From nobody Mon Mar 3 08:07:28 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6661A0011 for ; Mon, 3 Mar 2014 05:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.711 X-Spam-Level: X-Spam-Status: No, score=0.711 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDjqbteyXgEj for ; Mon, 3 Mar 2014 05:01:51 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEEE1A0051 for ; Mon, 3 Mar 2014 05:01:50 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w61so3158020wes.29 for ; Mon, 03 Mar 2014 05:01:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:reply-to:from:to:references:in-reply-to:subject:date :mime-version:content-type:importance; bh=32dbNqNPO1qVHYUNH6BOtEP2Zy9rGzUVFJOtNovwyQc=; b=oCfb8vRJKNzltFKtmCc3Y/abLq9AwXSag0MZbAGsJUNTWVwx6HmzJBjUwiMhXDw4Hn wq4AakeWn23IKJk4DYrMsdgz1lriz3QzdcIPUN7Ua4uWjosMKe5WjwQX46JEEYNIEzz+ uBUZ2aPq71zTvsVUv04DXdyDWAi2OrhNsqHzMZPBbQVNFuD8gJRKRmT1zV5ehEZpH5PK jeKZi+HFLJcqGLdYsWMvtm3nmlSPuB5cYmbhE5zwwo/pkyTYCc7SzLROy5DemUet9i8I UKRVjJyYpH/MswEglvbPbY6kLAfXyrNZol2fseNZ2Ui9r7uwVTwrrvnSMjC0pxvd/2p5 eqfA== X-Received: by 10.194.63.145 with SMTP id g17mr5715597wjs.72.1393851357436; Mon, 03 Mar 2014 04:55:57 -0800 (PST) Received: from C73782TX02 (dhcp-a327.meeting.ietf.org. [31.133.163.39]) by mx.google.com with ESMTPSA id ju6sm34850880wjc.1.2014.03.03.04.55.55 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 03 Mar 2014 04:55:56 -0800 (PST) Message-ID: From: "H Anthony Chan" To: "Catherine Meadows" , , "Russ Housley" , References: <79966625-7B22-4641-8B4E-3839AE3B67A6@nrl.navy.mil> <3FB80D3E15F745BE82C550268ABCA822@china.huawei.com> In-Reply-To: <3FB80D3E15F745BE82C550268ABCA822@china.huawei.com> Date: Mon, 3 Mar 2014 12:55:54 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_004C_01CF36DF.E9E6FCF0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/up7IJiYbmIOg_euGcGW8se0P_7I X-Mailman-Approved-At: Mon, 03 Mar 2014 08:07:17 -0800 Subject: Re: [DMM] Secdir review of draft-ietf-dmm-requirements-14 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: H Anthony Chan List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 13:01:54 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_004C_01CF36DF.E9E6FCF0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_004D_01CF36DF.E9E6FCF0" ------=_NextPart_001_004D_01CF36DF.E9E6FCF0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Just want to confirm whether anyone has further corrections to the = revisions made in the currently pending version 15 (not yet uploaded). H Anthony Chan From: H Anthony Chan=20 Sent: Thursday, February 27, 2014 12:32 AM To: Catherine Meadows ; secdir@ietf.org ; iesg@ietf.org ; = draft-ietf-dmm-requirements.all@tools.ietf.org=20 Cc: Catherine Meadows ; dmm@ietf.org=20 Subject: Re: Secdir review of draft-ietf-dmm-requirements-14 Catherine, Thanks for the comments and suggestions. I am going through them one by one as follows: The revised abstract is as follows: Abstract: This document defines the requirements for Distributed Mobility Management (DMM) at the network layer. The hierarchical structure in traditional wireless networks has led primarily to centrally deployed mobility anchors. As some wireless networks are evolving away from the hierarchical structure, it can be useful have a distributed model for mobility management in which traffic does not need to traverse centrally deployed mobility anchors far from the optimal route. The motivation and the problems addressed by each requirement are also described. I agree "distributed processing" is open-ended. The following suggested = revision tries to spell out what to enable.=20 REQ1: Distributed mobility management IP mobility, network access and routing solutions provided by DMM MUST enable traffic to avoid traversing single mobility anchor far from the optimal route. Thanks for the suggestion to clarify what the specific node mean.=20 I also agree that "can be used to protect" is not the proper word. The = intention of this requirement is that the dmm solution MUST be designed = properly (in terms of security) such that the use of the security = protocols that are already used to protect the existing network and the = existing mobility protocols is able to provide sufficient protection to = the dmm entities. Please check the following revision: REQ6: Security considerations A DMM solution MUST NOT introduce new security risks, or amplify existing security risks, that cannot be mitigated by existing security mechanisms or protocols. Motivation: Various attacks such as impersonation, denial of service, man-in-the-middle attacks, and so on, may be launched in a DMM deployment. For instance, an illegitimate node may attempt to access a network providing DMM. Another example is that a malicious node can forge a number of signaling messages thus redirecting traffic from its legitimate path. Consequently, the specific node or nodes to which the traffic is redirected may be under a denial of service attack, whereas other nodes do not receive their traffic. Accordingly, security mechanisms/protocols providing access control, integrity, authentication, authorization, confidentiality, etc. should be used to protect the DMM entities as they are already used to protect against existing networks and existing mobility protocols defined in IETF. Yet if a candidate DMM solution is such that even the proper use of these existing security mechanisms/protocols are unable to provide sufficient security protection, that candidate DMM solution is causing uncontrollable security problems. This requirement prevents a DMM solution from introducing uncontrollable problems of potentially insecure mobility management protocols which make deployment infeasible because platforms conforming to the protocols are at risk for data loss and numerous other dangers, including financial harm to the users. H Anthony Chan From: Catherine Meadows=20 Sent: Tuesday, February 25, 2014 3:27 PM To: secdir@ietf.org ; iesg@ietf.org ; = draft-ietf-dmm-requirements.all@tools.ietf.org=20 Cc: Catherine Meadows=20 Subject: Secdir review of draft-ietf-dmm-requirements-14 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.=20 This draft gives high-level requirements for distributed mobility = management at the network layer.=20 It also gives definitions of key concepts and motivation for replacing = or augmenting current standards for centralized mobility management (in = which information=20 about location of a mobile node is kept at a centralized mobility = anchor) with distributed mobility management, in which this information is distributed. This latter includes a list of the = problems that can be addressed with DMM. Although the motivation for distributed mobility management is not the = main point of this document, it is very helpful in helping the reader understand the requirements and their importance, = so I am glad to see it there. Since this, including the problem statement, is quite important and useful, I=92d suggest = mentioning it in the abstract. The requirements are for the most part well-written and at the = appropriate level of detail. However, I have a few suggestions: 1) REQ 1 is for distributed processing, but =93distributed processing = is a rather open-ended term. It would be a good idea to include some indication of what is meant by distributed = processing here. 2) There are a couple of points in REQ6: Security considerations that = need to be clarified: 2a) Another example is that a malicious node can forge a number of signaling messages thus redirecting traffic from its legitimate path. Consequently, the specific node is under a denial of service attack, whereas other nodes do not receive their traffic. It=92s not made clear what the specific node is. It would be better to = have something like Another example is that a malicious node can forge a number of signaling messages thus redirecting traffic from its legitimate path. Consequently, the specific node or nodes to which the traffic is = redirected may be under a denial of service attack, whereas other nodes do not receive their traffic. 2b) Accordingly, security mechanisms/protocols providing access control, integrity, authentication, authorization, confidentiality, etc. can be used to protect the DMM entities as they are already used to protect against existing networks and existing mobility protocols defined in IETF. =93can be used to protect=94 seems awfully weak. Is there any reason = why you don=92t want to say SHOULD or MUST? Or, if you don=92t want to make this and IETF SHOULD or MUST, you might = want to say something like =93we recommend=94.=20 Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil=20 ------=_NextPart_001_004D_01CF36DF.E9E6FCF0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Just want to confirm whether anyone has = further=20 corrections to the revisions made in the currently pending version 15 = (not yet=20 uploaded).
H Anthony Chan

From: H Anthony Chan
Sent: Thursday, February 27, 2014 12:32 AM
To: Catherine Meadows ; = secdir@ietf.org ; iesg@ietf.org ; = draft-ietf= -dmm-requirements.all@tools.ietf.org=20
Cc: Catherine Meadows ; = dmm@ietf.org =
Subject: Re: Secdir review of=20 draft-ietf-dmm-requirements-14

Catherine,
 
Thanks for the comments and = suggestions.
 
I am going through them one by one as=20 follows:
 
The revised abstract is as = follows:
 
Abstract:
   This=20 document defines the requirements for Distributed = Mobility
  =20 Management (DMM) at the network layer.  The hierarchical structure=20 in
   traditional wireless networks has led primarily to = centrally=20 deployed
   mobility anchors.  As some wireless = networks are=20 evolving away from
   the hierarchical structure, it can be = useful=20 have a distributed model
   for mobility management in = which=20 traffic does not need to traverse
   centrally deployed = mobility=20 anchors far from the optimal route.  The
   motivation = and the=20 problems addressed by each requirement are also
  =20 described.
 
I agree "distributed processing" is = open-ended. The=20 following suggested revision tries to spell out what to enable. =
 
   REQ1:  Distributed mobility=20 management

          = IP=20 mobility, network access and routing solutions provided=20 by
          DMM MUST = enable=20 traffic to avoid traversing single=20 mobility
          = anchor far=20 from the optimal route.
Thanks for the suggestion to clarify what the = specific=20 node mean. 
 
I also agree that "can be used to protect" is = not the=20 proper word. The intention of this requirement is that the dmm=20 solution MUST be designed properly (in terms of = security) such=20 that the use of the security protocols that are already used to protect = the=20 existing network and the existing mobility protocols is able=20 to provide sufficient protection to the dmm entities. = Please=20 check the following revision:
 
   REQ6:  Security=20 considerations

        &nb= sp; A=20 DMM solution MUST NOT introduce new security risks,=20 or
          amplify = existing=20 security risks, that cannot be mitigated=20 by
          existing = security=20 mechanisms or=20 protocols.

          = Motivation: Various attacks such as impersonation, denial=20 of
          service,=20 man-in-the-middle attacks, and so on, may be=20 launched
          in a = DMM=20 deployment.  For instance, an illegitimate node=20 may
          attempt to = access=20 a network providing DMM.  Another example=20 is
          that a = malicious=20 node can forge a number of signaling=20 messages
          thus=20 redirecting traffic from its legitimate=20 path.
          = Consequently,=20 the specific node or nodes to which the=20 traffic
          is = redirected=20 may be under a denial of service attack,=20 whereas
          other = nodes do=20 not receive their traffic. =20 Accordingly,
          = security=20 mechanisms/protocols providing access=20 control,
          = integrity,=20 authentication, authorization,=20 confidentiality,
         = ; etc.=20 should be used to protect the DMM entities as they=20 are
          already = used to=20 protect against existing networks and=20 existing
          = mobility=20 protocols defined in IETF.  Yet if a candidate=20 DMM
          solution = is such=20 that even the proper use of these=20 existing
          = security=20 mechanisms/protocols are unable to provide=20 sufficient
          = security=20 protection, that candidate DMM solution is=20 causing
          = uncontrollable=20 security problems.

   This requirement prevents a DMM = solution=20 from introducing
   uncontrollable problems of potentially = insecure=20 mobility management
   protocols which make deployment = infeasible=20 because platforms
   conforming to the protocols are at = risk for=20 data loss and numerous
   other dangers, including = financial harm=20 to the users.
H Anthony Chan

From: Catherine Meadows =
Sent: Tuesday, February 25, 2014 3:27 PM
To: secdir@ietf.org ; iesg@ietf.org ; draft-ietf= -dmm-requirements.all@tools.ietf.org=20
Subject: Secdir review of=20 draft-ietf-dmm-requirements-14

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

This draft gives high-level requirements for distributed mobility=20 management at the network layer.=20
 It also gives definitions of key concepts and motivation for=20 replacing or augmenting current standards for centralized mobility = management=20 (in which information=20
about location of a mobile node is kept at a centralized mobility = anchor)=20 with distributed mobility management, in which
this information is distributed.  This latter includes a list = of the=20 problems that can be addressed with DMM.

Although the motivation for distributed mobility management is not = the main=20 point of this document, it is very helpful
in helping the reader understand the requirements and their = importance, so=20 I am glad to see it there.  Since this, including the
problem statement, is quite important and useful, I=92d suggest = mentioning it=20 in the abstract.

The requirements are for the most part well-written and at the = appropriate=20 level of detail.  However, I have
a few suggestions:

1)  REQ 1 is for distributed processing, but =93distributed = processing=20 is a rather open-ended term.  It would be a good
idea to include some indication of what is meant by distributed = processing=20 here.

2)  There are a couple of points in REQ6: Security = considerations that=20 need to be clarified:

2a) Another example is
that a malicious node can forge a number = of=20 signaling messages
thus redirecting traffic from its legitimate=20 path.
Consequently, the specific node is under a denial of = service
attack,=20 whereas other nodes do not receive their traffic.

It=92s not made clear what the specific node is.  It would be = better to=20 have something like

Another example is
that a malicious node can forge a number of = signaling=20 messages
thus redirecting traffic from its legitimate = path.
Consequently,=20 the specific node or nodes to which the traffic is redirected may be = under a=20 denial of service
attack, whereas other nodes do not receive their=20 traffic.

2b) Accordingly, security mechanisms/protocols providing=20 access
control, integrity, authentication, = authorization,
confidentiality,=20 etc. can be used to protect the DMM entities
as they are already used = to=20 protect against existing networks
and existing mobility protocols = defined in=20 IETF.

=93can be used to protect=94 seems  awfully weak.  Is = there any=20 reason why you don=92t want to say SHOULD or MUST?
Or, if you don=92t want to make this and IETF SHOULD or MUST, you = might want=20 to say  something like =93we recommend=94. 
Catherine=20 Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: 202-767-3490
fax:=20 202-404-7942
email: catherine.meadows@nrl.navy= .mil=20

------=_NextPart_001_004D_01CF36DF.E9E6FCF0-- ------=_NextPart_000_004C_01CF36DF.E9E6FCF0 Content-Type: application/pdf; name="draft-ietf-dmm-requirements-15.pending.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-dmm-requirements-15.pending.pdf" JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nK1WXXPaOBR951fcycsmMwnEZLtp+kaANGz5SBNndjpNH2TrGmsjS0SSIfz7 vZINMU07ZbaBActwde65535YT3DajuDUv+trWrQ6t+cwt61T+EifeeupFQUDqC9pAZcxGb2HqAtx 1qr2RdA9g/N39EvROpyiW2nzCP/Ql1Bz+Gh0uYC9Xtdt6OdMwcPhkLcfjo7if1vRGcTj1uFIOTQK 3cnAsMzthwbXJVuhgBjTXGmp5wLt0R8VluLIwTrmSvsBRirTpmBOaMXkPsCDNoxF6bGGzwthkDB6 5by0Ds6iY+ieRn/ug9LPhWIw0YmQ6LH2jOqnr5s23KFwb4IFMDNMzd8Ci5L6RT9qx96C16fBYARj lvw21t9t+KRNrhWq/4V1aTTjqS6gr4uiVCIN5WN/g9cVJqZkZg3d86qGCOvsIlR/0+wWn0oquQKV s0B1CwNhnRFJ6aiiQzEJt4YJU2wejAil7qEfeuW+n04EuuyEF8WJaaCfRO9oc/evsLmXkBeWujrA OBcWuE5LbwkcM6HQgssRzD78dki9cKXGH0wmD0fAXMBS9SiRbI2m7b0i5AINM2lOikvqYFOmrjQI YpNGYslF3corIiLR2g2QhZxZkERkYUTBjJBrcBpScm2YpBuOC6nXyGusYiMnU2mujSUKPQtWF/gD aEYscKnl0g89tmJryIwuNqx+yvwYhIOUhl6CUFrMSkkklwgMeEO4QnOUNZYXdcuseBFPKFgReO4l yDKRUn4oJ0o74kgQFCj9sURjN139Ou5XEUPGTIgjRKAXjmSTQBPdYZWPrVJOLEML0E4ejBdGJxIL EoZzGpGW0JM1ICOCjRoJsjFpdQ3E0aYUNPL2S+3tlPyYxlLJtpPJl8QjroFywC0cTO7v4oPj6grT WVjfDj/fj26HA7++u+6Nx9tFZbFTjPTH7H5c2/rVC0p/NpkMp4MKaNL7Qhcf68HsJh7Npr3xgc+A o8bYhLJpDx8iqZ/4KqXH2MKgTylV4jZYv/P2qg/dKLrYLmqYr3Tvb781FLkLTy7QWfAHEyx0szG/ e1rSL7ZMCuFc5YlqTEKqq6eeSn0xu9znbEcJyt9SWD/UvJ/L/g2cvw8Bh+VFgw0Z73qsmmFVHwA2 OtR8cWsMQzWnuYGGrHZcx8w+wpU2RO3hcDSMrx6OqNqm2pGOOc0GTSgG5v5gYakD1qGAGv1Sa/Ga APteG1tPFUl7Pb20NManbGtVQ9VhkZLkPndu8aHT4YyyQDPxkWaTH6BtbeadME9tp8bp/FqlsKFB ccmk4KHHGYX2LIqy8MSseKYmUy63O0r5fHgB/PBYECHkx9RdC8lSvyIQnVgtQ71R81W6NeSg2lTr zYgShe/pUagXOpksqABoTDIXipdG02v6lnxlSIGmXnJ//iNWzRPcMVCWmWzXD5v6tPSrw9LXG+pv iL4R5jBufab3f3mU6tplbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKMTA4NgplbmRvYmoKMTIgMCBv YmoKPDwvTGVuZ3RoIDEzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicbVNNc9ow EL37V7zJJTCTGAxMk/aWAOlkJunQxLfSg7DXtlJbciQZyr/PypiGj+LBH9Lu2/fert4xDCMM/dU9 kyoYvNwgt8EQ3/mfB+9B1AageyQV7mMOukU0QpwFu7wIozFubm4RV0HvUTkyitz1zIjM4ew3e36+ fqF3e76DB1qZRpgtRsNo0o/fgvFXxE9Bj7cqwahSlNAGTiORjuAKqqD5zkuFUBAWFxtt/kAq1Ebn hqwNL/qXwejLHiYupMUJw40sS9DfWhqCVrhr8sY6jKOrlkbI+b2prrdG5oXDD+1kQn6N0T6Xl71k 2W/j8TiPHxAbjyFU6kmiJmO1spApKSczSannyjuME4333FKdNBUHQDSu0MaGwB0zawtYsBgya0rD cz3/EvndNqs3Spz36H66APdkT+KT16XFE+WiPKq+MHotrfQ0X6gUTqrcg7RZs66A7XQve4Vz9bfB wHk4olCSy0Jt8kHJ5ihL11Jlmg3hRlCWeT5srCeRchuhsw6nblacwLV4V2cccCCG1S9KEpZY+VrS xqfzR3pCJRGGsqYst1edpVukZBMjV4StbszePu8CW+iMTFwrciNd4VdqZtdhsdxTClOdEt+qWitf lMfEGZE4bmBmdHUcjorN6KCkSsqGU19lVZe7jt+/zvC0sweOcTzfPdXUO/VKLTVMwgOLvGm7YWpb dtgmL4nV+1Ff82SlrSTd8EALY4RyW67QoRzV8ZD/5+VnazIZtSMx9Sdq2Zun4bJ/BWK6Zdgd03l7 VuzpSTk9zb8WIieMfjPoPA5+8vUBMI1bxmVuZHN0cmVhbQplbmRvYmoKMTMgMCBvYmoKNjAzCmVu ZG9iagoxNyAwIG9iago8PC9MZW5ndGggMTggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJl YW0KeJydlF1vmzAUhu/9K85dE6llMZCQXGZNNk1aq35wt+7CAUM8YXvxR7Ts1+/g0K5ZK7qChWzZ Ps95j3nxDiYRhUnbur6Q5MNdBrUlE/iMb012hIYN0HWFhI85bpoDjSGvyDGOQpxAls0hl2T0RTlu FHcXK8MqBy+e1dXVxR3f2Zcr8IlvjGfmAPGEpuP8B0kWkH8lo5xtGg66gkuNcOXs+IzEs7CEUTQC wKRGl75wQiuI3t0gRSJNHokxzmCqPaZCngVveQlCgdsKC6UuvMQV6CdOkTgKVcVRqzDnRgqlG10f +iN7WEmrC1Mb1ojfKGnPjfWoSFhnxMY7nJJ6IxrhDiCZYjUPQk9YsyddSdD1nPdacJ+u7BmrPbPV G0L6WPOOleL4xmj84BLuHXNvRr7CWnSsKY7Ral6YQLEDnEFpx5oh654X3rQ1oTmsKLlhR3/8Lyvt WFnr2OX1ciDnhDU/evV47toMqvGRtQjnVXHDVcGHkJD11xOL4K9rbSSWt+fvJ5+w4vCXV0NpT6yl d1s8pjNYlqXh1g6ok7b+SqfTcF1cbpmCh9G6jB7G58AdsCbqrrP1r5/oPIspa28dJPQ8XGz/3nrf bvD/gOQ7Qtc5ucX2B4p7PHNlbmRzdHJlYW0KZW5kb2JqCjE4IDAgb2JqCjQ3MAplbmRvYmoKMjIg MCBvYmoKPDwvTGVuZ3RoIDIzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnichVbR bts4EHz3Vyz6cg7g+Ow4bZrHNGmLAGnrawwUhzoPtERZbChSISm7uq+/WYpy5OSAcxBEscjh7Ozs Lp9oNp3TjH/S36wa/fn9grZ+NKPP+N2OnkbzuIDSn6yiDyssek/zM1oVo27fnM4WdHHxnlbVaHxr gnRGhtMbJ4pArz43X76cfpdP/vUb+iQ3rhGupbPZ/Pxk9Wu0uKTV3Wg8nxIB1tm8yYKy5uSP0dm7 +Ib4BYVSUi18oFxmIpckqBDKkWmqjXRkCwKdvXWPp1q0+KKyG6VVaKl2NtjMag/A+aIHLMVO0kZK Qz4IkwuXq39kTj+/f7p+d3bx9iE+vb08P09Pi/ez7undYjZ/ABSDxDdn88UDqF/pUNpmW3Y8+zMp V0UBNgr8pas88ywaEwP0hIMTkvDeZkoEUKik92IrqbCuEsFPGLAloTXJqtYWj8+xCZOV1lGwPYzW dt8vkGQsdAqWnKwEGDgpslJs8AI5Y1IBMngs3uFYLBMJpeMsTeglRXgrRJVOq60yYUKismZLFuxA QPhHMJXGN076BJNZYyQi3THTTcsB7Vln7KpF9igD1JE+KBNPnxCgPR9aOFvFqBPOIBi2SCAF5SjD Uod4W4CwLKzcC1lUZxqA+h4rlCLELw+bhMtKFcCTmYNHLtrOHIJ8xao/Gwz7DkDdETGFEQ9cikJl vKxSWsf08vMzd898hCFbSyeCdQkoSQweAGlrlcWYKmHggZxliyGIqpd/elQXN8oHpzZNGIbfba5Y y/UYlbg+iZLhdM1VK5CSaAtGFhtk/6gykrCxHDqVGClZYIPEbZ1tEPVGlioFr7gbIJWsH+qpydsU HA6PgdVOVcIpBJZyUlh2KqxwHM56PAdZ+tKp1njJCjs5QWwsT4kY5E66CXvLNxVbqe9E/FUA0aNY 4keZTDfRdjH7yIq2UJmuuw10IzUEQUP62qXCg8b1zVcPJvtSZWWKJX5KkSOZsJB4ROs4KA6iO5VF IVBGWQaBAgSC49my980xSO8VVdXWwxdG7lGbT41yMWkwjumNk3HcpudVHFwTP7kI4gCWpyg4URaC QydwkL8zKVPsSPZOKB0bAOMOoXoXZgKliYgmh5DQynYq50QY2bUJ0Nadu0B8CAIrooNtFULyCBlN DSg6tgBJt8vd+aBKCm0h5Xosp9vpZAgSe+zl7PJhAsMpl9NnabhgUFG0FC7gH1+qmpbO/gI0IBaf l0vOFfgPgVDU6Ld3MdW3S7rKMjRWLL+7XV5hORfufWSHqPB+lah966gNkdbj+9vl6hs2/VzdT88W 03OMAPwXShc7/rCsRHfMIWVJiCHcD+RZ86KO2xXacm89HPXj7uorn7QU6BOnw31dVUxvkPVpYonE PsSxSSLPFWuEvkxbZGEv2l78OEoPKJXEDDDKV9HDPvqCC40T/VtV7OYjF+9VKFPRflxeD5E+7qzm ybGMzRzlBKuux1jUC3W5mMXR+LcMXe98PtzTXr5wIKqqbpxvgKgG0z52CbYddrotP3PmNtxj8fyq QFMdkbe66YbsRrY29alXdwKQQxfw2AM76/bIiBjJamvigQdF02CJc5XHFF7tlFdsob6C1JHazorY pTy6KhqgjQMXsioNplk8tLuF5NbIGBm3S815iMU2xNpZrsdUl9wkdHvcPePnAybyyzrrVUNXG6YA Cdbcx40sVDd2XzfPblbupLZ1LPnnmXY8ONkmVEhklTQv5+l3LATSARqlQjFjZ3RZvOvFfKdpFDta LQCVBl+fsSMHP48333pUeZxNmHABdxYWjW8ZqDx7yrMU8G8KLQ53Gf9miNUV6Qazi5srbj6Oe0pm q6oxGMXpmhZvOrXkJtjfKTCQhzhbabdO1CWPb06hmP7/bObrADg3+ii6yPU/JAZVzlZ/4xtcOTJt uX47CYdQ8aLGGRMh4ObX56+veDYPX+eR7WuerKjdfLo+wTUuoKVN+yr/XStO8FWzbaDSYj6JF3d6 8UG/wp31nG/GH1ejv/DzL0SJ+N5lbmRzdHJlYW0KZW5kb2JqCjIzIDAgb2JqCjE1MDcKZW5kb2Jq CjI3IDAgb2JqCjw8L0xlbmd0aCAyOCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4 nIVWwXLbNhC96ytwiz1jqpYU22l7SuOk9UzccR31FOsAESsJDQjQAChZ+fq+BUiJlNuJNB7JIrB4 +/btWzyLy/FEXPK7/Syr0U+PN2IdRpfid/ytR8+jSVog2o+yEr/NseidmEzFfDXK+yZiOhM3N+/E vBqd3dlI3lIsbr1cRfHqdXt/XzzSc3j9RHyipW+k34vp5eTt+fyf0exnMf88OsOjp7Pp07kQc6fk /k0QlVtqQwLH7Jz/FkTtKZCNIpDf6pLwv9tqRT6InY4brNudvxlNZl209Co30hiyawpjIe45oI57 UcvI+IPQVulSRhJxI+PhQKcoCLeKZBHwEMpTJbUV2CrLDSkRHXaRCLICFKcBzK3apxXDXDkvSmcD Q5RLQ/1YNXntFB8iosb+rw8SPxWfHcBoux7/jRwXQPylplKvdCnuHjI6oO/HqaSVa0rHhaaunY9C ByQQgfa50R4wGYasa8N5asDJqRrZ2HLTDyWtAtyqNpToIO1BdAhpy27DvHC2PYr4JORnqYyk+pF+ QAzS+sPtaEv+QpSN9/jJ7C+Q4SCxrlS9tFAVvbZdSmYn96FwVjgwl1K7GDKDg/EHNrHWoOQeeCKr hUkHPmCP9JLrRMDW5tYPEpplKL1eks9nBmEcx2MSaS+kpyMDXdqtXMf9OPMNcyUtqhIag2QgI7GT AUwDDH50jS+hOa5Bw/FAPLdI6UIM/UCMInF70gLg9M6uuOYshVSdA4Ola1BUlZpkUPCjKAAokjF6 TRZBQ7NGv8ReT/QLgXBGieVQzhmGAi4DMvSWDG8Ap5J7THy9K27Hyw3Sk14XalMWpZEhFEsZSBXD SLTSL4vERNr1zfmNs2SLa2i9yI/xwUWPmsLiAjCbAA5VU6LWAx2CKFm5JguwK3cnDKAFspOKTa87 94CDYeleKB0iFNDEnv6ZDon2cT50MZSMsqiNtFjmdtKjt+XAjSoHsawMGG2Py/wkjv8zMIurdkFz fQ79VRqH0ndSa/D9VwHiIXB00DEE6hjDoVL4Ygw7y1AEHGGlfYjFxtXCO6TIOvokS46SVi/3ObmO A5YKqDxxohbxhdAxUbZMwINesme4gSaAWEDCbFD89SQQyhodwB60pqgmODRaDgfvNgQwPvPWdzsi ll4O27XdXUz9dtQGncghcIaoHjqqyj2Q5d5A+AdxD7WyhXhdE17x3PrJcFyNOwxHttH0W6dVLl2v y9FrmA865LHB/BLGltWhCswfELKgujgYuDwQVt5VYF44k5xH8vg7FdFQ0cmElCubdAxbPSQWegJX x/29udIq5qjkEr96afT3/9kApr5wwUHpbMzHJpuCGKp29hxJgVKkUkARWmmmtmPlh6aqQPf3zHwX 720br2Inic53wmmHXZXKAcvZwcxal8Z44K3SDBexkbaVKozck28j/YgNxraGlm0f1hW3jbapC9s4 gTDasvu2N4A8fHk/ziiblHIvxvVpsQ6sZanm063qGh8sYjxnj9y7bw72o6qqCKgOy3TRsnwsG7he Qfzp0Pa6cXtMdtzdjcaPtNW0WzCc9mY2RXofnEXSOYcmdN7ZE9QR/XQ84TKRr7R1xq27Ir1HTRg8 mgZ0mAO9hSeT3Ab+U4UuR1w/ZOmd3VeHAwfpDA5PtKILlpQmmceY4ICS7wyrvtXf5x69e9hedxIE jSK016xsBF8fP324nt5cYba02x68e9l3Dc6bhzvaULzvajqZYZ/MPB8unI9tij1W0vLZzdVskUUd OtPJNGhbmkZl11qxf+9gg78M7l9PZ/d/Pp3jEuVwiQq1s6ob/oh0NU1MfYCRYOFHNeaVBKbMuB2P H19qzQbwvlmz6c0mF+lKLk5e0MqaxNUCMT/OR3/h/S9A3AYiZW5kc3RyZWFtCmVuZG9iagoyOCAw IG9iagoxNDA1CmVuZG9iagozMiAwIG9iago8PC9MZW5ndGggMzMgMCBSL0ZpbHRlciAvRmxhdGVE ZWNvZGU+PgpzdHJlYW0KeJyNVl1z6jYQfedX7FuTGaABmnA7faL5uM3MpZNmeLvJg7BlrMaWHEmG 6/76nhUy2IROaobx12r37NmzK7/T1XhCV/yL56Qc/Pw8p40bXNFX/DeD98EkGFA8JSX9voLRF5pM aZUN9usmNJ3RfP6FVuXg4lF7abX0ozsrMk8fjrvlcvQs393HN/Qg17YWtqHp1eSXy9Xfg9mvtPo2 uMCrl4vbP18uhyR0SrkpJYmN1B6P/1i8XJJwVElL358fbm+m8+vX36gwiSioNGtVKN9gWZIbe/nT YDI7evy2DGvhMdjBZ5JI52gjvNyJBhbLxde+9+vpZPa6R5EYJPrDwyd769jM5tez1zGeT2/aWI+a RJoqr4weks+VozSQo7S3Jq0RFU8lZaYozE7pDYHC0o2j71tkakVRNJTKqjCNTE8Tc9ESh5UZcHgT HB7MSqFBWMmU7X3wpUN82uUqydnYIn8rexTh2EqUI5O7DxEDBxwD0LJMJWQyKlVRIEUXrgOlR1za pDIEFJoMqBLeWIJMdsa+ceAIMaV1E9w6wUUOsfpcRjbUP10ajvkdI5biDRFrJxlO8jmHLd13ynmr 1rX/LADKqI1vXQdAjnkX/kBKauTeSEu85apYAUrdB57/Bz7KhKXMmjLwYyqvSkjcGgDtM/RQAEGU dGT4CDqHUrmehdzKIlSKPbDmcoWq2CRvjrJM+XIvpVR4QZXw+SnyWK9zUnON87Lsg1u2dv3+2dPJ jhI0gUy4VRic0pmxpQi3Vr7Xyu55rKzZqvQY9hRVF0VdVcZ6dJclQRu1lfrADkTJ8OKcmY378uJK 1ejVTwVxJr0OANYJys/alolgQXKej088EywPHOQpupB6yZSYREku9EbykOGVbALzrXTj8wGzWgcC XVi8brtQlVURDIAECklVhlHB9oVokCnDYPeg1htUgZwXyRtCLHwEHP28XERVYTaGpcOz1U/Q6WvU s1C4G62FQ9hjz4+is/C8L5GFRqxR8HzW8QEgK6apVBL6JgbQjLVHYGWVThRS5wS5lhB7rVzOml8D jIQeBDkUgkUGUWmvMvRCmHAiwmybpC1Z2DUEugP/8Bx3VdV1GWbjzozD9F92p+Hj03BfR7RhXwWH RopFxh7Bw7ytOfcu1x1t2U58fneCbYiZjrpGsRirNkpjUHQirSV6QUaigsY6MYOwQIflU3TykRyk tcIL3mZZaa2fY5F4e4U+uv2Lcr3JyvPEEM6ZRIkAu5NCu5lGnDvl8/+O/wR1Smxi0TrO15DT9TQU /xZtAyD36Zg/HaQnUYzjp8b9jwqjxNGi3tTO02wyDB8dp18k35+QD928wuf9avAXfv8C2CTv42Vu ZHN0cmVhbQplbmRvYmoKMzMgMCBvYmoKMTAwOQplbmRvYmoKMzcgMCBvYmoKPDwvTGVuZ3RoIDM4 IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnichVVNc+I4EL37V/RtoQqYADth9sgS wqZqSLFA1R6GHITdgDay5EgywfPrt/VhYs9QsyEpHHf309Pr19Ib3A2GcOc+8TvNk0/rCRxNcgcL +jsmb8nQJ0D8SnP4c0tJX2A4gu0hCXVDGI1hMvkC2zzpPEmLWqLtP2h2sPDTz8Ny2V/jm/k5Ao+4 1yXTFYzuhr93t/8m4z9g+zXpUMigMVxJ4BlKyw8cNbxzIeDAtbGgVWkRrAJ7QlCaH7lkAojEu9Kv 8H7i6Qk09ru/JcNxjZhxjak1riSH0nB59NUOyj2zLNO0pgPNUPAzLRjxI5UBoTmcNfYDlKsqWPqK HpQbeGcVpEzSyqYUFrgEoSjHkzUDgKkEvHDjCiOWKizP+Xdm3VZDXuQpql9wVAf/+qSM7UUkJjMw JW2beDAf6e+ZQXqpRGkj/dF9LcaWyiVeLJBiVLc3bj9KGiJYCEbMU5JdM8G/E4TDzoi35ntimEGu 9lxwW7XkzZlkR8ypDA6ljGgEZP1KvjENCuPBkASZNRapQRtAcWtPbTY3Ent+FaHSICSXB6Xz+hnI nrlpcSX9GJUXhRN1T+QQZbPVTde5zd/oQeRGar9iYYHRL7h+CfwgyGR6UrrnIWqjZOj6T9sI5oow t9bVYU1KPXMWDBYAB14SRdU0E0pnpuc7H6FuyAOmMhZz4zGbUpI4e8Lx+0sVvVcCqP0SG6ZysYxZ FgKw6/gFqKcqQ3haAYEdDjzdddsGWzJZXd1+k1SGhVCVezT0+hXJ7+g60yDYNlhbVgdL/MnrpBbT Kc184wjwLyyZutRIDTBgTupd1k2T8MiPFAFnwvmF5YXAoE4YqxyBWBLHXeev6a7rdXDuEk3rB4Ec FUr7unR5BvXZe8SfMjFqgNzo/28qt+ssnwNyhFqG4DRN3YQvmEV3nFDadEF5RDkmPK3O9/Bt/Ti7 H00+v3hqFFxpdanaSNfEz6Ph+MUdSoUb8jOKyo+eEKVgulbMhNMjMI9A48VqBQuUpK+AlTcwrFnG FWy8oYjdYrXeEL0riKPjy+ZnJc5Yby4WX8vmq1YV5s4K/zflEcsqFSbASRooEokaLBwFtXw+simL QmkLz0H3xWJDytfn5ia27Fbmxmf6PYVtP0d3zcKsCHStXz/Pdt2IRkNEhrfucvowZuXPm+CFH5iT Di3ibbke3NjVa344YtVf/BNpXdlfgxsfvEFHhgPjJik3uZMwaLMTXWDUoGxAGgGRYGIQb+v5paCr ycC0PJZ0B4+HPX9v/3ipf1tRv2DyQqDzbfI3ff4Ds0q3kGVuZHN0cmVhbQplbmRvYmoKMzggMCBv YmoKOTY5CmVuZG9iago0MiAwIG9iago8PC9MZW5ndGggNDMgMCBSL0ZpbHRlciAvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJytVk1z2jAQvftX7K0wYMxH26RHGghlpmYoYSaHkIMwAlRsyZHkEjr8+K6N HX8mkE7EYMna1dun9VvZT9BudaAd/uLe8QxrdgUbZbRhhP+N8WR0IgeIO8eD73N0uoZOF+Zr47Su A90eXF1dw9wzamOuqeRUmwNJ1hpKbWDb5ow+qbIFbulSBkQeoNvufK7Pfxu9bzD/adQSe280ncJo OrsrLowMw2lp3h5PrSle6p+MTi8HBQ0zao3iknPzCJWCHGE0uptgV2hHmJqj+4r5H33rp90/5kA+ hAk2a7Eoup43FEAsgGrntw15FCu8VHmfM+RgrFNXdj9vyOJYyaDof4khA2SlDvkFlxlSJCvrk11x qeEElVdHeve++RPWEe4yMk7vcJSRcXp3tCeW3R8l8/Hdx/OCknYzirVKSXqxFXSWUVcjDVroQutx NrkJt1fuzq7tfk2Ol1u2CSSFTgvghnIticv+0hV4Yslcpg/gEU421ENTK0TttbroOWBKS7YMdLVn vC+7bIF1wB3NBFc4eQDiKgFLCqsMnhbgBa5mvktz5yCe0XshdwqIArUVew6MJ+y7TUAgvSUayIkQ BS5WNHQh/ABijUaqaEzsBSrkgOEVlX8w8hIJoY1IHCQ8Yc/0FojvS+FLRnQCkezakiLQjG+ye1zU ZvaiDg7xyckpzFzh3ZBtVeoqjypeCpmGT35mw6kKXh8Vz+B3M6hc/Up7NVpla7w/xBHsyf9GKRXA BbJuvaHrWEk+kZoR10XJSdRQOMhoO/cIH8bmoHUQO6GJufI8UzmUE8nEIxIZ81CvsBbSoxKFpCgI jljh5IpoAr5LOKpbxYwyMZrAPN9lDtPoT5QKvFCdiiIzEgkaayGCIHwFjsCKF26MEoFG9bWiykE8 TAMWUER0T3ZsR/bExNqhz9r0Peabjm8GvpliPyYZui3uvCqdJ6IYMKrbpcA6S/aXJRQRDQ0x2WRW 5o4NTNr9Niz7JFBSp2k4h/DCWYO5QhYKjwqNde9QpcKvOcw6IBkqEeJLN3pcN1tcu6gNV61FvQkU Txm3FStq+OwziZvoB5tAaeh1mtHnYFF4D1OkAdePiDmcG7/w9w8ReHEmZW5kc3RyZWFtCmVuZG9i ago0MyAwIG9iago4MjgKZW5kb2JqCjQ3IDAgb2JqCjw8L0xlbmd0aCA0OCAwIFIvRmlsdGVyIC9G bGF0ZURlY29kZT4+CnN0cmVhbQp4nI1WTXPbNhC961fsrfaMpFp2Eie5uZKTeiZyXVu32AeIXImo SYAGQMnKr+9bEPqgo2ZKjYYSATw8vH27yxc6G47oTD7pnlW93+8vael7Z/QV32XvpTeKEyjdsor+ mGHSRxqd02zRa9eN6PyCLi8/0qzqndyYwM5wGEycWgT66ZpMp4N7fvE/j9AXnrtGuQ2dn43enc7+ 6V18otm33gmGFo3JgrbGk2+ygpTc5z5zupanVCmjllyxCf3uQK6CmivPfVImP/2tN7rYIoLi2rpn UlnG3pNqQoHlOlNxXbA0Z/K60qVy5YZy7YPT8yZwPgTM+YctzNXhEFV2rksdNgeEyGcFftDCOlK0 KFVoZ/GOgV10iCVCxubsSXuqna2tB7g29P1O1ewGkwM2k41Rlc6G07T1k/ATnJvgcQbDC40fdsWO MtBxqtQ//oNpoVaMJWzIF3ZtEk4onG2WhYjRlKoNwhEe4z34z1ym1rFQ6AON6fHE8eNp41mCQvwa 2HgR3S7wB5DaLOXUwWa29HJsLEpA0EQv48y5DQVsUXaDc/Rcie2Wi146JXsM/7QVD6+WmOKfjh1p e4zhw9X1U+RaKxe0wp5bOv9v56Ogd9Obu6eE86t5Mu0gNI5r60Jrh70umMk4VeN4SDQr2DH8BtfP 4z3JJroaXh9jmmD2qie7NgLZOaZyWYHNMhnokw5iUceZrQCTYzzYhLXQzgfKYBedw3zrgkHX7SN8 TK/9/pkyIJ+gokXyNvVSTXiHc945Oy+5ooegwvYU+8yECoInMzyUQt61mKTy3CHDwHWt4SEUJBwK yd5UlXIxOXbS7rNyYcvSrsH7c2eTu4fRZ6JbawYWBadSJSFZAvtEvL3u8UhOvNIKmh5moTJZAaHt IsTI+qYM0fBmD9hh0V7tFjGXHM83WJA5Vl62kPSCVINgB7gh7qXaDDtadJghdlBfL9gjtP0YdH5V VV0itAiYScVIkBWsoxx28+ykmFjXQWqfeslMRWOLJoBwTrjUeLqh21TqHk/Gk9vH0z5Wt/hwDusV 8Dtgpc0kyUitFOovWNPNHaH6SHmGp7DY43TCqvO8VtkzBz/sYD2eXG8dF3WjqKv+0dZ5CGCN7ESF 9WEgrSInb8tGRiHcX6YDJvLaaOMC5aDfEo2RdCnG0VKS2qsP9P3+y/jD5dn7pw7G1n67naWoiG5h HyQRB5aMNU4eT29j+dnne3tl1gGqtsgNqC0dQxSGwNHQKgSF3iMpGUG8QhuaXn2NvbDN3A6asYFU XZcQUySP8ZF141vKLfs4PudYiUr9LMUbvIaPp28S4hwJMZGwo7Bm6HvOVkkzXiVhpccHhxC2Zm/N ccToh7Vm3/l31Sj1jCy5LU9u6zbo9pp2Wq5v6ykIomiK0WJlFXqrmER2rRy4te36CK8EA3+Mf91S JYs0WGv/JqX3WNEw6cVg907SqbE78X1TS+1HUN5Ebifs8E0sLhCLb8gKkcnDqioxFNUOmIfGGC4P C/Hbt6X22p0wSv6KNxmlRXuUMT4i+gOHmBNNnXbwu5eJXRnclkCxZETDty0H788j2hiZJkmcD6Vu MKiVw4R//VprMcZVs2yQ/hejfnxzpDcXmuuS6ZNk4fWs9zc+/wIfv4OXZW5kc3RyZWFtCmVuZG9i ago0OCAwIG9iagoxMjE5CmVuZG9iago1MiAwIG9iago8PC9MZW5ndGggNTMgMCBSL0ZpbHRlciAv RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJx9VttOI0cQffdX1FtAMg42LJDkaRfYFVKICDiKomUf2tNl u7M900NfbJyvz6mesZkxTkCWwa6uy7lUzwudjsZ0Kr/te1EOfny8pEUYnNIXvBaDl8E4B1D7VpT0 aYqgKxpPaDofNOfGNDmjy8srmpaDo7sqsq84ntx4NY/07ufm/v7kkV/C+2/oM898Un5Dk9Px+fH0 78HZTzT9dXC0CyjdzFgTN1Q4VHmNNHeeWBVLuv+NUkjK2g15fknGc0C0Z4ksuIpeRdbHPwzGZ/2M iHPJF4g2FSlqQq35hzVpDmZRDSkuU0CcToWpFhQKZVXTxQj53jLdmBC9maUoUXHJFFNVsaVSGfRa KbRB81QV0ThUqnSO2Q7Uy7Qd7vDJ0iG/NvM5ezRLQHrt/HfC3yYaDr1MaxOXVHtXsycZBpPhMD6I rnC2nZAKhbQrZzQwKDyr0E6w39QOxw5quQLOd05WqZyhnpuDlCAYTS62mD88nf9M9IQoy1Q7jCdh c2VsAlUCiopRFd97la87nACLpfNSpekdJKsNzbjhepVsxV7NkDw6CrnMAc5z4dCpHDqlAyYXPABx yyfKhk2IXI6IpnuomLJWRR5CUUgFEAnzZNtUJHS1ZxugOvLqpdnpulSVWnApxAorGGyuPC0ALUxF CniztfuYfgCmf0BrUl3cs8sWUl07HwWMwhqWoTFcJO2ociIdjGZir5O7h/fHTdh5C9JZGY1jSIkP MsNEfzGCJO4A2FJI2bXahK0x9TDDLV/witFvrbwqOTaa+V9HoJM2VwqsUfmz+P9VlbXlIQVXQkR1 bU2hxCug2PfSVA6q6U0PemLWC+ZWWkMK+D5lgSmCDrRDhxi2z5b4Ei8KCBdPSnumSrISoG50EU3J YZgdLr70vbZ6ubYpfEK766UR6eIU1pl26FUaLdDHovl4a5leiiy2pWgG1T/BFlpqZzDa7PiXR4vR kJ7uHk5mKoiit9/0cYbmZGr7tpmQPpfuDEBWbUSNIHHJspwaRPtQC7oHxPRLIxRJWVHqiBaCasWF Y4fNsdWjLH2YbbkbYt8QFzDE/e7Ubu8Jl0tWul2LzP4kuhN5B4NlmapDBP2pQt7onZUnrZfv0z8f NSB313amat8Sb5fDkL4z19C0WfFbJrAVi9HzseAkAogJ96lGrrmM3uvuv4fYx+QSmNxwbd0mb5cM QZlsNHWX7OBsytbpVcHWEwnLy2IV6bynNrRS3ihZKqIE2JOr0LgOm1/81GyrAwC8Lycqc8DFN9qS pdJpFgkrXh9eDZ2N+Zat3Z1wjrVcLTKm0qTmWVrIv70UcpmaAlgMG27RhzxhnPArroAGqU6jLQI6 t7e3x00+THPDVu8TcCUEpMZE3EBfQFuEC0HKv9vCu4DdRSTWy/tI+WJpIhcx310p37odrx1A/K3/ rUq/Pn6+vphMzr9BZ3KHWjGGXBSuQokF79TbwWnbve50F9IsFN7UTfbo1srrbG9shXWFzlmVvSzt Y1F+Xtns2rn/+EXQe4BwVhfPx+D/2skjRWS7aWjps36wft4MptIGawT3VQMIt2sfZiocJsiUfZhk fK7lqn8+utVwm7gO7I7aCrevdX6I/JgWCWXOxsP8VEr9n68PEB8ejr8h5+108Dt+/wWfu4+gZW5k c3RyZWFtCmVuZG9iago1MyAwIG9iagoxMjMwCmVuZG9iago1NyAwIG9iago8PC9MZW5ndGggNTgg MCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyNVk1z4kYQvfMr+ha7ChMDu+uNfdpd O4mr4i3WJqeQw0hqiUmkGXlmBCa/Pq9H4kNAtgIF2PPx5nX3ez16pevRmK7l3f2m1eDH5xsq/OCa fsGnGLwOxnEBdT9pRZ/nWPSRxhOa54N235gmU7q5+UjzanDxaAI7w+Hq3qk80Mnr/unp6plf/ekM /cyJa5Tb0OR6/O5y/tdg+hPNfxtc7BasdVhSZRNd6rCh0BjDpafFBY+K0ZBmT4+z1YdueHE5pKyp S52qwJc/DMbTPlTVlAFzPpBvEp86XQdtzeLCLy5Je6qdNUzBUsLkOGW94ozC0tmmWAJtj5PpPGfH JlBT++BYVVSrsPQjovmyBUpKrqhSG1Klt8RvGodaB+QeUGUdk+cVwEgbUkAGnk6agJN3MbNZaVCr cOAI27sEvcdpyGmjHcuMx8zkwzbeTzkKQqmtauW0Kc7jVsqoIm4mVShtQDHFP06V+h/OevnLuC7t Ji4FzxdOJXE0JWUyzEkqEzkmLHkbvD9c+G7YhR0kPb4b1RnwdK7Zx425LUu7Fhh3ENZtL67nh2/j W+jp++H0ckyPs92aIUGka+v+JpWm7H3kj/oGOdXbshFesX4rkMso2ZxRkaiZnn5/maMwCqESMpbn OhXlqJXVmQygpD6C4gtLtgT6zJRJlxBFrvBxtopZsNBkpcrIike94LvXkw16pYTpbSu3g3SJjKt2 PtKntHFRqFCpyaQm5wLaJoVXXQpu4S8lpoiAqfXhqk0Ve9u4lK8YBkARV2KXfkypShFFatERUL1h 3CZxybgkZGvcL/dfcYBnJ5ki5frG6AkWBgpLFYgBQQ22RK+YDZU2jXkAuBHTpqX1p4zE1DaPJLrj 7sAiwelxSBcGGgRCKIGoXAF801QJfmzeR4pVZDIWko+B5RAs8qPKEuoFrUqUI4wxpNqKy1np4rIP 1Kmitho5EnK50mWDJqDkIxoCyElD8BsfuLrrQy0ushgJuhCgjnyMiFrnYncrNlSkzf/SVkcph3mk EyAsyWu5N1a7cxjJVTroIopL6H2nZpFrX78nYlVZBkX5zv+7xjF7GaOxv0zka9oqaPby7qgfxZ7T 0th1mdFxr5igV3ze1Mr7aNRO51el2qC6u/h8U9fWHXUNMfm+Ixza/T9QELf4RVae81gi5fZex4Zh oaEgUsaOkTi6z0RMZ5ghgqHoqk+M31RVlzyk9ZJFIZ0olzAp/l51yoQhVN3ehJ1BcOKRU23N7e2q KF0qU8Q7SCqBjtmV5jy5I93IDdfSPeIUe5jrwNF8INA9NCkZOTaY8A+2YNBwW3IxNAQ13PKrsZ9N Gm0NJwlaHyfXJQ7G1PA4ER1ChNTSD7HONTUki1B/tWu5i8+Y/jB+dCKB6MtAKoaSqnKtNtvi3R0b 5KB/xJZlcUvHxuVDZIfHoFbuJ2di9ZmkJ7y/qsDKxqRFPlK4xxhhkIrsqfVRDMstKE9fkGSF1hFU 7DrgIzo9KBa6G7Ke67f/cSXx9gqShMfOe3pJ4bzWTue8Eh+LWO5ULcu3F3Sbmd6UWAgndLUA1vtJ xPoCyaE1PmQjeSZkiX7UgT+81eDh6VNTNBDBFL1GHj2p//pjhnZI4/GfwHyYD77h/S/YsXmEZW5k c3RyZWFtCmVuZG9iago1OCAwIG9iagoxMjE4CmVuZG9iago2MiAwIG9iago8PC9MZW5ndGggNjMg MCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyFVl1z2zYQfNevuLfaM5Ji+SNO8+bG SuuZOHFk5qnuA0QeJTQkQAOgPvLruweSkim5Y2k0skxwsbe7d+AznY0ndCbv9jstB+9m17TwgzP6 E5/F4HkwiQuo/UpL+iPBog80OackHzT3Tej8gq6vP1BSDk7uTGBnOIxuncoDHb1u7+9HM372x1fo M89drdyWzs8ml6fJv4OL3yn5MjjZr3Dsbe1S9jTfkueC06DNgpShuwdSWYbrnqyjynGuN6TS1LpM VgR7+ttgcnEAt15yWLKj0s51oQMg66qyLpD2ZJgzzgCdyV7GBiqVNgEf4AHsBUxqUfMmkAoEuD2a MukSZLCLkQuOI67FLuky4o+Bc/6+I5Uscdnxc60dl2xCVxCqFdjK2XnBpaeHx6tI6+HxPWXsU6fn IKpNr8JHkcYauuzvMZt+v/hIUGsl91aF3cpO/XLgEHlb1HK/p8e/vv34cktBuQWH5kbVEdKluNXD OdKYzUo7a5qCwLrF+/otoTkDVhfWgb6vONW5TlVRbOFW50SfGXa/HKJSqpQLOq0L5eSX16FWDdt1 lBnMVipwXL9XsY8FLu9gztebxJPCPbU/9KN93dsgaID/eGwRrM+tgymgLJos2LBTxWtCWKdxRwQi m9PdNPlMa+t+jhvF9ypKSgDKnpEblFfqbNTnjs0KaxYjdFpJiJj+Zc2wyVk0CAC8gaABwmItdM6V pNzxYXDL0ko20UDBZmr7ViBXVmeN+bUxjD70ymkYBqCq4I2EXvywxSo23ZJ7QuwSjDW7fEqprbHr pUZjrHVRxH4DbYX1UgHMAWrJEK6tQDhIraMuOJSzCjVUOwr8JQI/3WgfR8WuOUEm2NQWB7G46cWf 7n88JpRr56PVXmeYFo5r30ydDDIHNnHCiJ+j13z3AQsVxtAvuLHbFdWJx23ut4JgeL2//mYUZyyi IEjclbZLlPgvZhPnEEa3nfcat0LmJTtn3Qg7G37L/xC4rEJMe8xCtEEmmRDp8e/tlvGKC1vtZkAc hrF8/KUxri1UDFoV+4gAb84xRLrkLv5iQV3utP8/3vD8Cp5/slEaNikjVGHZthjI4ngSnXyEWVof DkKQoKpeDEq17YRA51nPQ/BaLIOcNRjoOBd44aIxr6mMy3Zv03ECdzTkFENc0p/jPp8ZLxCgaBZ0 Ec1f7AgToe4w/vs4u/ODlu86Km3EaYTZcWuFeTGM/BAT/FWRhLSzNWaQTAQVokjQQ76kfbWMhGj5 Uel9oH3m8QhQOwmHpHdIql9Pe3JEgip11h8QynSeI1fYsPN3iGR5r+eYULbCXJZ5iMPLM84P/Dio J0OyQFRUXTFlVs57345VHEt2zfFRQHQOroZ2jovm2Fnqqo81BwFuTv3yzU5+OlFPp+JJJTPfYe85 IrCG4z4OVizrHk9sVBqAV+cR8JNM7qeTaTZ+OoVR6K5i3O4w3VRIq6ebeiFcLybD+FhF/dffD2rB eJj7B5jTZPAd7/8AtRQYN2VuZHN0cmVhbQplbmRvYmoKNjMgMCBvYmoKMTEyMwplbmRvYmoKNjcg MCBvYmoKPDwvTGVuZ3RoIDY4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnichVZd c9s2EHzXr7i3xjOSYtlpnOYtTZw2M3HzYaUznaYPEHAk0ZCADIBy1F/fPZC0RElJ5PFIooi9w+7e gnd0Pl/Qufz177qZPP54RWWcnNNv+C8nd5NFvoH6N93Qr0vc9IwWF7QsJt26BV1c0tXVM1o2k0dv XOLgOM1eBVUkOnq9urmZfeS7ePwLveZVaFXY0sX54snZ8t/J5S+0fDt5tLuDv9qYrCsJBe59+BJJ OUOVjwmfApPziVRRsE5s8k/aO9zfMiV/9tNkcXmAV7ROJ+sdqUhtbFU9zas+P1p9PiN2alUzWdnQ zPhGWUd+zUHlFbYA4B6U4WgDmzmuXjwdyiwrGynwXYufGnZozpjAMXKkVDGtg0eFht7fXsl6HewK faPMLXdtPZn3RT5ef3j6nOR6G2zayr6iNX0vcdzJC+GYoq/bjHHz6XZJf7xbykaCN60GTXxPcYAK Nn6JU/LhFEGqWde22O6IP1yWKpVIKyfMr5gam2yphP3VdtzVMULDulLOxiaiuHCRvPZ1HDPYv258 spu82ef0pwrWtxA8JaVhgdjqSgS0DcSJ3uXbpiDUWVWTL07tK3LYWM1TapSbWTeDGrPGGgO9e9jO CdGTYDVqK7urFfxSsRnvDHqpTLnhde23ovMcZsaerItJOSmjYJi65hL0NKAHRjUsqGMklOZmnWBW UlrDJwDunS78bKwRAlEK+C/AeMUBvIpGsOmBC7IwCjVqqzNduSSUosKHkgW5bVYA8AVFWzrcB+wG RVXJR1it2NjAxTprmDDbhdVUBN+QxfDtbW2tUjUfr38Jj2IIQEy9nWbnxzVrKwi5K1Al71E2fl9Z yCn39EUOyN41ApP1urQOo4AdPUg+6NuLOQUqB1YH2+oI7Cobn8MDuGw3LPVtGDoQtrX2QdjHBsYg J+z8+MHLe6r1gkogBV9PDy2UuBQUOKVFbYSW7m0s332w//Vfsb7A4OMGCJYOm+GEZmPl29pkXiI4 AqfSDwjLrIpRZXmy2LXKObSV7DxwYg26zPYIQZVKTP2NIB6ujrEav7LS627EIVRhXRd1b66Xr0Hw X5wQqdAQDjXWiJHQ6QHVQ6TZfuizx3nDbkhTBIC0LA7AFXw43dH3NZODpO2yv9s5FIRjW7GCBXXf wOopyioNqbjbyah5rdp41BSipfNGnUvv48ohEX9wsqyDECHn4LhcN6J99HdFd2l4UHMoJfytsZvs snorOSbd8E5KxCZiotmxsaOvG+BGfeG9QAREgfmzUmXFsn9Uq1VCFjXDVIq18TXnix8U3dMElMqh I/lFoFVR7WPnOyQZB2RcD9TNtVGuxHkwRWldt3kGYTrEsUREpUIzVEEv4YBdHLdXOG5v2loGEX7/ 3nkrdN/+/u7T21fDI0PzsG6QIUfbShjZcA2b5qFSG2/NqdNpyHzMSG86LSLs4Q4BbLhGXIXtDw/N 62Fgdxh76lRqI7pgkB4eEk42hic6MKu9nDjdQVBxfvIpXT9z8GSBqMWh92CWMVuDpnjiAJjDyaFM L/nJbWd9vZsdRPdaTpuaoHruQzwh1Y8YQrS8QWChSDcWORvHWIO2e4tZBdg++m6Qx8A7STHgY6QV p46fHnBvG3gqkQGy7nSbwPn5IpP9EoGEB9BrM/98NkWgI4rnPfz11zWmPdKLtmyx9HIxzU/KNH79 /R6TSYvLf4B5vZx8wN//A2TD9GVuZHN0cmVhbQplbmRvYmoKNjggMCBvYmoKMTI3OAplbmRvYmoK NzIgMCBvYmoKPDwvTGVuZ3RoIDczIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic fVVNU9tIEL3rV/RtcZVRkHFiJycT8II3QLyO9rTew3jUkgbPh5gPHP/77ZFNmSFVwUUJNNPvve5+ 3X6Gi7yAi/g5PrnKPqwm0LjsAm7pt8mes6K/AMcHV/C1pEtTKEZQ1tkhroDRJUwmUyhVdrbQHq1G f35jWe3hl5+bh4fzFT67X0/gT9zYwOweRhfFeFA+ZZefobzPzk43KpTiBenG+swF3gJzUIVOCs48 ggrS01/Ogwsbx63ovDDagTc7Zis3+CMrLt/h+RahMjvtvEWmwAetUQJqL7xAtx7kAGWbIBsZelRC e4PjWhNkFeE0sBcjKrBImIJ7oZueRTHNGlQEDaYGJiUslinGicRT5WrBSTgwcIQgEVoTD1prQkNp UyGqPukqxVifHVJYD0DEPtSMIxh9wj7nrGMbwmOco3NAeHTN5QQz+vRanLIVdILPQdiDYlZVlI9D 16fSWUMIysHyRwFMV/SckqBY8Q1WRJxU+gfyWDAYR45jQz/l/ftghd/DNVVTVGjZa11PQpYSmUOS UqON1ejbJRwPzkXIoCnsBPRWsdCvxImYj29ETEjE4urx6ncCHo3GU8SUIugy9XUTvLHut0UjZxoe DmIcdezJUEcA69pYKqgy5AtNx9SA1Jkds9Qq0bEIsTN2Gx1E6TDwZNGoWcd+iL6ox5qw4FvSMwRk NBSmPpoiHtVGSrOLGC0Ni2IVQj9ATjRakMlYbC/1UKiOhMX/+GuGb2ze84iDni9J2tcts5KMMc9h iVFsms1dYDsUUCJvtZGmoak6Qs4VE/IL8BgvsJtxo7roxdzYJmF4oJlnhECWY9wk6FcyzoA8vw88 1vkr0ljds807Cn8MzVVEmjXGNPGFkDlxJlRziZrBDR1awRKmSE+3YeGZ7I/iyxfSdZvDCgVN0soo I8UQRpPxEMrvq8Xj9yGtzWI8HfZR+1QURqq8OlDN/AFe9Oi58Imqv8gr53d7E7Zwj5gOF9ON2gfq 7j86LkZHczCEb4a2WUr3RBhthJg5FXLG861NOL7ReiF/LOPq25IlRdrG+eK6hFu1uUtRt3l3Cpgh rTvKiK58HPWB5A1NK2le5esBeZOMJvPjopr/7GhOHFyFJtBiuyyG/dJ/94Xw75J2JhTj/whzXmZ/ 0+d//p3+8GVuZHN0cmVhbQplbmRvYmoKNzMgMCBvYmoKODY0CmVuZG9iago3NyAwIG9iago8PC9M ZW5ndGggNzggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJx1VNtS2zAQffdX7Fth xqhx0kLokyEJEEgYmrhlSunDRl4cJbYUdAmlX185F6ZKSjwZX/acs2e1Kz1DgyXQqK/NnVfRx9EJ FCZqwKX/F9FzlKwAsLnxCs4zD2pD0oTsKVrzEmi24OSkDVkVHfSlJS3JHnU1PlnY+3WHw6MRPZv9 CFzQRDvUr9BsJJ8Os1nUOoVsEB34UKYF5wLG6vBDlLS2Xx+ynn+vn3oVivILWKPSP5acQcZV5WPN 4y22g7pUBq4ZnHt/qHNlAq1vUixJG5FjvsX2+33ICYaYa5FvEp0tWYCNodWIYUAFSjLxBgvN9mmS xDBeoJChQz6b8FRY5nirYmQCi3fklw6GvINSBt6uHL6QgIz4VKpSFWJF/Ed1xWRrZjpdofcWYExq DtdKwY2aBuo3r04WC+Wjt2iFkli+FWhfYw/XhGE6M5uraTqXjiFncx2kuScJA/den24VO27H8CBm QnqfMOrGP5x/sCigK4z1bbax9yF9vIjhWqAsjINm0mgkzRg6UyF3vJROsReSddvrkhmXYdVawKWT OS6pLEXgqiMMVxsxU6wxKa8/7q3dlfP2SBYhvzYDQzURJYWecg+dOpHyGlGtAHuSQ9RcwUDQxPCw H7e9DgxwojRapX2roee0WuykKNfEVBIvccLI7Q073AtfMVbhmA8741GtvjNA3BNe0oobfeTlDFO6 2BkeUcI1qXAu+9JYYZ1V9TbJqCRfpJOCI1f1ZjhbktBqZ3S80MzrpLhkfhss7E4aXQgFF6Jwnkq5 em+LUp3xv/pPb9x3UlhRwHeSiOHCbPk+nC5X4U3LPjdXkM4UJTwe9HL2eBgDWcCSbc6t3u+FT2jg zBXOWGj5nV+fYDun2887LAiSz7+8Zi+LvvrrLyLxhNBlbmRzdHJlYW0KZW5kb2JqCjc4IDAgb2Jq CjY3NAplbmRvYmoKODIgMCBvYmoKPDwvTGVuZ3RoIDgzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2Rl Pj4Kc3RyZWFtCnicdZTJUhsxEIbv8xR9C1Sw4rFTLDmNwQ57hcCkUknIoZmRZYEWowXw26dnoYLs xFOuKUt/f73otx5hyHIYNk//rnT24XoPhM+GcExfkT1meSuA/lVpOCxJtA/5CMp51sXlMBrD3t4+ lDrbOjWBO8PDYOpwHmDjM728HFzzR7+5A5/5nYvoVjAa5h+3y/tsfADlRbZFWxdReriUInIFR9YE xx3SQnRSKbv9LsvHr8qSKz63RlYIp++ntNUszjRK9QmUrnQRZM24p43R7mvMWUQDR+iU9fAzGikw QbYtTaWQAVUKbAK7ONbFFW+1rLI6yTNR/AVN7SJccWrBVzHJ00PxVcWWvaoQzc4G7phbJyTVfI4O hURjpE+A34x84s7LsAI7h/KZU3FpA4I9/I0tYmglzKi18SjJDVygQCO5S1KcUdvLdu0N9b4NYJKH +X9K/47eS00nWi3oRE+wrrFOZ+Fk5b01KbgLY52+4L1mgz6V7gGerIGTKFJ3THkMnnK2Nnmwmpq6 sw6DdbL1xJtcDYQRZNBAitDpWc3TE11orMmHCxpgaprJM7oabqyKQVqzxkavu5BihQtrNxo4XNlo xODMwrnUKbYsm5rXeBorfxdFQW7h6KoFwxA2oCc0PPL5RMlBW3bC/eLQiDVzLNoAhkpioy9sq/mH q8kA8IMLaRLkDWpPXax13ojZqhEXS3TB0C/fCXtw/6c/YADXfM4dN1V7NAd5u35Ec4PbrVnNbrd3 gAcisv7+mL0sJU0AJlFEH2Cc77Q3ydot8+sKBYd89zcxZ2X2lZ4/iDFq72VuZHN0cmVhbQplbmRv YmoKODMgMCBvYmoKNjAzCmVuZG9iago4NyAwIG9iago8PC9MZW5ndGggODggMCBSL0ZpbHRlciAv RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJy9ll1z2jgUhu/5FWe42WTG8mJoQ9i78JGUNqQssNPZ3fRC 2AdQsSUiySH01++RMAmsofRiZ+1hbGPp6NWj9xz5CWphBDV3Ftc4q/w6asLcVGpwR7955akS+QZQ XOIM2hNqdA1RHSazyrZfBPUGNJvXMMkqF31pUUu0rKv5zELp6A4GbIRPpvwGbnGqc643UK9F7y4n 3yqNFkzuKxetMAoBHpTOuBXPCCOcoUYZo7n8pVK/8m2o+9+j2049ilpfAdqaJxJ1AOMwgOon3MBa 6cTATGnIDYKQQI0NWAV9mYiYW6RQUWMXau8grbnQmKG0cI/PmJpqAO3OEKJ3gQsCbsgABlzHC4ha rWb4JqoV1kl4X86OS/ei+6wbThdcJlwLlixiFqfcGDblBhO20jgTL19PaWsX/bbz/MDTNTeCB3BH T3c5vSK5afG2i3JObcKgGHjvmCwETnluA7inhp+UXiiJMoCP9EQDQD+EW66141ntfugMn6/AiyxH 8qphq5owJc4C7MzsWO19OdDjBS3Y0q3TSqu5RmMeL0lQnnpzNMLDhXcMl4VsdpVxuQtNnVeorUBz kuHhdIe0TCmt7xGAYxQWqUUBpRuWVd+LnBD1HaChF0CXnYDqEfBbPmeUs1r9DUc5xs/yWfOlWPI1 Z5Sb+GLZKhMrFq9YvmIGV1zTxJU8SelL0Zss7yl9X2y4lLnePjse43CfWFlndfw6CqgZdJS0WqW+ 6x8GNQxTLtEnKDF72cBATUWK5TiO7qu1fmpSrFb7Lwy2UUtlOUuyjJkYJRlancT1p2/r023fN13M qBv93yug/RVChyvyDCGAmJKiLHQ31rZ4dYWxWkxzS2nmCQlLqLjkc1+hTpvsiHrichxDOcbn2Kop LRKhqf0LzZCTT9merrBDQjRPxXe632k8XcKcyeUWT1vJbyovqrbD85ENQvevdC2qN/uzL2skOnsj v9IhrzhHxYiJkHPjvHeXqilPyxE6Ksty6XYDco1xFi2KtbOL64TUwtmkizFmWx611lke3Y3kmYj/ TxbFkMcsAuN4QTc0ByPmkkA5W92m3FJmlQPd0K5G9o1trl0JK6FsaNoe/I7voR2n+oqRUv8B1zDB eCFVquZU3YI3jb6KYJxrejiWsA+TwdjRJ+jXZ6HvooaD/vAk8A7tTNskrZ5JLFgLu/hBTTqCpt/r 9Q7ZHBrsh6QeL/qdzuMlfKHsNAu1cugmmGJ8YNHfYKZVVg40QoP+e4S+b8bW776JcdWNKiylcN3R e1/3QBwCGq2XhA4tWuBpWETpvazow8fATT7PjYVGFPgPs8OhHPs5QtR0kHuTyu90/gPKXN1kZW5k c3RyZWFtCmVuZG9iago4OCAwIG9iagoxMDAyCmVuZG9iago5MiAwIG9iago8PC9MZW5ndGggOTMg MCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyNVtty4jgQfecrunjZpMp4MZDbvGwR biHBCQvsZFKbPAi7wZrYkiPZMPz9tMQlJJipmKIsbKn79Onu07xB1fWgaj6be5CU/h5dwFyXqtCj 77z0VvLsBtjcggSuJ7TpErwaTGal9TkPanW4uLiESVI66YsMlcCs0lZslsHB1fb9ygjf9OEb6OJU 5UytoFb1GqeTn6X6FUwGpRN69f+Qpagqba4zxad5hqHryymPebZyh35/+HL6V8mrb3fvXa2ICQdu XAfKQyV/rcAeQ+gPYcmzCPYswtYi2fpkpSmCSCpddgDISoAYcjHXIGfQi+UUWzKBR6ledSRTAClg jCyJUetDS49coXmzc+ZAGwNMpqhM2FWXjtTOvxL2CBccl18I/Em+yoyt1z84OnBLizHyjJZDWjIR QtuFAc+dQ7zlfYLszpVgCQ92+MFngs0xQZEBFxt6D+1sy+IbtHKlzOZmmirJggi1tdvXOkfL8K3M lWAxsXtohphOcsEDlnEptAMLGbtw7oCQLngOpKkLjYp35nyoJe/rpI6bnaOMdrmOUDngE2dNEaLS khju0q87mWqM6akhNojYzGzrbaj13cMwaFNMpNGucvNDCVJZ7ojdEgQzqaDeA8JWLsjQ54rMIgTv ikp7Tbllitgcr5JUap4nVJ+HRoY2GkYx9EUoyZ9Fvm6VEQu5/MQ8PJ8M+/6o9XxagKhWrV4WUj6Q 5riYu/9pVEd5vuNqulrzV96esFGZU6ZAPkA5VmqbuB3i4uqsEI3P52oN50Ym6DbnVJX6KKpH9spf 2ZL6aETAvrOYhSb92yzfuuDninHCvLMLxm6BmFhHMJFLpkK964yKDhixvUt/G9NYrkxf6a+mvdny oUZgWvK+82NCN0GViCJAK0rdPMtVAZ57zJYkXgbwBINIyFjOOeoPwlQ9L6bQVojbZhlzH2azWDKD 5yiHAyTJuSPG7MLI0BMR9kT3UWSe9Ddkjl2SLynmhswjemJcwrvLb8T1kjJA3dJiglS2ywl+zBeo /jElM+73Wg++X1SrXtUpUt5Rt1W/OKu/gBE4YVqVUrzuZ+r3n3KLzaRqhDEz3TtBlXDL38qmrJAE MgzGMhnMBRpuG4euz2qecd3LRcgWGMdE09jylhtWDIVtXDDFUmbffacHxNgyjHK1su+PeTcRXLsw pAKND2fi4pzIMgCNf9KzfJ7rrKifDcT6ZZUgjmXMk+2oaTGdEdo8CDg1SouedGKfxa98jdk4H7jH oF2bOK0m3tCNqSCiFo/3wZHq3Phm8Xz6h2H9PpC2wRBSBx6CTG6KuSiaq0bjxeogNYJeYy/vq/E4 T1OpMivGBKFBpmkAawz/nGlj14F7uTg64mnXea1mnNNUSHiYOTAh548Mo5jrIFoPnE1b3CkaQsLQ Xb5mGo95ftcOi9fP44y4pFQOaNYgVfMuHBrZ+zVABs9q1qD5/0B8d0KXNB4wA0aTdn11fqX0L0Zv y6Pu2QZqfIRgJGJOk+jSqEFnUvqXPr8Bbz/NpGVuZHN0cmVhbQplbmRvYmoKOTMgMCBvYmoKMTEz NQplbmRvYmoKOTcgMCBvYmoKPDwvTGVuZ3RoIDk4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4K c3RyZWFtCnichZXbctpIEIbv9RRdvoldJWt14GB2bywDJnHAVkCudTnsxVhqpAliBo9G2OTpt0eI zRLCLoLSaab7+3v+Hl7BdTxwzdGck5X127QLWWm5MKJfZr1aXj0AmlOygpuYBl2B50O8sHbzPPAD 6HavIF5Z55+ERiVQXw4UW2g4+gwmk8spvpbHb+AWX1TF1BZ812tdxN+soAfx2Do/HPUp2nRgfh5N zMX8AgZyxbgoz2yY3vah4/stG8K14oUJ4zkXHyy/sw/zlYZ0/G77L4AI1ZKm2dB3bLiTuSilsGFA N0ykcOdAqJZLacPZRL7wgustzKr1WipNAb3gF1xc1Gj/cHTbFLcqtqcwAtcjjOe8suGZsv7JlnzJ 3hhNbxjGDr1lIiOGkJKrDW5BLmDPc4qjwTQ8OkfYr8eei9L+N1fXNeX5rHiZC0YlmRHOZynTgu/Q xrJSyBWVJjLYhP+lAQ6dU0yDSmtSdjaWCSv4d0xhKivNRQYLqSBS8n2704VNDSnQTyFqeGIjIFxr XL2gMgr8XyjouT1SMKpEyjZYGG6j4TmXxPpUq1G5FEja7ujuFnmGNowaEdOTIvZFOCPEFsRk7wVP 4GGxKCRLiarARJOah7XmUvwQdizlQOlOGCH/y7XBT6LimeMHTosMc4otGEURkY1QoGIFRCxZooYp S7kkMrXhCVLPjKLpjDoGBdkqwRUKXR7TGfDhRhYbWqVHwTeoSooYo1JYasXpehc2TBIsS7hH/SbV 8jjO/Hx4+RhPw3vKyOqxJNZwQjyFnRzaVhz6ujZMmEryU9J7gRv8n/LdLgD3bIUw25ZkEFP9BFMy a/kHzDTLEIKG4Bh2h0R5gHrCN0THLmt2o7DSuVTlBwjTlGKXWB4Qf4RQ0ACxhT5VmaqAKSdbzC8O BHys2BtyqmqSC1nIjON+JdpBy4UxZizZwkA5cFPxIjWdElDDFUxQ38VP0G27Zp97nIXNtCHJL36H 3GFOQnmvOSI6UmU/uE0bsjVSpDGvDmD6ORescWUTjhZe+zb4V/BUMfFWkVfeOYQbapTdAxhw44ZE 23CD/JsB9FzXbRNlHe4Qq+BVWue+TszLVZ3KSeTqAC/iZDKeLKn2XOMB4oOijXAPR8JVhZBW0C9k CX3akDQWBBJBz/P9DiHQukhxOcMNzwSte7vtkZpbZWx/SLZucjqlyXkt6zwNmee26vzNQg5TZ35h A/UVK5zGN8P3NScTQFhlVakhoL3V/Hkdmgu+RsZ9Xs+YeBhbX+j4G76Z8qJlbmRzdHJlYW0KZW5k b2JqCjk4IDAgb2JqCjk0OQplbmRvYmoKMTAyIDAgb2JqCjw8L0xlbmd0aCAxMDMgMCBSL0ZpbHRl ciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxlUE1vwjAMvedX+DaQaNe0fG0nxtdgwMZYL9PYwdBQ QpsEklQa/36BdZoYsSLL7z3bTz5A4FMITlHmtSC3ixakhgTw6H5KDoSeBVCmtYBu7ERtoCHEG/LT RyGMoNVqQyxIZSwt05JZr69xY+Hq9Wczb8EO5pqBIVvpAvURwoDWq/GORHcQT0nFUSOeMKvMlsO7 ypTF6g2h0S856ffHMMWVA09l6FGPNuBlixprMCx2XHCpavCG3KJwUNRoeu1GEMIT7lGWXQOBPL+H 43l8J0sSnuPK+Lu94/98PKlCcpgovVWSyQsXXa0wWSsBPSWEU63RciVNOX6udJZhjjJDW0BYd8bG z14Q0HYAI5YbLjPuMC6dJLm0tDvt9KUyexSd9IT5bo3TNOrN8/LeFiUsK4PEX1ZrwCxg7pcnHXzt uWYGHoq0MBYiWjsf99/hP+aYMkd8uqGDmLy6+AZnp4uvZW5kc3RyZWFtCmVuZG9iagoxMDMgMCBv YmoKMzUxCmVuZG9iago0IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJd Ci9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0K L0V4dEdTdGF0ZSA5IDAgUgovRm9udCAxMCAwIFIKPj4KL0NvbnRlbnRzIDUgMCBSCj4+CmVuZG9i agoxMSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAv UGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUg MTQgMCBSCi9Gb250IDE1IDAgUgo+PgovQ29udGVudHMgMTIgMCBSCj4+CmVuZG9iagoxNiAwIG9i ago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMg MCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTkgMCBSCi9G b250IDIwIDAgUgo+PgovQ29udGVudHMgMTcgMCBSCj4+CmVuZG9iagoyMSAwIG9iago8PC9UeXBl L1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNv dXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMjQgMCBSCi9Gb250IDI1IDAg Ugo+PgovQ29udGVudHMgMjIgMCBSCj4+CmVuZG9iagoyNiAwIG9iago8PC9UeXBlL1BhZ2UvTWVk aWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Q cm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMjkgMCBSCi9Gb250IDMwIDAgUgo+PgovQ29u dGVudHMgMjcgMCBSCj4+CmVuZG9iagozMSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAg MCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9Q REYgL1RleHRdCi9FeHRHU3RhdGUgMzQgMCBSCi9Gb250IDM1IDAgUgo+PgovQ29udGVudHMgMzIg MCBSCj4+CmVuZG9iagozNiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQy XQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRd Ci9FeHRHU3RhdGUgMzkgMCBSCi9Gb250IDQwIDAgUgo+PgovQ29udGVudHMgMzcgMCBSCj4+CmVu ZG9iago0MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRl IDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3Rh dGUgNDQgMCBSCi9Gb250IDQ1IDAgUgo+PgovQ29udGVudHMgNDIgMCBSCj4+CmVuZG9iago0NiAw IG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50 IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNDkgMCBS Ci9Gb250IDUwIDAgUgo+PgovQ29udGVudHMgNDcgMCBSCj4+CmVuZG9iago1MSAwIG9iago8PC9U eXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9S ZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNTQgMCBSCi9Gb250IDU1 IDAgUgo+PgovQ29udGVudHMgNTIgMCBSCj4+CmVuZG9iago1NiAwIG9iago8PC9UeXBlL1BhZ2Uv TWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8 PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNTkgMCBSCi9Gb250IDYwIDAgUgo+Pgov Q29udGVudHMgNTcgMCBSCj4+CmVuZG9iago2MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3gg WzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0 Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNjQgMCBSCi9Gb250IDY1IDAgUgo+PgovQ29udGVudHMg NjIgMCBSCj4+CmVuZG9iago2NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUg ODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1Rl eHRdCi9FeHRHU3RhdGUgNjkgMCBSCi9Gb250IDcwIDAgUgo+PgovQ29udGVudHMgNjcgMCBSCj4+ CmVuZG9iago3MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90 YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRH U3RhdGUgNzQgMCBSCi9Gb250IDc1IDAgUgo+PgovQ29udGVudHMgNzIgMCBSCj4+CmVuZG9iago3 NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFy ZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNzkg MCBSCi9Gb250IDgwIDAgUgo+PgovQ29udGVudHMgNzcgMCBSCj4+CmVuZG9iago4MSAwIG9iago8 PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBS Ci9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgODQgMCBSCi9Gb250 IDg1IDAgUgo+PgovQ29udGVudHMgODIgMCBSCj4+CmVuZG9iago4NiAwIG9iago8PC9UeXBlL1Bh Z2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJj ZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgODkgMCBSCi9Gb250IDkwIDAgUgo+ PgovQ29udGVudHMgODcgMCBSCj4+CmVuZG9iago5MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFC b3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9j U2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgOTQgMCBSCi9Gb250IDk1IDAgUgo+PgovQ29udGVu dHMgOTIgMCBSCj4+CmVuZG9iago5NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1 OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYg L1RleHRdCi9FeHRHU3RhdGUgOTkgMCBSCi9Gb250IDEwMCAwIFIKPj4KL0NvbnRlbnRzIDk3IDAg Ugo+PgplbmRvYmoKMTAxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJd Ci9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0K L0V4dEdTdGF0ZSAxMDQgMCBSCi9Gb250IDEwNSAwIFIKPj4KL0NvbnRlbnRzIDEwMiAwIFIKPj4K ZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9LaWRzIFsKNCAwIFIKMTEgMCBSCjE2IDAg UgoyMSAwIFIKMjYgMCBSCjMxIDAgUgozNiAwIFIKNDEgMCBSCjQ2IDAgUgo1MSAwIFIKNTYgMCBS CjYxIDAgUgo2NiAwIFIKNzEgMCBSCjc2IDAgUgo4MSAwIFIKODYgMCBSCjkxIDAgUgo5NiAwIFIK MTAxIDAgUgpdIC9Db3VudCAyMAo+PgplbmRvYmoKMSAwIG9iago8PC9UeXBlIC9DYXRhbG9nIC9Q YWdlcyAzIDAgUgovTWV0YWRhdGEgMTA2IDAgUgo+PgplbmRvYmoKNyAwIG9iago8PC9UeXBlL0V4 dEdTdGF0ZQovT1BNIDE+PmVuZG9iago5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjEwIDAg b2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjE0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjE1 IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjE5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2Jq CjIwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjI0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5k b2JqCjI1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjI5IDAgb2JqCjw8L1I3CjcgMCBSPj4K ZW5kb2JqCjMwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjM0IDAgb2JqCjw8L1I3CjcgMCBS Pj4KZW5kb2JqCjM1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjM5IDAgb2JqCjw8L1I3Cjcg MCBSPj4KZW5kb2JqCjQwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjQ0IDAgb2JqCjw8L1I3 CjcgMCBSPj4KZW5kb2JqCjQ1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjQ5IDAgb2JqCjw8 L1I3CjcgMCBSPj4KZW5kb2JqCjUwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjU0IDAgb2Jq Cjw8L1I3CjcgMCBSPj4KZW5kb2JqCjU1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjU5IDAg b2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjYwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjY0 IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjY1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2Jq CjY5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjcwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5k b2JqCjc0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjc1IDAgb2JqCjw8L1I4CjggMCBSPj4K ZW5kb2JqCjc5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjgwIDAgb2JqCjw8L1I4CjggMCBS Pj4KZW5kb2JqCjg0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjg1IDAgb2JqCjw8L1I4Cjgg MCBSPj4KZW5kb2JqCjg5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjkwIDAgb2JqCjw8L1I4 CjggMCBSPj4KZW5kb2JqCjk0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjk1IDAgb2JqCjw8 L1I4CjggMCBSPj4KZW5kb2JqCjk5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjEwMCAwIG9i ago8PC9SOAo4IDAgUj4+CmVuZG9iagoxMDQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTA1 IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjggMCBvYmoKPDwvQmFzZUZvbnQvQ291cmllci9U eXBlL0ZvbnQKL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKMTA2IDAgb2JqCjw8L1R5cGUvTWV0YWRh dGEKL1N1YnR5cGUvWE1ML0xlbmd0aCAxMzI5Pj5zdHJlYW0KPD94cGFja2V0IGJlZ2luPSfvu78n IGlkPSdXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQnPz4KPD9hZG9iZS14YXAtZmlsdGVycyBlc2M9 IkNSTEYiPz4KPHg6eG1wbWV0YSB4bWxuczp4PSdhZG9iZTpuczptZXRhLycgeDp4bXB0az0nWE1Q IHRvb2xraXQgMi45LjEtMTMsIGZyYW1ld29yayAxLjYnPgo8cmRmOlJERiB4bWxuczpyZGY9J2h0 dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMnIHhtbG5zOmlYPSdodHRw Oi8vbnMuYWRvYmUuY29tL2lYLzEuMC8nPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0nYjEy NmI0MTEtZDc2Mi0xMWVlLTAwMDAtNTdjYmMzZDYxMzM4JyB4bWxuczpwZGY9J2h0dHA6Ly9ucy5h ZG9iZS5jb20vcGRmLzEuMy8nIHBkZjpQcm9kdWNlcj0nR1BMIEdob3N0c2NyaXB0IDkuMDInLz4K PHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J2IxMjZiNDExLWQ3NjItMTFlZS0wMDAwLTU3Y2Jj M2Q2MTMzOCcgeG1sbnM6eG1wPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJz48eG1wOk1v ZGlmeURhdGU+MjAxNC0wMi0yN1QwMToyODo1NiswMTowMDwveG1wOk1vZGlmeURhdGU+Cjx4bXA6 Q3JlYXRlRGF0ZT4yMDE0LTAyLTI3VDAxOjI4OjU2KzAxOjAwPC94bXA6Q3JlYXRlRGF0ZT4KPHht cDpDcmVhdG9yVG9vbD5HTlUgRW5zY3JpcHQgMS42LjUuOTA8L3htcDpDcmVhdG9yVG9vbD48L3Jk ZjpEZXNjcmlwdGlvbj4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J2IxMjZiNDExLWQ3NjIt MTFlZS0wMDAwLTU3Y2JjM2Q2MTMzOCcgeG1sbnM6eGFwTU09J2h0dHA6Ly9ucy5hZG9iZS5jb20v eGFwLzEuMC9tbS8nIHhhcE1NOkRvY3VtZW50SUQ9J2IxMjZiNDExLWQ3NjItMTFlZS0wMDAwLTU3 Y2JjM2Q2MTMzOCcvPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0nYjEyNmI0MTEtZDc2Mi0x MWVlLTAwMDAtNTdjYmMzZDYxMzM4JyB4bWxuczpkYz0naHR0cDovL3B1cmwub3JnL2RjL2VsZW1l bnRzLzEuMS8nIGRjOmZvcm1hdD0nYXBwbGljYXRpb24vcGRmJz48ZGM6dGl0bGU+PHJkZjpBbHQ+ PHJkZjpsaSB4bWw6bGFuZz0neC1kZWZhdWx0Jz5FbnNjcmlwdCBPdXRwdXQ8L3JkZjpsaT48L3Jk ZjpBbHQ+PC9kYzp0aXRsZT48L3JkZjpEZXNjcmlwdGlvbj4KPC9yZGY6UkRGPgo8L3g6eG1wbWV0 YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNrZXQgZW5kPSd3Jz8+CmVu ZHN0cmVhbQplbmRvYmoKMiAwIG9iago8PC9Qcm9kdWNlcihHUEwgR2hvc3RzY3JpcHQgOS4wMikK L0NyZWF0aW9uRGF0ZShEOjIwMTQwMjI3MDEyODU2KzAxJzAwJykKL01vZERhdGUoRDoyMDE0MDIy NzAxMjg1NiswMScwMCcpCi9UaXRsZShFbnNjcmlwdCBPdXRwdXQpCi9DcmVhdG9yKEdOVSBFbnNj cmlwdCAxLjYuNS45MCk+PmVuZG9iagp4cmVmCjAgMTA3CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAw MDAyNDgyNSAwMDAwMCBuIAowMDAwMDI3NjAzIDAwMDAwIG4gCjAwMDAwMjQ2MzEgMDAwMDAgbiAK MDAwMDAyMTM4OSAwMDAwMCBuIAowMDAwMDAwMDE1IDAwMDAwIG4gCjAwMDAwMDExNzEgMDAwMDAg biAKMDAwMDAyNDg5MSAwMDAwMCBuIAowMDAwMDI2MTM0IDAwMDAwIG4gCjAwMDAwMjQ5MzIgMDAw MDAgbiAKMDAwMDAyNDk2MSAwMDAwMCBuIAowMDAwMDIxNTQ4IDAwMDAwIG4gCjAwMDAwMDExOTEg MDAwMDAgbiAKMDAwMDAwMTg2NiAwMDAwMCBuIAowMDAwMDI0OTkxIDAwMDAwIG4gCjAwMDAwMjUw MjEgMDAwMDAgbiAKMDAwMDAyMTcxMCAwMDAwMCBuIAowMDAwMDAxODg2IDAwMDAwIG4gCjAwMDAw MDI0MjggMDAwMDAgbiAKMDAwMDAyNTA1MSAwMDAwMCBuIAowMDAwMDI1MDgxIDAwMDAwIG4gCjAw MDAwMjE4NzIgMDAwMDAgbiAKMDAwMDAwMjQ0OCAwMDAwMCBuIAowMDAwMDA0MDI3IDAwMDAwIG4g CjAwMDAwMjUxMTEgMDAwMDAgbiAKMDAwMDAyNTE0MSAwMDAwMCBuIAowMDAwMDIyMDM0IDAwMDAw IG4gCjAwMDAwMDQwNDggMDAwMDAgbiAKMDAwMDAwNTUyNSAwMDAwMCBuIAowMDAwMDI1MTcxIDAw MDAwIG4gCjAwMDAwMjUyMDEgMDAwMDAgbiAKMDAwMDAyMjE5NiAwMDAwMCBuIAowMDAwMDA1NTQ2 IDAwMDAwIG4gCjAwMDAwMDY2MjcgMDAwMDAgbiAKMDAwMDAyNTIzMSAwMDAwMCBuIAowMDAwMDI1 MjYxIDAwMDAwIG4gCjAwMDAwMjIzNTggMDAwMDAgbiAKMDAwMDAwNjY0OCAwMDAwMCBuIAowMDAw MDA3Njg5IDAwMDAwIG4gCjAwMDAwMjUyOTEgMDAwMDAgbiAKMDAwMDAyNTMyMSAwMDAwMCBuIAow MDAwMDIyNTIwIDAwMDAwIG4gCjAwMDAwMDc3MDkgMDAwMDAgbiAKMDAwMDAwODYwOSAwMDAwMCBu IAowMDAwMDI1MzUxIDAwMDAwIG4gCjAwMDAwMjUzODEgMDAwMDAgbiAKMDAwMDAyMjY4MiAwMDAw MCBuIAowMDAwMDA4NjI5IDAwMDAwIG4gCjAwMDAwMDk5MjAgMDAwMDAgbiAKMDAwMDAyNTQxMSAw MDAwMCBuIAowMDAwMDI1NDQxIDAwMDAwIG4gCjAwMDAwMjI4NDQgMDAwMDAgbiAKMDAwMDAwOTk0 MSAwMDAwMCBuIAowMDAwMDExMjQzIDAwMDAwIG4gCjAwMDAwMjU0NzEgMDAwMDAgbiAKMDAwMDAy NTUwMSAwMDAwMCBuIAowMDAwMDIzMDA2IDAwMDAwIG4gCjAwMDAwMTEyNjQgMDAwMDAgbiAKMDAw MDAxMjU1NCAwMDAwMCBuIAowMDAwMDI1NTMxIDAwMDAwIG4gCjAwMDAwMjU1NjEgMDAwMDAgbiAK MDAwMDAyMzE2OCAwMDAwMCBuIAowMDAwMDEyNTc1IDAwMDAwIG4gCjAwMDAwMTM3NzAgMDAwMDAg biAKMDAwMDAyNTU5MSAwMDAwMCBuIAowMDAwMDI1NjIxIDAwMDAwIG4gCjAwMDAwMjMzMzAgMDAw MDAgbiAKMDAwMDAxMzc5MSAwMDAwMCBuIAowMDAwMDE1MTQxIDAwMDAwIG4gCjAwMDAwMjU2NTEg MDAwMDAgbiAKMDAwMDAyNTY4MSAwMDAwMCBuIAowMDAwMDIzNDkyIDAwMDAwIG4gCjAwMDAwMTUx NjIgMDAwMDAgbiAKMDAwMDAxNjA5OCAwMDAwMCBuIAowMDAwMDI1NzExIDAwMDAwIG4gCjAwMDAw MjU3NDEgMDAwMDAgbiAKMDAwMDAyMzY1NCAwMDAwMCBuIAowMDAwMDE2MTE4IDAwMDAwIG4gCjAw MDAwMTY4NjQgMDAwMDAgbiAKMDAwMDAyNTc3MSAwMDAwMCBuIAowMDAwMDI1ODAxIDAwMDAwIG4g CjAwMDAwMjM4MTYgMDAwMDAgbiAKMDAwMDAxNjg4NCAwMDAwMCBuIAowMDAwMDE3NTU5IDAwMDAw IG4gCjAwMDAwMjU4MzEgMDAwMDAgbiAKMDAwMDAyNTg2MSAwMDAwMCBuIAowMDAwMDIzOTc4IDAw MDAwIG4gCjAwMDAwMTc1NzkgMDAwMDAgbiAKMDAwMDAxODY1MyAwMDAwMCBuIAowMDAwMDI1ODkx IDAwMDAwIG4gCjAwMDAwMjU5MjEgMDAwMDAgbiAKMDAwMDAyNDE0MCAwMDAwMCBuIAowMDAwMDE4 Njc0IDAwMDAwIG4gCjAwMDAwMTk4ODEgMDAwMDAgbiAKMDAwMDAyNTk1MSAwMDAwMCBuIAowMDAw MDI1OTgxIDAwMDAwIG4gCjAwMDAwMjQzMDIgMDAwMDAgbiAKMDAwMDAxOTkwMiAwMDAwMCBuIAow MDAwMDIwOTIzIDAwMDAwIG4gCjAwMDAwMjYwMTEgMDAwMDAgbiAKMDAwMDAyNjA0MSAwMDAwMCBu IAowMDAwMDI0NDY1IDAwMDAwIG4gCjAwMDAwMjA5NDMgMDAwMDAgbiAKMDAwMDAyMTM2OCAwMDAw MCBuIAowMDAwMDI2MDcyIDAwMDAwIG4gCjAwMDAwMjYxMDMgMDAwMDAgbiAKMDAwMDAyNjE5NiAw MDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDEwNyAvUm9vdCAxIDAgUiAvSW5mbyAyIDAgUgovSUQg WzxFNjdGQURBQzUyMDZCQTMyQ0MwNzZEMzQ5RDE3NzJEOD48RTY3RkFEQUM1MjA2QkEzMkNDMDc2 RDM0OUQxNzcyRDg+XQo+PgpzdGFydHhyZWYKMjc3ODIKJSVFT0YK ------=_NextPart_000_004C_01CF36DF.E9E6FCF0-- From nobody Mon Mar 3 14:43:48 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBA81A02B8; Mon, 3 Mar 2014 14:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS3xwb9HQee6; Mon, 3 Mar 2014 14:43:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D45D91A00DD; Mon, 3 Mar 2014 14:43:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140303224340.31242.31409.idtracker@ietfa.amsl.com> Date: Mon, 03 Mar 2014 14:43:40 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/DAiLsiMnDBJpcxyVt1d20LpoaVo Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-requirements-15.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 22:43:43 -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 Working Group of the IETF. Title : Requirements for Distributed Mobility Management Authors : H Anthony Chan Dapeng Liu Pierrick Seite Hidetoshi Yokota Jouni Korhonen Filename : draft-ietf-dmm-requirements-15.txt Pages : 20 Date : 2014-03-03 Abstract: This document defines the requirements for Distributed Mobility Management (DMM) at the network layer. The hierarchical structure in traditional wireless networks has led primarily to centrally deployed mobility anchors. As some wireless networks are evolving away from the hierarchical structure, it can be useful have a distributed model for mobility management in which traffic does not need to traverse centrally deployed mobility anchors far from the optimal route. The motivation and the problems addressed by each requirement are also described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dmm-requirements-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-requirements-15 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 Mar 4 06:40:36 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7031A01DA for ; Tue, 4 Mar 2014 06:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UMEQ49H6EwT for ; Tue, 4 Mar 2014 06:40:31 -0800 (PST) Received: from mail-ob0-x243.google.com (mail-ob0-x243.google.com [IPv6:2607:f8b0:4003:c01::243]) by ietfa.amsl.com (Postfix) with ESMTP id 7F10F1A0152 for ; Tue, 4 Mar 2014 06:40:31 -0800 (PST) Received: by mail-ob0-f195.google.com with SMTP id wo20so2181030obc.6 for ; Tue, 04 Mar 2014 06:40:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=AmZNmc8URaEdxLgakXU1nordORzeOl5rSXZMOoP5xEk=; b=P6W0LukuHcdRrEPHUY6HrWLE4Cq++JCxdFTYPkAHLPttvcMdW6pnXcQg+aORU2wkLs fRL2G4eWSSwRLk5lsVcUoJ43Y5iHNtdh0jFIFedZFCb16G7nsnns4NqbWVFz1eSVrr0w fhtJrXnHJgT04yIF351PSwtHBpFiTNoFPtSg51en1GOiJnZ75f55PWyKYllIM02IFM+8 jMosflBV5bK1gFYFYr0+BLB+87bWzkb6FToUSPHjBzg7BOOAmUoM0UjCJ6KRMKkz8lEO Y/uGD68mq2yeD6cypTUz3xNpuwI6+A+IjE5sh1wua4X4ghah1vDbfonNA3653+Fr1Tzh v5ag== X-Received: by 10.60.161.136 with SMTP id xs8mr21877848oeb.37.1393944028251; Tue, 04 Mar 2014 06:40:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.162.66 with HTTP; Tue, 4 Mar 2014 06:39:47 -0800 (PST) From: Satoshi Usui Date: Tue, 4 Mar 2014 14:39:47 +0000 Message-ID: To: dmm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/wxBEGhKbezNNP1Fs5o6EPik6gp0 Subject: [DMM] Demo for "Stateless U-Plane for vEPC" X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 14:40:33 -0000 Hi all, I'm going to present a demo tomorrow for "Stateless user-plane for vEPC": [1] http://datatracker.ietf.org/doc/draft-matsushima-stateless-uplane-vepc/ [2] http://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ The demo will show you GTP-U tunnel setup based on received BGP routing update with remote-next-hop attribute. The venue is just in front of the terminal room. Please join us if you have interest in this work. @ Wednesday, March 5, at 1700-1730 in "Hilton Meeting Room 1-4" Looking forward to seeing you there! Regards, Satoshi Usui From nobody Wed Mar 5 00:53:58 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8641B1A02C8 for ; Wed, 5 Mar 2014 00:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BH4dK5ITTbAS for ; Wed, 5 Mar 2014 00:53:54 -0800 (PST) Received: from out68-ams.mf.surf.net (out68-ams.mf.surf.net [145.0.1.68]) by ietfa.amsl.com (Postfix) with ESMTP id D643F1A0283 for ; Wed, 5 Mar 2014 00:53:52 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id s258tadP019602 for ; Wed, 5 Mar 2014 09:55:37 +0100 Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 5 Mar 2014 09:53:51 +0100 Received: from EXMBX23.ad.utwente.nl ([169.254.3.208]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0328.009; Wed, 5 Mar 2014 09:53:47 +0100 From: To: Thread-Topic: comments on draft-ietf-dmm-best-practices-gap-analysis-03.txt Thread-Index: Ac84UGy6KsR1Eb+3Rj2/2gxqiOSSng== Date: Wed, 5 Mar 2014 08:53:46 +0000 Message-ID: References: <20140214184528.30120.70550.idtracker@ietfa.amsl.com> In-Reply-To: <20140214184528.30120.70550.idtracker@ietfa.amsl.com> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [80.229.76.233] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4335F1EXMBX23adutwent_" MIME-Version: 1.0 X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: No geolocation information available for 130.89.5.49 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0bLxITALq - d6007ba59667 - 20140305 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/n6-sdH6NTcBlwluPfuWPvWgoZEg Subject: [DMM] comments on draft-ietf-dmm-best-practices-gap-analysis-03.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 08:53:57 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4335F1EXMBX23adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have reviewd draft-ietf-dmm-best-practices-gap-analysis-03. The draft is = in a good shape, but I have some comments! Moreover, thanks for addressing some comments that I had on previous versio= ns. Comment_1: Not sure if it will help to have a table that shows how each of = the presented solutions satisfy the DMM requirements Comment_2: By looking to the gaps that you have listed, I see that some are= missing or are hidden in the text. The gaps that IMO are not currently listed are: o) lack for support of different deployement models and at the same time la= ck of exposing mobility states, including binding state, access network par= ameers, etc, to interwork with other types of technologies. o) lack of control and data plane separation Best regards, Georgios ________________________________ Van: dmm [dmm-bounces@ietf.org] namens internet-drafts@ietf.org [internet-d= rafts@ietf.org] Verzonden: vrijdag 14 februari 2014 19:45 To: i-d-announce@ietf.org Cc: dmm@ietf.org Onderwerp: [DMM] I-D Action: draft-ietf-dmm-best-practices-gap-analysis-03.= txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Distributed Mobility Management Working G= roup of the IETF. Title : Distributed Mobility Management: Current practice= s and gap analysis Authors : Dapeng Liu Juan Carlos Zuniga Pierrick Seite H Anthony Chan Carlos J. Bernardos Filename : draft-ietf-dmm-best-practices-gap-analysis-03.txt Pages : 25 Date : 2014-02-14 Abstract: The present document analyzes deployment practices of existing IP mobility protocols in a distributed mobility management environment. It then identifies existing limitations when compared to the requirements defined for a distributed mobility management solution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap-analysis= / There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analysis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmm-best-practices-gap-analys= is-03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4335F1EXMBX23adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi all,

 

I have reviewd draft-ietf-dmm-best-practices-gap-analysis-03. The draft = is in a good shape, but I have some comments!

 

Moreover, thanks for addressing some comments that I had on previous ver= sions.

 

Comment_1: Not sure if it will help to have a table that shows how each = of the presented solutions satisfy the DMM requirements

 

Comment_2: By looking to the gaps that you have listed, I see that some = are missing or are hidden in the text.
The gaps that IMO are not currently listed are:

 

o) lack for support of different deployement models and at the same time= lack of exposing mobility states, including binding state, access network = parameers, etc, to interwork with other types of technologies.

 

o) lack of control and data plane separation

 

Best regards,

Georgios

 

 

Van: dmm [dmm-bounces@ietf.org] namens internet-drafts@ietf.org = [internet-drafts@ietf.org]
Verzonden: vrijdag 14 februari 2014 19:45
To: i-d-announce@ietf.org
Cc: dmm@ietf.org
Onderwerp: [DMM] I-D Action: draft-ietf-dmm-best-practices-gap-analy= sis-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
 This draft is a work item of the Distributed Mobility Management Work= ing Group of the IETF.

        Title    &nb= sp;      : Distributed Mobility Management: Curren= t practices and gap analysis
        Authors    &= nbsp;    : Dapeng Liu
            &nb= sp;            = Juan Carlos Zuniga
            &nb= sp;            = Pierrick Seite
            &nb= sp;            = H Anthony Chan
            &nb= sp;            = Carlos J. Bernardos
        Filename    =     : draft-ietf-dmm-best-practices-gap-analysis-03.txt
        Pages    &nb= sp;      : 25
        Date    &nbs= p;       : 2014-02-14

Abstract:
   The present document analyzes deployment practices of existing= IP
   mobility protocols in a distributed mobility management enviro= nment.
   It then identifies existing limitations when compared to the    requirements defined for a distributed mobility management sol= ution.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf= -dmm-best-practices-gap-analysis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dmm-best-= practices-gap-analysis-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-dmm-best-practices-gap-analysis-03


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm
--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4335F1EXMBX23adutwent_-- From nobody Wed Mar 5 02:09:55 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5541A03C5 for ; Wed, 5 Mar 2014 02:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVy3YIUpz3cV for ; Wed, 5 Mar 2014 02:09:49 -0800 (PST) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 51F551A039E for ; Wed, 5 Mar 2014 02:09:49 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id t60so905718wes.19 for ; Wed, 05 Mar 2014 02:09:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=KGPiNclj3hbVPhxuRGKtuAKLGa17GP9nEeRFx4kOO+s=; b=hebZE2w9BM5iBNAirxS3QPRiy3aPe34JB0u9ucjwofhDzYoTICuOA83qEXmf6XK4Vu bHJbhHFnDrSbWIKAml8GikZjQXJExd4Gad9ACbnOwtWpyBJ4v+HQR/HuJB3r12ZxWzZz gWejqIy5awQr8hV7AMqHW9g7upsl5paMMDF2tEJNcFtZLYssRSNN1LjgI/G3bvXTBC8o an+fTPcHs75x3rO5OthDtJJ4VuSFrysMnTshN0qJoyx6Hq1x4FWVH/rurTL9fFvADmN5 E3zfHo00TEW8YpuO8n+rd5utF6V6qKMZzj7gUE0hoxaU18C+AR+1ucBVcJ6kgly8Fbt5 9QnA== X-Received: by 10.194.84.144 with SMTP id z16mr6988511wjy.23.1394014185400; Wed, 05 Mar 2014 02:09:45 -0800 (PST) Received: from dhcp-b491.meeting.ietf.org (dhcp-b491.meeting.ietf.org. [31.133.180.145]) by mx.google.com with ESMTPSA id ci4sm9318961wjc.21.2014.03.05.02.09.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 02:09:44 -0800 (PST) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 5 Mar 2014 10:09:42 +0000 Message-Id: To: "dmm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/2o4wMbaOhSFVSatslWoFgZcOb6U Cc: "dmm-chairs@tools.ietf.org" Subject: [DMM] DMM WG next steps X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 10:09:55 -0000 Folks, DMM WG has done some progress lately. The requirements document has already left the building and the gap analysis is heading to WGLC as we speak. It is about the time to think what we should do next now that we have grown out of the infancy. A smaller group of mobility enthusiasts have been discussing about possible next steps and how the possible new charter would look like. The current very draft text template can be found here: https://github.com/jounikor/dmm-re-charter As you can see, we are still in early stages and all input it welcome. Obviously, possible re-chartering depends on many things. For example, things like getting the gap analysis out of the WG and what the IESG says. Nothing has been fixed or decided yet. Anyhow, we will start the discussion on re-chartering with the expectation that the DMM WG will re-charter and continue developing new solutions and/or enhancements in the IP mobility space. - Jouni & Dapeng From nobody Wed Mar 5 05:04:21 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227B21A00AA for ; Wed, 5 Mar 2014 05:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BA4rPFP7Uoz1 for ; Wed, 5 Mar 2014 05:04:18 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF0B1A006B for ; Wed, 5 Mar 2014 05:04:18 -0800 (PST) Received: from [10.119.8.6] (178-32-57-51.ovh.net [178.32.57.51]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Mdaw0-1WZa9O441k-00PyhF; Wed, 05 Mar 2014 08:04:06 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_863B2736-5189-4C96-9BCC-368A16DC24DE" From: Alper Yegin In-Reply-To: Date: Wed, 5 Mar 2014 15:04:20 +0200 Message-Id: <30507101-509F-4CE0-AF77-BDF03BAE810C@yegin.org> References: To: Jouni Korhonen X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:5sIUHF2F2s5POyGEhdBFUtTxEK+Pw58tB8rZTbnoSVf 9/KSM+bJ2ehUTQBUlrfLYHYmEXIW584BO497chmFEzCXbaiErN Q9XcQ5k07AwtOOB6uzK++t1l0/0suR4wKN5vVjygCQdxobmk0l KMnlq7ebpBpkC9dvRebbJBDPlKMxQaXd7+6+E22cpAYBTV7lPt VHZDvhU2cCATd19X6Qx7S/kkxgrjfEa3B0atUQWnHkuXcd2ZQk 2Cd6z8hL65bRFy+3e/H0bFfLZIIyA3AH1uvbuQlTItyUEpJFof QQI/PnCi2WQz3jduG7CEI3dvlxNsOibXBPI8L+cnO8ogHxMO0i R4rsdERgrNSvb3Zt/ZLrolLZv16E7p3TIKfpA2ShG Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Hk6yhtYIoAzGDyPv-kBz-yRodxI Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 13:04:20 -0000 --Apple-Mail=_863B2736-5189-4C96-9BCC-368A16DC24DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jouni, Thanks for the text. DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user. This part excludes the approaches that place the mobility function on or = near the CN. I recommend the following revision: DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user and/or its corresponding nodes. Alper On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote: > Folks, >=20 > DMM WG has done some progress lately. The requirements document has > already left the building and the gap analysis is heading to WGLC as > we speak. It is about the time to think what we should do next now > that we have grown out of the infancy.=20 >=20 > A smaller group of mobility enthusiasts have been discussing about > possible next steps and how the possible new charter would look like.=20= > The current very draft text template can be found here: > https://github.com/jounikor/dmm-re-charter >=20 > As you can see, we are still in early stages and all input it welcome. > Obviously, possible re-chartering depends on many things. For example, > things like getting the gap analysis out of the WG and what the IESG > says. Nothing has been fixed or decided yet. Anyhow, we will start the > discussion on re-chartering with the expectation that the DMM WG will > re-charter and continue developing new solutions and/or enhancements > in the IP mobility space. >=20 > - Jouni & Dapeng >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm --Apple-Mail=_863B2736-5189-4C96-9BCC-368A16DC24DE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
= DMM can be used to realise such a distributed deployment
      model, by = distributing mobility functions more closer to the = user.


This part = excludes the approaches that place the mobility function on or near the = CN.

I recommend the following = revision:


      DMM can be =
used to realise such a distributed deployment
      model, by distributing =
mobility functions more closer to the user
      =
and/or its corresponding =
nodes.

Alper


<= /div>




On = Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote:

Folks,

DMM WG has done some progress lately. = The requirements document has
already left the building and the gap = analysis is heading to WGLC as
we speak. It is about the time to = think what we should do next now
that we have grown out of the = infancy.

A smaller group of mobility enthusiasts have been = discussing about
possible next steps and how the possible new charter = would look like.
The current very draft text template can be found = here:
= https://github.com/jou= nikor/dmm-re-charter

As you can see, we are still in early = stages and all input it welcome.
Obviously, possible re-chartering = depends on many things. For example,
things like getting the gap = analysis out of the WG and what the IESG
says. Nothing has been fixed = or decided yet. Anyhow, we will start the
discussion on re-chartering = with the expectation that the DMM WG will
re-charter and continue = developing new solutions and/or enhancements
in the IP mobility = space.

- Jouni & = Dapeng

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

= --Apple-Mail=_863B2736-5189-4C96-9BCC-368A16DC24DE-- From nobody Tue Mar 11 08:49:01 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1241A076C for ; Tue, 11 Mar 2014 08:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGH8COgv7DsC for ; Tue, 11 Mar 2014 08:48:54 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id E45191A076A for ; Tue, 11 Mar 2014 08:48:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s2BFmmas003355; Tue, 11 Mar 2014 08:48:48 -0700 Received: from XCH-PHX-513.sw.nos.boeing.com (xch-phx-513.sw.nos.boeing.com [10.57.37.30]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s2BFmc2V002719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 11 Mar 2014 08:48:38 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.102]) by XCH-PHX-513.sw.nos.boeing.com ([169.254.13.48]) with mapi id 14.03.0174.001; Tue, 11 Mar 2014 08:48:37 -0700 From: "Templin, Fred L" To: Jouni Korhonen , "dmm@ietf.org" Thread-Topic: [DMM] DMM WG next steps Thread-Index: AQHPOFsfvo94f8eUfUyESxtA5yGOGZrcDj8g Date: Tue, 11 Mar 2014 15:48:36 +0000 Message-ID: <2134F8430051B64F815C691A62D983181EC042@XCH-BLV-504.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/S2Gv_H6pfuqTAI5dlK7oc9tE21I Cc: "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 15:48:59 -0000 Hi Jouni, I think AERO fits paragraph 3 of the proposed new charter. AERO is a mobility solution for IPv6, where each node gets at least a /64. It has in-built route optimization, and can run over either IPv6 or IPv4 networks as a "link layer" for mobility. AERO expects a distributed mobility management environment, where a network of servers and relays keeps track of mobile node locations without single point of failure concerns. AERO is somewhat like MIPv6, but differs in that it treats the underlying network as a link-layer for IPv6 using a non-broadcast multiple access (NBMA) interface model. AERO uses IPv6 ND messaging and the IPv6 neighbor cache on the AERO "link" instead of MIPv6 mechanisms, and uses DHCPv6 PD exchanges instead of RS/RA for mobile node coordinations. The mobile nodes can therefore act as mobile routers and can provide stable network access for their connected networks (where each mobile node and its connected networks is a "site").=20 Here is a pointer to the spec. Please have a look and let me know what you think, https://datatracker.ietf.org/doc/draft-templin-aerolink/ Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Wednesday, March 05, 2014 2:10 AM > To: dmm@ietf.org > Cc: dmm-chairs@tools.ietf.org > Subject: [DMM] DMM WG next steps >=20 > Folks, >=20 > DMM WG has done some progress lately. The requirements document has > already left the building and the gap analysis is heading to WGLC as > we speak. It is about the time to think what we should do next now > that we have grown out of the infancy. >=20 > A smaller group of mobility enthusiasts have been discussing about > possible next steps and how the possible new charter would look like. > The current very draft text template can be found here: > https://github.com/jounikor/dmm-re-charter >=20 > As you can see, we are still in early stages and all input it welcome. > Obviously, possible re-chartering depends on many things. For example, > things like getting the gap analysis out of the WG and what the IESG > says. Nothing has been fixed or decided yet. Anyhow, we will start the > discussion on re-chartering with the expectation that the DMM WG will > re-charter and continue developing new solutions and/or enhancements > in the IP mobility space. >=20 > - Jouni & Dapeng >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Mar 12 08:11:37 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42D81A072C for ; Wed, 12 Mar 2014 08:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxoeOOiwfvQs for ; Wed, 12 Mar 2014 08:11:25 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7851A045D for ; Wed, 12 Mar 2014 08:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9987; q=dns/txt; s=iport; t=1394637079; x=1395846679; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=V1pTL+wZKfhtiF6I31s73i/IMip51ZZ8nMLnlgUbv1s=; b=Wf+fV++2UdKUV6wfGJdtkRRH559w0LClRDImryQvuvtIYAq5p6mFA2YE d1gEm77GxQNsMcgZHqtX7RLVcyLb4ZObh9c5O64IqTNLg/PgQ4UaWbq2U L3bm/7nUCr1UjA2gGNi4ytKu4Oj5zxF9uStFaaKDfDNhlXWcvG7GRKdgc E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAFl4IFOtJV2b/2dsb2JhbABagkJEO1e6JocugRwWdIIlAQEBBAEBAWsGBRIBCBEDAQIoKAYLFAkIAgQOBRuHSgMRDctMDYYwEwSMRYIGDQQHhDgElliBbYxlhUiDLYIr X-IronPort-AV: E=Sophos; i="4.97,638,1389744000"; d="scan'208,217"; a="26896461" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP; 12 Mar 2014 15:11:18 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2CFBIdv028410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Mar 2014 15:11:18 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.143]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Wed, 12 Mar 2014 10:11:18 -0500 From: "Sri Gundavelli (sgundave)" To: Jouni Korhonen Thread-Topic: [DMM] DMM WG next steps Thread-Index: AQHPPgVRjcRaPuP1zUGsd7jgyAeq2g== Date: Wed, 12 Mar 2014 15:11:17 +0000 Message-ID: In-Reply-To: <30507101-509F-4CE0-AF77-BDF03BAE810C@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.211] Content-Type: multipart/alternative; boundary="_000_CF45C586120512sgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/JExAPKtTSNuZW0GoCDo5QNtAONg Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 15:11:35 -0000 --_000_CF45C586120512sgundaveciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Also, I propose to include the following text. Based on the discussions we = had in the NETEXT WG meet on last Friday, I assume Brian and the DMM chairs= agreed in principle agreed to allow any PMIPv6 maintenance related extensi= ons to be completed in DMM WG. Once the NETEXT closes, we will have a singl= e mobility working group and that will be DMM, just as we had MEXT in the p= ast. "The DMM working group will also allow extensions to the Proxy Mobile IPv6 = protocol, specified in RFC 5213 and RFC 5844. These extensions are maintena= nce-oriented and incremental in nature. Primarily to address any protocol g= aps required to support deployments and other standards development organi= zations using the Proxy Mobile IPv6 protocol in their system architectures.= " Regards Sri From: Alper Yegin > Date: Wednesday, March 5, 2014 6:04 AM To: Jouni Korhonen > Cc: "dmm@ietf.org" >= , "dmm-chairs@tools.ietf.org" > Subject: Re: [DMM] DMM WG next steps Jouni, Thanks for the text. DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user. This part excludes the approaches that place the mobility function on or ne= ar the CN. I recommend the following revision: DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user and/or its corresponding nodes. Alper On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote: Folks, DMM WG has done some progress lately. The requirements document has already left the building and the gap analysis is heading to WGLC as we speak. It is about the time to think what we should do next now that we have grown out of the infancy. A smaller group of mobility enthusiasts have been discussing about possible next steps and how the possible new charter would look like. The current very draft text template can be found here: https://github.com/jounikor/dmm-re-charter As you can see, we are still in early stages and all input it welcome. Obviously, possible re-chartering depends on many things. For example, things like getting the gap analysis out of the WG and what the IESG says. Nothing has been fixed or decided yet. Anyhow, we will start the discussion on re-chartering with the expectation that the DMM WG will re-charter and continue developing new solutions and/or enhancements in the IP mobility space. - Jouni & Dapeng _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --_000_CF45C586120512sgundaveciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0788EBEBF857704EB0E59B36D722E5A8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Also, I propose to include the following text. Based on the discussion= s we had in the NETEXT WG meet on last Friday, I assume Brian and the DMM c= hairs agreed in principle agreed to allow any PMIPv6 maintenance related ex= tensions to be completed in DMM WG. Once the NETEXT closes, we will have a single mobility working group a= nd that will be DMM, just as we had MEXT in the past.

"The DMM working group will also allow extensions to the Proxy Mo= bile IPv6 protocol, specified in RFC 5213 and RFC 5844. These extensions are maintenance-oriented and incremental in nature. Primar= ily to address any protocol gaps required to support  deployments and = other standards development organizations using the Proxy Mobile IPv6 = protocol in their system architectures."

Regards
Sri






From: Alper Yegin <alper.yegin@yegin.org>
Date: Wednesday, March 5, 2014 6:04= AM
To: Jouni Korhonen <jouni.nospam@gmail.com>
Cc: "dmm@ietf.org" <dmm@ietf.= org>, "dmm-chairs@= tools.ietf.org" <d= mm-chairs@tools.ietf.org>
Subject: Re: [DMM] DMM WG next step= s

Jouni,

Thanks for the text.

      DMM can b=
e used to realise such a distributed deployment
  =
;    model, by distributing mobility functions more clo=
ser to the user.


This part excludes the approaches that place the mobility function on = or near the CN.

I recommend the following revision:


      DMM can b=
e used to realise such a distributed deployment
  =
;    model, by distributing mobility functions more clo=
ser to the user
      and/or its corresponding nodes.
=

Alper






On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote:

Folks,

DMM WG has done some progress lately. The requirements document has
already left the building and the gap analysis is heading to WGLC as
we speak. It is about the time to think what we should do next now
that we have grown out of the infancy.

A smaller group of mobility enthusiasts have been discussing about
possible next steps and how the possible new charter would look like.
The current very draft text template can be found here:
https://github.com/jounikor/dmm= -re-charter

As you can see, we are still in early stages and all input it welcome.
Obviously, possible re-chartering depends on many things. For example,
things like getting the gap analysis out of the WG and what the IESG
says. Nothing has been fixed or decided yet. Anyhow, we will start the
discussion on re-chartering with the expectation that the DMM WG will
re-charter and continue developing new solutions and/or enhancements
in the IP mobility space.

- Jouni & Dapeng

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

 --_000_CF45C586120512sgundaveciscocom_-- From nobody Thu Mar 13 03:06:09 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63471A09A6 for ; Thu, 13 Mar 2014 03:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlYC0OEwT7D6 for ; Thu, 13 Mar 2014 03:06:04 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id D9D621A099A for ; Thu, 13 Mar 2014 03:06:03 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id b8so516144lan.12 for ; Thu, 13 Mar 2014 03:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U6qVY5GayCL3UdaaFvkM46TCvzG5eQU47VK4qhRIW20=; b=ouyrVqPd8wruH4vzZAwRN840AqZ1JQFPvFp3dT6UnROQSVNd6eDIdKs5h4RgVj3V7j IbNKlkqUDjoaNtP/hdRmwWOdvTKqgAB1QLSVHoPoY+May/Md7DeZnREDOlLGAQEe9e1Z YZECcYkeuIqxbd91SyA1/i+6N6EWsoj7tsZt0ppbcwICVf3o9p8oGLTUI4akXmRM2s2D ujI+vZQ30IFv7o+7DnJHXAXNP5ANVwN7ZO5F7VN6G/WE1/cAmtA1vtDJUQn7AWRvhVuM m+JHMgA3QDpIKswcgn0yrAD0pn3XrWRO66ZU/7YUzEm3rzoGHXixX6YBSSO6mrII2hZH cJOA== X-Received: by 10.112.35.130 with SMTP id h2mr626734lbj.15.1394705156878; Thu, 13 Mar 2014 03:05:56 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:680a:3aad:2297:8bc9? ([2001:1bc8:101:f101:680a:3aad:2297:8bc9]) by mx.google.com with ESMTPSA id bm3sm1802703lbb.12.2014.03.13.03.05.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Mar 2014 03:05:52 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: Date: Thu, 13 Mar 2014 12:05:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sri Gundavelli (sgundave) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/5HSFOHf1KT-nPIwO53Lbd76dp_w Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 10:06:06 -0000 On Mar 12, 2014, at 5:11 PM, Sri Gundavelli (sgundave) = wrote: > Also, I propose to include the following text. Based on the = discussions we had in the NETEXT WG meet on last Friday, I assume Brian = and the DMM chairs agreed in principle agreed to allow any PMIPv6 = maintenance related extensions to be completed in DMM WG. Once the = NETEXT closes, we will have a single mobility working group and that = will be DMM, just as we had MEXT in the past. This is/was my understanding as well. I would, however, emphasise the=20 the word "maintenance". There is a difference between a new protocol work and maintaining a protocol. > "The DMM working group will also allow extensions to the Proxy Mobile = IPv6 protocol, specified in RFC 5213 and RFC 5844. These extensions are = maintenance-oriented and incremental in nature. Primarily to address any = protocol gaps required to support deployments and other standards = development organizations using the Proxy Mobile IPv6 protocol in their = system architectures." Looks as a good basis. Thx. - Jouni >=20 > Regards > Sri >=20 >=20 >=20 >=20 >=20 >=20 > From: Alper Yegin > Date: Wednesday, March 5, 2014 6:04 AM > To: Jouni Korhonen > Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" = > Subject: Re: [DMM] DMM WG next steps >=20 > Jouni, >=20 > Thanks for the text. >=20 > DMM can be used to realise such a distributed deployment > model, by distributing mobility functions more closer to the = user. >=20 >=20 > This part excludes the approaches that place the mobility function on = or near the CN. >=20 > I recommend the following revision: >=20 >=20 > DMM can be used to realise such a distributed deployment > model, by distributing mobility functions more closer to the = user > and/or its corresponding nodes. >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 > On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote: >=20 >> Folks, >>=20 >> DMM WG has done some progress lately. The requirements document has >> already left the building and the gap analysis is heading to WGLC as >> we speak. It is about the time to think what we should do next now >> that we have grown out of the infancy.=20 >>=20 >> A smaller group of mobility enthusiasts have been discussing about >> possible next steps and how the possible new charter would look like.=20= >> The current very draft text template can be found here: >> https://github.com/jounikor/dmm-re-charter >>=20 >> As you can see, we are still in early stages and all input it = welcome. >> Obviously, possible re-chartering depends on many things. For = example, >> things like getting the gap analysis out of the WG and what the IESG >> says. Nothing has been fixed or decided yet. Anyhow, we will start = the >> discussion on re-chartering with the expectation that the DMM WG will >> re-charter and continue developing new solutions and/or enhancements >> in the IP mobility space. >>=20 >> - Jouni & Dapeng >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 From nobody Thu Mar 13 03:07:02 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD071A099A for ; Thu, 13 Mar 2014 03:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLI8nVnQ-WVz for ; Thu, 13 Mar 2014 03:06:59 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 356431A0993 for ; Thu, 13 Mar 2014 03:06:59 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gf5so507201lab.21 for ; Thu, 13 Mar 2014 03:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UW8GxZDcHw34ULinSYnW5kOIj7roU21tcrf9lRh8BaU=; b=yPujcZ+XGlxiC8jUI2c3+IazuHoDiPnCDyiAVfbJ2DftHRXQ3sjOOsWEVwUgozNGY9 ddtVvLfPv1gJvsAj1oiF6Fut9LHknsvhrGMoH+61PnA+lAW4uWNlwdycwJH/j1FL4EiI tK6q2aoiQrCNICLLX65XuCWTBT7I1cLwkkywi6bq2vRLAR2aX+FHXx3YzFFhcAroQLU6 uD4sMyiwnEUxhwhCoWVH3qt19Nex6OITuT5602sUAsCbr8ZccdMHnYDiXJ4Z01Slnrqp /l955jq6d1sB0X4fLmjEXQwwMiqhzkQnp4BC8b4fk4xBwrUUiQ3weK9bfvWhhZnukZfd 6xog== X-Received: by 10.112.46.225 with SMTP id y1mr669586lbm.12.1394705212176; Thu, 13 Mar 2014 03:06:52 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:680a:3aad:2297:8bc9? ([2001:1bc8:101:f101:680a:3aad:2297:8bc9]) by mx.google.com with ESMTPSA id bm3sm1802703lbb.12.2014.03.13.03.06.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Mar 2014 03:06:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <30507101-509F-4CE0-AF77-BDF03BAE810C@yegin.org> Date: Thu, 13 Mar 2014 12:06:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7E25C274-AD96-46A7-B022-B2C183150BDC@gmail.com> References: <30507101-509F-4CE0-AF77-BDF03BAE810C@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/wBq6yO1Eaje_S2JQo_j3IubULPA Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 10:07:01 -0000 Alper, Thanks. Looks good (or better than the original) to me. - Jouni On Mar 5, 2014, at 3:04 PM, Alper Yegin wrote: > Jouni, >=20 > Thanks for the text. >=20 > DMM can be used to realise such a distributed deployment > model, by distributing mobility functions more closer to the = user. >=20 >=20 > This part excludes the approaches that place the mobility function on = or near the CN. >=20 > I recommend the following revision: >=20 >=20 > DMM can be used to realise such a distributed deployment > model, by distributing mobility functions more closer to the = user > and/or its corresponding nodes. >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 > On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote: >=20 >> Folks, >>=20 >> DMM WG has done some progress lately. The requirements document has >> already left the building and the gap analysis is heading to WGLC as >> we speak. It is about the time to think what we should do next now >> that we have grown out of the infancy.=20 >>=20 >> A smaller group of mobility enthusiasts have been discussing about >> possible next steps and how the possible new charter would look like.=20= >> The current very draft text template can be found here: >> https://github.com/jounikor/dmm-re-charter >>=20 >> As you can see, we are still in early stages and all input it = welcome. >> Obviously, possible re-chartering depends on many things. For = example, >> things like getting the gap analysis out of the WG and what the IESG >> says. Nothing has been fixed or decided yet. Anyhow, we will start = the >> discussion on re-chartering with the expectation that the DMM WG will >> re-charter and continue developing new solutions and/or enhancements >> in the IP mobility space. >>=20 >> - Jouni & Dapeng >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 From nobody Thu Mar 13 06:05:35 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FF61A087F for ; Thu, 13 Mar 2014 06:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGL9c6tAelOU for ; Thu, 13 Mar 2014 06:05:31 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 146271A0848 for ; Thu, 13 Mar 2014 06:05:30 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id c11so660875lbj.17 for ; Thu, 13 Mar 2014 06:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=O3SriFnNrfru9fPzMSbVti1Y6jCSiat+toWz1F6w65M=; b=MbC653X7i38HM92lrX4OZdmRYYlX4ukEONsfMles7L1k+rBUjk2nS0g2TWoiuPNa7t jj6PaH24fqjlHsGznybBEwfkUC0EindBl7URvxqpjGF/oX0gHLOpLpA2DBFoGnImeWaL R3xh7myeLFRtJn8ofrFqN1+Kr8U0zQap1saxXfVE4PE2m0OGoQZpjAM7NejyI9QjjLUf 1oT7nCByLVAHO+/+9zCR7uQTOhje+llnu4+m3ZptQz93rh6bHSe95YAB9B00POlesyRs eGOIX+EkNZBgIB3BKRW4J/ZUXTFTpD7swViaS/Wmmxb7tUBltk1UlP0+RUStjPdJNHX4 N87A== X-Received: by 10.112.147.36 with SMTP id th4mr1124615lbb.32.1394715923931; Thu, 13 Mar 2014 06:05:23 -0700 (PDT) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id jy5sm2048493lac.9.2014.03.13.06.05.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Mar 2014 06:05:23 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 13 Mar 2014 15:05:21 +0200 Message-Id: To: "dmm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/IMRnExrS9Qswikie7FIaJ3zP0m0 Cc: "dmm-chairs@tools.ietf.org" Subject: [DMM] IETF#89 draft meeting minutes uploaded. X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 13:05:33 -0000 Available here: http://www.ietf.org/proceedings/89/minutes/minutes-89-dmm In a case of errors, just let the chairs know and we'll fix the minutes. Thanks to Alex taking extensive notes during the meeting. - Jouni & Dapeng From nobody Thu Mar 13 06:11:32 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3BD1A082B for ; Thu, 13 Mar 2014 06:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXEBWwbX1-Hn for ; Thu, 13 Mar 2014 06:11:28 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADDB1A07CB for ; Thu, 13 Mar 2014 06:11:27 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id y1so665977lam.34 for ; Thu, 13 Mar 2014 06:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=hkIgqNEh4O98tKPA25BwyTWvu8kgJ337c9EMjXW6EYI=; b=jYuPgxTiK+ZAvweecdLIUNNmPzQK+31ocn05F+tGPtekM6CLzBCpS16N7/I0oXUUyY VKTktyIyyR0OO4zF4cuGh3ayWykzLQXtHnPZf3WPNLEs9rkbckGTqXpryiA8HF59vLKU MaPpdZzrRTCfY6gM2cRquDmB3k7BbTx12teYIK4U16Yeyp60q+do1+sz2YfGHWpodt9S 5sKY0NBHBxqHUrrF5pkNMcN2nIYV/qw3YBejWxJhx/7RDSZMpZA002zV26NZQ47WHkNP emeuhfgPe1jAJrOryQPdf30KRchPeNZXaVwaVKBvpAU5NVm+IUOyLNBTIhGEgTVCQV1b iTKQ== X-Received: by 10.112.147.67 with SMTP id ti3mr1161160lbb.14.1394716281000; Thu, 13 Mar 2014 06:11:21 -0700 (PDT) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id x4sm2372327lbn.2.2014.03.13.06.11.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Mar 2014 06:11:20 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 13 Mar 2014 15:11:18 +0200 Message-Id: <9F2F59BC-1344-409E-8D6B-44C22F362D31@gmail.com> To: "dmm@ietf.org" , "draft-ietf-dmm-best-practices-gap-analysis@tools.ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/oCf67rca_RRiziqlbRqwXuUJp4k Cc: "dmm-chairs@tools.ietf.org" Subject: [DMM] WGLC #1 for draft-ietf-dmm-best-practices-gap-analysis-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 13:11:29 -0000 Folks, As mentioned during London meeting, the best practices and gap analysis document is ready for the WGLC. This mail starts a two week WGLC for the draft-ietf-dmm-best-practices-gap-analysis-03. The WGLC ends 27th March. Send your comments into the mailing list and in a case of issues you think need to be addressed in the document, create an issue into the issue tracker! - Jouni & Dapeng From nobody Thu Mar 13 08:41:07 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C201A09A3 for ; Thu, 13 Mar 2014 08:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgKbk4q5AxZN for ; Thu, 13 Mar 2014 08:41:02 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 724C51A088B for ; Thu, 13 Mar 2014 08:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=560; q=dns/txt; s=iport; t=1394725256; x=1395934856; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=BTgEaApedMc6pv/eG+jJFTDhLWOGxObQfxShZXbMVjI=; b=PQzDmCaU0DcOz7iji0cOLx0ur6laFZOahdgPgPcAMMKCMiflq2zbmIg/ +mhX/ZjNqlSopZdlYg4tfISwpvinX3CYQJzutX93u7Cmkfu3GXWyuvGf9 eq0Cy2HRnxsHWKwIJkBK84AZANVbZ0qSFF02MHOYYbbV0P3BVOgHlWX9M Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAJXQIVOtJV2b/2dsb2JhbABZgwaBEsFjgRcWdIIlAQEBBDo/EgEIGB4xESUCBA4Fh2UDEcxRDYcHF4xGghcHhDgBA5ZYgW2MZYVIgy2CKw X-IronPort-AV: E=Sophos;i="4.97,648,1389744000"; d="scan'208";a="310185007" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 13 Mar 2014 15:40:56 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2DFetCD021551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Mar 2014 15:40:55 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.143]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Thu, 13 Mar 2014 10:40:55 -0500 From: "Sri Gundavelli (sgundave)" To: Jouni Korhonen Thread-Topic: [DMM] DMM WG next steps Thread-Index: AQHPPtKfmzH0SLLdzUusSLjBmWSf/A== Date: Thu, 13 Mar 2014 15:40:55 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.213] Content-Type: text/plain; charset="us-ascii" Content-ID: <1F2A3B77D4EE8C49BA3C9846746930A8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/TQIVICdq6XcFiQqQyl6tt1EGtKY Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 15:41:04 -0000 On 3/13/14 3:05 AM, "Jouni Korhonen" wrote: > >On Mar 12, 2014, at 5:11 PM, Sri Gundavelli (sgundave) > wrote: > > >This is/was my understanding as well. I would, however, emphasise the >the word "maintenance". There is a difference between a new protocol >work and maintaining a protocol. I'd say, incremental extensions for ensuring deployment continuity and SDO support. But, I agree, we don't design a NG StarTrek, all that action already exists in DMM :), we dare not go there with this. From nobody Thu Mar 13 09:01:09 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879691A0A0B for ; Thu, 13 Mar 2014 09:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWGcdlllR-PV for ; Thu, 13 Mar 2014 09:01:05 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCEB1A09A3 for ; Thu, 13 Mar 2014 09:01:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s2DG0ws9004803; Thu, 13 Mar 2014 11:00:58 -0500 Received: from XCH-PHX-112.sw.nos.boeing.com (xch-phx-112.sw.nos.boeing.com [130.247.25.134]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s2DG0mk1004223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 13 Mar 2014 11:00:48 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.102]) by XCH-PHX-112.sw.nos.boeing.com ([169.254.12.213]) with mapi id 14.03.0174.001; Thu, 13 Mar 2014 09:00:47 -0700 From: "Templin, Fred L" To: Jouni Korhonen , Sri Gundavelli Thread-Topic: [DMM] DMM WG next steps Thread-Index: AQHPPqPOvo94f8eUfUyESxtA5yGOGZrfLFgw Date: Thu, 13 Mar 2014 16:00:46 +0000 Message-ID: <2134F8430051B64F815C691A62D983181EF82C@XCH-BLV-504.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/2GekbMpTwu0k77eMfInFH-gCzyk Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 16:01:07 -0000 Hi Jouni, > There is a difference between a new protocol work and maintaining a proto= col. AERO is simply an adaptation of an existing protocol (namely, IPv6 ND). So, it should qualify as maintaining a protocol, I think?=20 Thanks - Fred fred.l.templin@boeing.com From nobody Thu Mar 13 09:04:57 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FE21A09A3 for ; Thu, 13 Mar 2014 09:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26HU4HZ_X386 for ; Thu, 13 Mar 2014 09:04:55 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 33BDF1A088B for ; Thu, 13 Mar 2014 09:04:55 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id s7so861076lbd.1 for ; Thu, 13 Mar 2014 09:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7Wmlmq9q4IznflJg89wl9MWIPuL4v0ROFO9CM6uiesY=; b=oeuFXtEtsxJqGfQxb28tAA4sLiBVINsX6/CmGVLDnCvwJfiquoO5I0+CylUqEGE/NE zFc0ijlC2q28f+HJfYRgn/Bqa9V5zLiSNvLKv3qfAV0HW/UHoSuy5iF3cgQFnrbYOXFI R129BXoETxz6mnfkoTEtA4MzJbhBZ/wzSshSqdTyLP42mvYd9dcobUxFuTzDEZwA5J8h NoQh6QZaTvLkLW8u764LX6oNTovN9KAqrLF0gwspJMHFo3iPSeIkNlnp/Sgd2hVmC1Ad 4/fWThEXbKhdvkZLJlXzG6gmgWbAfnBqva73Cl1A4eq+pQVQD7eCV+9Bq2O1yGlV9fUO 5gCg== X-Received: by 10.112.139.232 with SMTP id rb8mr906045lbb.53.1394726687945; Thu, 13 Mar 2014 09:04:47 -0700 (PDT) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id sx1sm2514882lac.1.2014.03.13.09.04.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Mar 2014 09:04:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: Date: Thu, 13 Mar 2014 18:04:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1A1F5DDA-B31E-419E-9A87-2AC29FB9A981@gmail.com> References: To: Sri Gundavelli (sgundave) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/CG0WXuM66GLEUSMOdXAvIPy9gMc Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 16:04:56 -0000 On Mar 13, 2014, at 5:40 PM, Sri Gundavelli (sgundave) = wrote: >=20 >=20 > On 3/13/14 3:05 AM, "Jouni Korhonen" wrote: >=20 >>=20 >> On Mar 12, 2014, at 5:11 PM, Sri Gundavelli (sgundave) >> wrote: >>=20 >>=20 >> This is/was my understanding as well. I would, however, emphasise the >> the word "maintenance". There is a difference between a new protocol >> work and maintaining a protocol. >=20 >=20 > I'd say, incremental extensions for ensuring deployment continuity and = SDO > support. But, I agree, we don't design a NG StarTrek, all that action That is maintenance in my eyes. - Jouni > already exists in DMM :), we dare not go there with this. >=20 >=20 >=20 From nobody Fri Mar 14 04:51:46 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C446E1A010E for ; Fri, 14 Mar 2014 04:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYQZiz665Cva for ; Fri, 14 Mar 2014 04:51:44 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 918901A011D for ; Fri, 14 Mar 2014 04:51:44 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id F291388118 for ; Fri, 14 Mar 2014 04:51:37 -0700 (PDT) Received: from 102520208.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id C308E71B0001 for ; Fri, 14 Mar 2014 04:51:37 -0700 (PDT) Message-ID: <5322ED49.8030604@innovationslab.net> Date: Fri, 14 Mar 2014 07:51:37 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dmm@ietf.org References: <2134F8430051B64F815C691A62D983181EF82C@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181EF82C@XCH-BLV-504.nw.nos.boeing.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IqPQ09FXEcF545IRfGn3gNIHEpUf0rks3" Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/qrofqRjydXj_xsOvCZUl6yGkTFo Subject: Re: [DMM] DMM WG next steps X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 11:51:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IqPQ09FXEcF545IRfGn3gNIHEpUf0rks3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 3/13/14 12:00 PM, Templin, Fred L wrote: > Hi Jouni, >=20 >> There is a difference between a new protocol work and maintaining a pr= otocol. >=20 > AERO is simply an adaptation of an existing protocol (namely, IPv6 ND).= > So, it should qualify as maintaining a protocol, I think?=20 IPv6 Neighbor Discovery is maintained by 6MAN. Regards, Brian --IqPQ09FXEcF545IRfGn3gNIHEpUf0rks3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTIu1JAAoJEBOZRqCi7goqYI4H/R3OTLD3lENU39pOOTcOJQHb c5rb6f95jwGx2KRcWZQxr8RMEnMkDAMRjpXVh7sGjhTPb80A/CJikyJ97sFpt6Sd 7R2fbvYnwulExBjUIej3Iroip4HT3vZ1iRclvaAtxZMn4KLqFFzUU1m8k6zCrJAC mG0p1QWZV2nEwnhb/zW/NOxPBXW/pr8t9RD+pa7QW/vnZqVReF+TEvEmh51VP6LI H1aqpZU6aBWYK6gzckG6QD2g+JJQ5u+okd3mMSYjRSzRtpmPgs3ubRQjMHVRQqr4 OU/B+X30PIqZTI8+AxGltDTWXji3gGpwn5EhkeO18y/nJfaRVP8Hoel5Kua/4k8= =+nAZ -----END PGP SIGNATURE----- --IqPQ09FXEcF545IRfGn3gNIHEpUf0rks3-- From nobody Sat Mar 15 21:04:57 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F9A1A02C0 for ; Sat, 15 Mar 2014 21:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbEdYKeY_Ep7 for ; Sat, 15 Mar 2014 21:04:38 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 380B41A02C1 for ; Sat, 15 Mar 2014 21:04:37 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ma3so4309812pbc.13 for ; Sat, 15 Mar 2014 21:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QrS3Pr6yKAR9vw96PF8b4DkLLBRbMoV91Q3fC5B8kzM=; b=BBwiZlqt5XJhhAaXssBPdJ9sy3T/4gyKajWnNcQOaW1FO9lqF//I3Q+FH3UFr4JtGU FOHZH35KOd9TdhapZD2dFeB4HjzidnZ/Z0Tjdf7wXvy2hnveSLiJiFAWM6kUkkEZzMg9 NfPtTw9YE2RKLwRknDuXRo2zBZ2EOURLIpmB7RRHJEaLb2p7fi5+I9OiNcrdkMZT0xRC GJEj2yTrlndI3ZAktd/rUT7GohyTyROcmArSAH4gScnOPKkex/G357NdfWuXTRO7+jgY LK2Nt1fSpfCspgvFhkZevjJRxMDANCYM8E0fgKQ84lXDiDbKJ8qNLsuNoNUabytvAPt4 JZog== X-Received: by 10.66.227.104 with SMTP id rz8mr18262147pac.74.1394942670619; Sat, 15 Mar 2014 21:04:30 -0700 (PDT) Received: from [172.23.208.34] ([125.35.60.218]) by mx.google.com with ESMTPSA id id10sm30666591pbc.35.2014.03.15.21.04.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 15 Mar 2014 21:04:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <2134F8430051B64F815C691A62D983181EC042@XCH-BLV-504.nw.nos.boeing.com> Date: Sun, 16 Mar 2014 12:04:17 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2134F8430051B64F815C691A62D983181EC042@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/qy1gJHBL28S49Ka-qUutGKSKJik Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 04:04:53 -0000 Fred, On Mar 11, 2014, at 11:48 PM, "Templin, Fred L" = wrote: > Hi Jouni, >=20 > I think AERO fits paragraph 3 of the proposed new charter. AERO is a > mobility solution for IPv6, where each node gets at least a /64. It > has in-built route optimization, and can run over either IPv6 or IPv4 > networks as a "link layer" for mobility. AERO expects a distributed > mobility management environment, where a network of servers and > relays keeps track of mobile node locations without single point > of failure concerns. >=20 > AERO is somewhat like MIPv6, but differs in that it treats the > underlying network as a link-layer for IPv6 using a non-broadcast > multiple access (NBMA) interface model. AERO uses IPv6 ND messaging > and the IPv6 neighbor cache on the AERO "link" instead of MIPv6 > mechanisms, and uses DHCPv6 PD exchanges instead of RS/RA for mobile > node coordinations. The mobile nodes can therefore act as mobile > routers and can provide stable network access for their connected > networks (where each mobile node and its connected networks is > a "site").=20 >=20 > Here is a pointer to the spec. Please have a look and let me know > what you think, There has been zero prior discussion or activity on this topic in DMM that I recall. Furthermore, the current draft seems to be a bis of RFC6707, driven by a single individual and quite far in the preparation so I do not see a reason involving this into the WG work. - JOuni >=20 > https://datatracker.ietf.org/doc/draft-templin-aerolink/ >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> -----Original Message----- >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen >> Sent: Wednesday, March 05, 2014 2:10 AM >> To: dmm@ietf.org >> Cc: dmm-chairs@tools.ietf.org >> Subject: [DMM] DMM WG next steps >>=20 >> Folks, >>=20 >> DMM WG has done some progress lately. The requirements document has >> already left the building and the gap analysis is heading to WGLC as >> we speak. It is about the time to think what we should do next now >> that we have grown out of the infancy. >>=20 >> A smaller group of mobility enthusiasts have been discussing about >> possible next steps and how the possible new charter would look like. >> The current very draft text template can be found here: >> https://github.com/jounikor/dmm-re-charter >>=20 >> As you can see, we are still in early stages and all input it = welcome. >> Obviously, possible re-chartering depends on many things. For = example, >> things like getting the gap analysis out of the WG and what the IESG >> says. Nothing has been fixed or decided yet. Anyhow, we will start = the >> discussion on re-chartering with the expectation that the DMM WG will >> re-charter and continue developing new solutions and/or enhancements >> in the IP mobility space. >>=20 >> - Jouni & Dapeng >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm From nobody Sun Mar 16 23:41:59 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40A81A0031 for ; Sun, 16 Mar 2014 23:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s52n4ldT2qF8 for ; Sun, 16 Mar 2014 23:41:54 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 09EE71A0030 for ; Sun, 16 Mar 2014 23:41:53 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id rr13so5312009pbb.11 for ; Sun, 16 Mar 2014 23:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=1S+sqrOSeuN6fqL9MhwEeYj4m3sR0IrXPa16aJyY3nA=; b=LQClRF4UDtPa8C+XG66jDCcM7OdNrufL+NFkyoJwBFEypuUGtIPLra7f31B/u3JBvB 6ML5zEJC+aqRs4P7wYi90O3EPQVY+rWEAe9jfehDzDWbtMwio3yF64oM5WQW0r9kxOqx 9ukDz+Dw4h7IlYBwhnc+MEGLH+IyNvEtSCpN6E5npe55AG+pXwRtvzl97hc9JiYu2iEE 5+04EIcaRZp2CxSMs/tHPt2azYIShBmMW1hcGjWeoKUlkjEEf6aqMJRz+gwLoS+TSqfK U9hSAonlpqtvjP3DwS3DeQykAWslGda21AcjPncdEg9/Ute8DiofabHAeEQthfhqy5kI HnYw== X-Received: by 10.67.1.202 with SMTP id bi10mr23967681pad.68.1395038506295; Sun, 16 Mar 2014 23:41:46 -0700 (PDT) Received: from dhcp-18-187.meeting.verilan.com ([123.124.234.161]) by mx.google.com with ESMTPSA id ei4sm40146296pbb.42.2014.03.16.23.41.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Mar 2014 23:41:45 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <47C1CC71-67F1-4AC7-96AA-48BF37040C29@gmail.com> Date: Mon, 17 Mar 2014 14:41:38 +0800 To: "dmm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/h-spi5lMpjsJQseW4KX8UHfh4y0 Subject: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 06:41:56 -0000 Folks, I have updated the charter draft text slightly: https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt Basically: Added Sri's comment on PMIPv6 maintenance. Added Alper's comment of location of mobility functions. Added links to other IETF WGs on possible mobility enabling technologies. Added a comment that virtualised network functions are in scope. - Jouni From nobody Mon Mar 17 01:30:09 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9551A03BC for ; Mon, 17 Mar 2014 01:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEZnp7JTzfvC for ; Mon, 17 Mar 2014 01:30:06 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 83BA61A03BA for ; Mon, 17 Mar 2014 01:30:06 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id e16so3430061lan.16 for ; Mon, 17 Mar 2014 01:29:57 -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-type; bh=ZppGkwohhbPzlrrEgSoT9HiHN1eGeGTLg1boMe1600o=; b=Td18+NrR/wptG9m4IgITWn8zzJwK68LJebYjB9wMg9XCFKmBDWlkXHLJ1lXDZuD42P G4orvpIp1rLdfQUbZOW7GXmn0KbidKOgHrGvtk4XsjBouBQ5RIoDrqcQYq7Okk8Gjr66 Wp8R5Cpb7z2rmtVSU1OLZseCBSDp4ftbXa5gaUTpswI5RXgoVsMhEJwxKp5N9OKj99du DnGux3BFEArGLcWn75qJ0KCtwndxtrtahwuUh9h8SAOWOcSRSbK1YGD3xcAJYolhnbIL CPuFrqcbBLKHt1Y7VbreQsVomdpkf9j7T36i7yj/YkebIPBuaGMDa6PQLse7Pr6C50TM rcSA== MIME-Version: 1.0 X-Received: by 10.152.29.8 with SMTP id f8mr16034766lah.11.1395044997831; Mon, 17 Mar 2014 01:29:57 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Mon, 17 Mar 2014 01:29:57 -0700 (PDT) In-Reply-To: <47C1CC71-67F1-4AC7-96AA-48BF37040C29@gmail.com> References: <47C1CC71-67F1-4AC7-96AA-48BF37040C29@gmail.com> Date: Mon, 17 Mar 2014 03:29:57 -0500 Message-ID: From: Behcet Sarikaya To: Jouni Korhonen Content-Type: multipart/alternative; boundary=089e0158c1588aa0d304f4c939eb Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/MkLaosh0mIjcxB4KxRXbv_6iXzE Cc: "dmm@ietf.org" Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 17 Mar 2014 08:30:08 -0000 --089e0158c1588aa0d304f4c939eb Content-Type: text/plain; charset=ISO-8859-1 Hi Jouni, Reading your milestones: Submit I-D 'Solution Requirements' to the IESG for consideration as an Informational RFC. Submit I-D 'Gap Analysis' to the IESG for consideration as an Informational RFC. I came to the conclusion that we are the loop doing the same or similar things over and over again. Why? Regards, Behcet On Mon, Mar 17, 2014 at 1:41 AM, Jouni Korhonen wrote: > Folks, > > I have updated the charter draft text slightly: > https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt > > Basically: > > Added Sri's comment on PMIPv6 maintenance. > Added Alper's comment of location of mobility functions. > Added links to other IETF WGs on possible mobility enabling technologies. > Added a comment that virtualised network functions are in scope. > > - Jouni > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --089e0158c1588aa0d304f4c939eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jouni,

Reading your milestones:
Submit I-D 'Solution Requirements' to th= e IESG for consideration as an Informational RFC.
=A0 Submit I-D 'Gap Analysis' to the IESG for consideration as an I= nformational RFC.

I came to the c= onclusion that we are the loop doing the same or similar things over and ov= er again.

Why?

Regards,

Behcet



On Mon, Mar 17, 2014 at 1:41 AM, Jouni Korhonen <<= a href=3D"mailto:jouni.nospam@gmail.com" target=3D"_blank">jouni.nospam@gma= il.com> wrote:
Folks,

I have updated the charter draft text slightly:
https://github.com/jounikor/dmm-re-charter/bl= ob/master/recharter_draft.txt

Basically:

Added Sri's comment on PMIPv6 maintenance.
Added Alper's comment of location of mobility functions.
Added links to other IETF WGs on possible mobility enabling technologies. Added a comment that virtualised network functions are in scope.

- Jouni

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

--089e0158c1588aa0d304f4c939eb-- From nobody Mon Mar 17 02:16:40 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DE11A007E for ; Mon, 17 Mar 2014 02:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuDBLmrI4d5s for ; Mon, 17 Mar 2014 02:16:37 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id CC1D81A0064 for ; Mon, 17 Mar 2014 02:16:37 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id y10so5332950pdj.13 for ; Mon, 17 Mar 2014 02:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UvtCkOya1gyJHm+mHsSnohr/J2WSOFaPDfeeDUqDwOc=; b=PNA81k+CGVKiPUoodjCroM2QymW5EomjXSO4SIyU4R/1GL0Gqrm0HiJm8FdmWP1fXI aAa6w58d6JRmCCslYX5Lg4nSvNtI5Sg4AnNR0Wf3QWxFCpDtbMMoSeA29SKee7qsRLXs N46dBIr5yvBVq9/ex3LlLLxWDxz2sfuQ5bLkofOf6YTugyqNXoY7PgFPSQ+7UeqjG6k0 EWLHfag3e9Aa9q7tDpKAvUJoBNBMftxWbp0/CXCx/dlEBjxJTtPkvLpYHgTclIWLZ0u7 sSGlsQIWiSCaoA9/1TO0l/M082WpIVi/TGKg2sboNEeOJIsJ9OCWMV/ek91BHxDUEmeB V89w== X-Received: by 10.66.227.104 with SMTP id rz8mr24701520pac.74.1395047790091; Mon, 17 Mar 2014 02:16:30 -0700 (PDT) Received: from dhcp-18-187.meeting.verilan.com ([123.124.234.161]) by mx.google.com with ESMTPSA id sm5sm68978292pab.19.2014.03.17.02.16.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Mar 2014 02:16:28 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: Date: Mon, 17 Mar 2014 17:16:18 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <67E9A360-E9D1-4DFA-AE76-F00C7B98D8FD@gmail.com> References: <47C1CC71-67F1-4AC7-96AA-48BF37040C29@gmail.com> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/_crOobg449Umvk5rjJT8uyqfeQ0 Cc: "dmm@ietf.org" Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 09:16:39 -0000 On Mar 17, 2014, at 4:29 PM, Behcet Sarikaya = wrote: > Hi Jouni, >=20 > Reading your milestones: > Submit I-D 'Solution Requirements' to the IESG for consideration as an = Informational RFC. > Submit I-D 'Gap Analysis' to the IESG for consideration as an = Informational RFC. >=20 > I came to the conclusion that we are the loop doing the same or = similar things over and over again. >=20 > Why? Because our text editing has not even reached milestones part of the charter text. That's why. - Jouni >=20 > Regards, >=20 > Behcet >=20 >=20 >=20 > On Mon, Mar 17, 2014 at 1:41 AM, Jouni Korhonen = wrote: > Folks, >=20 > I have updated the charter draft text slightly: > = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >=20 > Basically: >=20 > Added Sri's comment on PMIPv6 maintenance. > Added Alper's comment of location of mobility functions. > Added links to other IETF WGs on possible mobility enabling = technologies. > Added a comment that virtualised network functions are in scope. >=20 > - Jouni >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm >=20 From nobody Mon Mar 17 11:31:41 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9981A0440 for ; Mon, 17 Mar 2014 11:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rUuAma2-kS5 for ; Mon, 17 Mar 2014 11:31:36 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id C02AD1A01D5 for ; Mon, 17 Mar 2014 11:31:36 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s2HIVS8a030506; Mon, 17 Mar 2014 13:31:28 -0500 Received: from XCH-PHX-512.sw.nos.boeing.com (xch-phx-512.sw.nos.boeing.com [10.57.37.29]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s2HIVNst029959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 17 Mar 2014 13:31:24 -0500 Received: from XCH-BLV-408.nw.nos.boeing.com (130.247.25.166) by XCH-PHX-512.sw.nos.boeing.com (10.57.37.29) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 17 Mar 2014 11:31:23 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.87]) by XCH-BLV-408.nw.nos.boeing.com ([169.254.8.139]) with mapi id 14.03.0174.001; Mon, 17 Mar 2014 11:31:22 -0700 From: "Templin, Fred L" To: Jouni Korhonen Thread-Topic: [DMM] DMM WG next steps Thread-Index: AQHPQMzMvo94f8eUfUyESxtA5yGOGZrlmwQA Date: Mon, 17 Mar 2014 18:31:22 +0000 Message-ID: <2134F8430051B64F815C691A62D9831820153C@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181EC042@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/-LOa01-_zJ43yl1ZSUQokP8h9es Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 18:31:39 -0000 Hi Jouni, > -----Original Message----- > From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] > Sent: Saturday, March 15, 2014 9:04 PM > To: Templin, Fred L > Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org > Subject: Re: [DMM] DMM WG next steps >=20 > Fred, >=20 > On Mar 11, 2014, at 11:48 PM, "Templin, Fred L" wrote: >=20 > > Hi Jouni, > > > > I think AERO fits paragraph 3 of the proposed new charter. AERO is a > > mobility solution for IPv6, where each node gets at least a /64. It > > has in-built route optimization, and can run over either IPv6 or IPv4 > > networks as a "link layer" for mobility. AERO expects a distributed > > mobility management environment, where a network of servers and > > relays keeps track of mobile node locations without single point > > of failure concerns. > > > > AERO is somewhat like MIPv6, but differs in that it treats the > > underlying network as a link-layer for IPv6 using a non-broadcast > > multiple access (NBMA) interface model. AERO uses IPv6 ND messaging > > and the IPv6 neighbor cache on the AERO "link" instead of MIPv6 > > mechanisms, and uses DHCPv6 PD exchanges instead of RS/RA for mobile > > node coordinations. The mobile nodes can therefore act as mobile > > routers and can provide stable network access for their connected > > networks (where each mobile node and its connected networks is > > a "site"). > > > > Here is a pointer to the spec. Please have a look and let me know > > what you think, >=20 > There has been zero prior discussion or activity on this > topic in DMM that I recall. Furthermore, the current draft > seems to be a bis of RFC6707, driven by a single individual > and quite far in the preparation so I do not see a reason > involving this into the WG work. AERO is about mobility in general and distributed mobility management in particular. It also provides a solution to the route optimization problem cited in RFC5522 (which came from MEXT). AERO should be of interest to anyone interested in network mobilitiy, route optimization and distributed mobility management. IMHO, it is a better way of doing things than prior methods and this group would do well to consider it. Thanks - Fred fred.l.templin@boeing.com=20 =20 > - JOuni >=20 >=20 > > > > https://datatracker.ietf.org/doc/draft-templin-aerolink/ > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen > >> Sent: Wednesday, March 05, 2014 2:10 AM > >> To: dmm@ietf.org > >> Cc: dmm-chairs@tools.ietf.org > >> Subject: [DMM] DMM WG next steps > >> > >> Folks, > >> > >> DMM WG has done some progress lately. The requirements document has > >> already left the building and the gap analysis is heading to WGLC as > >> we speak. It is about the time to think what we should do next now > >> that we have grown out of the infancy. > >> > >> A smaller group of mobility enthusiasts have been discussing about > >> possible next steps and how the possible new charter would look like. > >> The current very draft text template can be found here: > >> https://github.com/jounikor/dmm-re-charter > >> > >> As you can see, we are still in early stages and all input it welcome. > >> Obviously, possible re-chartering depends on many things. For example, > >> things like getting the gap analysis out of the WG and what the IESG > >> says. Nothing has been fixed or decided yet. Anyhow, we will start the > >> discussion on re-chartering with the expectation that the DMM WG will > >> re-charter and continue developing new solutions and/or enhancements > >> in the IP mobility space. > >> > >> - Jouni & Dapeng > >> > >> _______________________________________________ > >> dmm mailing list > >> dmm@ietf.org > >> https://www.ietf.org/mailman/listinfo/dmm From nobody Mon Mar 17 17:36:58 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B941A02E0 for ; Mon, 17 Mar 2014 17:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DyhI3NhFKvR for ; Mon, 17 Mar 2014 17:36:54 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id E9E5E1A0289 for ; Mon, 17 Mar 2014 17:36:53 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id b8so4187103lan.40 for ; Mon, 17 Mar 2014 17:36:45 -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-type; bh=KtK55VD1h0hnO7Jy9+qbNTkKQqChGTCIBmR7vY0mBSI=; b=qP0CRHxny7wzFNpmznLrrapCP/oq9IcmhTCsoNreSt9yLW0aqYbqM0r7gXKx85gSMT 6gVJP9mR8l3sxCmocm/YHS0DvUmn86dzGVIwkUyREeOlAMtfputhzTL826zfWwZThVqt H5VhrvXXVPfIE8TCm6e645E+qMkuiK6abNc2JGpleoMvXCfKqoIJarUSbSLnzPTzpXL+ 8zvRX2kpr63CewOiYoWSFmzmrRDnSNDZgSrGzeQenFawNeqdsLkuwdR+0E1vIXG0mvAj 55YokYsiOeeKoy+drHivelbDm1W7bLTGK66RjYUE/sWJ9WWT/6qscYIOHxfGdyAzWNjY uY9Q== MIME-Version: 1.0 X-Received: by 10.152.202.7 with SMTP id ke7mr3941894lac.30.1395103005061; Mon, 17 Mar 2014 17:36:45 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Mon, 17 Mar 2014 17:36:44 -0700 (PDT) In-Reply-To: <2134F8430051B64F815C691A62D9831820153C@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181EC042@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831820153C@XCH-BLV-504.nw.nos.boeing.com> Date: Mon, 17 Mar 2014 19:36:44 -0500 Message-ID: From: Behcet Sarikaya To: "Templin, Fred L" Content-Type: multipart/alternative; boundary=001a1137ef8e0ab74804f4d6bb83 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/kCyGlXXxdn42EVKxX3L9awg4kEg Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 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, 18 Mar 2014 00:36:56 -0000 --001a1137ef8e0ab74804f4d6bb83 Content-Type: text/plain; charset=ISO-8859-1 Hi Fred, Why don't you submit it as a solution draft to dmm? Then you can push for your draft instead of arguing for something that we don't know what. Regards, Behcet On Mon, Mar 17, 2014 at 1:31 PM, Templin, Fred L wrote: > Hi Jouni, > > > -----Original Message----- > > From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] > > Sent: Saturday, March 15, 2014 9:04 PM > > To: Templin, Fred L > > Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org > > Subject: Re: [DMM] DMM WG next steps > > > > Fred, > > > > On Mar 11, 2014, at 11:48 PM, "Templin, Fred L" < > Fred.L.Templin@boeing.com> wrote: > > > > > Hi Jouni, > > > > > > I think AERO fits paragraph 3 of the proposed new charter. AERO is a > > > mobility solution for IPv6, where each node gets at least a /64. It > > > has in-built route optimization, and can run over either IPv6 or IPv4 > > > networks as a "link layer" for mobility. AERO expects a distributed > > > mobility management environment, where a network of servers and > > > relays keeps track of mobile node locations without single point > > > of failure concerns. > > > > > > AERO is somewhat like MIPv6, but differs in that it treats the > > > underlying network as a link-layer for IPv6 using a non-broadcast > > > multiple access (NBMA) interface model. AERO uses IPv6 ND messaging > > > and the IPv6 neighbor cache on the AERO "link" instead of MIPv6 > > > mechanisms, and uses DHCPv6 PD exchanges instead of RS/RA for mobile > > > node coordinations. The mobile nodes can therefore act as mobile > > > routers and can provide stable network access for their connected > > > networks (where each mobile node and its connected networks is > > > a "site"). > > > > > > Here is a pointer to the spec. Please have a look and let me know > > > what you think, > > > > There has been zero prior discussion or activity on this > > topic in DMM that I recall. Furthermore, the current draft > > seems to be a bis of RFC6707, driven by a single individual > > and quite far in the preparation so I do not see a reason > > involving this into the WG work. > > AERO is about mobility in general and distributed mobility management > in particular. It also provides a solution to the route optimization > problem cited in RFC5522 (which came from MEXT). > > AERO should be of interest to anyone interested in network mobilitiy, > route optimization and distributed mobility management. IMHO, it is > a better way of doing things than prior methods and this group would > do well to consider it. > > Thanks - Fred > fred.l.templin@boeing.com > > > - JOuni > > > > > > > > > > https://datatracker.ietf.org/doc/draft-templin-aerolink/ > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > >> -----Original Message----- > > >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen > > >> Sent: Wednesday, March 05, 2014 2:10 AM > > >> To: dmm@ietf.org > > >> Cc: dmm-chairs@tools.ietf.org > > >> Subject: [DMM] DMM WG next steps > > >> > > >> Folks, > > >> > > >> DMM WG has done some progress lately. The requirements document has > > >> already left the building and the gap analysis is heading to WGLC as > > >> we speak. It is about the time to think what we should do next now > > >> that we have grown out of the infancy. > > >> > > >> A smaller group of mobility enthusiasts have been discussing about > > >> possible next steps and how the possible new charter would look like. > > >> The current very draft text template can be found here: > > >> https://github.com/jounikor/dmm-re-charter > > >> > > >> As you can see, we are still in early stages and all input it welcome. > > >> Obviously, possible re-chartering depends on many things. For example, > > >> things like getting the gap analysis out of the WG and what the IESG > > >> says. Nothing has been fixed or decided yet. Anyhow, we will start the > > >> discussion on re-chartering with the expectation that the DMM WG will > > >> re-charter and continue developing new solutions and/or enhancements > > >> in the IP mobility space. > > >> > > >> - 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 > --001a1137ef8e0ab74804f4d6bb83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Fred,

Why don't yo= u submit it as a solution draft to dmm?

Then you can push for = your draft instead of arguing for something that we don't know what.
Regards,

Behcet

=
On Mon, Mar 17, 2014 at 1:31 PM, Templin, Fr= ed L <Fred.L.Templin@boeing.com> wrote:
Hi Jouni,

> -----Original Message-----
> From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]
> Sent: Saturday, March 15, 2014 9:04 PM
> To: Templin, Fred L
> Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org
> Subject: Re: [DMM] DMM WG next steps
>
> Fred,
>
> On Mar 11, 2014, at 11:48 PM, "Templin, Fred L" <Fred.L.Templin@boeing.com> wro= te:
>
> > Hi Jouni,
> >
> > I think AERO fits paragraph 3 of the proposed new charter. AERO i= s a
> > mobility solution for IPv6, where each node gets at least a /64. = It
> > has in-built route optimization, and can run over either IPv6 or = IPv4
> > networks as a "link layer" for mobility. AERO expects a= distributed
> > mobility management environment, where a network of servers and > > relays keeps track of mobile node locations without single point<= br> > > of failure concerns.
> >
> > AERO is somewhat like MIPv6, but differs in that it treats the > > underlying network as a link-layer for IPv6 using a non-broadcast=
> > multiple access (NBMA) interface model. AERO uses IPv6 ND messagi= ng
> > and the IPv6 neighbor cache on the AERO "link" instead = of MIPv6
> > mechanisms, and uses DHCPv6 PD exchanges instead of RS/RA for mob= ile
> > node coordinations. The mobile nodes can therefore act as mobile<= br> > > routers and can provide stable network access for their connected=
> > networks (where each mobile node and its connected networks is > > a "site").
> >
> > Here is a pointer to the spec. Please have a look and let me know=
> > what you think,
>
> There has been zero prior discussion or activity on this
> topic in DMM that I recall. Furthermore, the current draft
> seems to be a bis of RFC6707, driven by a single individual
> and quite far in the preparation so I do not see a reason
> involving this into the WG work.

AERO is about mobility in general and distributed mobility mana= gement
in particular. It also provides a solution to the route optimization
problem cited in RFC5522 (which came from MEXT).

AERO should be of interest to anyone interested in network mobilitiy,
route optimization and distributed mobility management. IMHO, it is
a better way of doing things than prior methods and this group would
do well to consider it.

Thanks - Fred
fred.l.templin@boeing.com<= br>

> - JOuni
>
>
> >
> > https://datatracker.ietf.org/doc/draft-templin-aeroli= nk/
> >
> > Thanks - Fred
> > fred.l.templin@boein= g.com
> >
> >> -----Original Message-----
> >> From: dmm [mailto:dmm= -bounces@ietf.org] On Behalf Of Jouni Korhonen
> >> Sent: Wednesday, March 05, 2014 2:10 AM
> >> To: dmm@ietf.org
> >> Cc: dmm-chairs@t= ools.ietf.org
> >> Subject: [DMM] DMM WG next steps
> >>
> >> Folks,
> >>
> >> DMM WG has done some progress lately. The requirements docume= nt has
> >> already left the building and the gap analysis is heading to = WGLC as
> >> we speak. It is about the time to think what we should do nex= t now
> >> that we have grown out of the infancy.
> >>
> >> A smaller group of mobility enthusiasts have been discussing = about
> >> possible next steps and how the possible new charter would lo= ok like.
> >> The current very draft text template can be found here:
> >> =A0 =A0https://github.com/jounikor/dmm-re-charter
> >>
> >> As you can see, we are still in early stages and all input it= welcome.
> >> Obviously, possible re-chartering depends on many things. For= example,
> >> things like getting the gap analysis out of the WG and what t= he IESG
> >> says. Nothing has been fixed or decided yet. Anyhow, we will = start the
> >> discussion on re-chartering with the expectation that the DMM= WG will
> >> re-charter and continue developing new solutions and/or enhan= cements
> >> in the IP mobility space.
> >>
> >> - Jouni & Dapeng
> >>
> >> _______________________________________________
> >> dmm mailing list
> >> dmm@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dmm

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

--001a1137ef8e0ab74804f4d6bb83-- From nobody Mon Mar 17 19:20:30 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0A61A034E for ; Mon, 17 Mar 2014 19:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qN4rnMEdQiWV for ; Mon, 17 Mar 2014 19:20:26 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 65F4F1A034D for ; Mon, 17 Mar 2014 19:20:26 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id p10so6324839pdj.26 for ; Mon, 17 Mar 2014 19:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=VlGXWMzK3db9O8gd1IMYla9XY34+XQ6/r5XPiykQ/OI=; b=wiYmbDnjoXNHQZtmaRKJQVYpem4ir7a4UzPrgqRDMjGv8idk5zxvKooelF9pKJ0j92 dQPUmDXmus8Ujn5T4w4pzA+Rb0tnQrI0YF9RxBnDyHAP+ipMe6Ue94opAOngIeaMiqDq dbSErygVXE+Ul8xVH0kExgfOAfPYL44IMYP/QlwbhZXx5afJul5Klf7qmB1HfriD8E6h Mhmanomeq7KKMaBFxUJP7N1IWt23rUZkfTuF0/LXg1dhR5g82PjViIzot3cjJ6s0nM+h ptwAug355lH/VFjRalh9NAPVLa0o5QC1neOMDNbaufXSDH8emMhFQy4ncXh+SySRP4rT tLoQ== X-Received: by 10.67.8.102 with SMTP id dj6mr29949524pad.10.1395109218325; Mon, 17 Mar 2014 19:20:18 -0700 (PDT) Received: from dhcp-18-187.meeting.verilan.com ([123.124.234.161]) by mx.google.com with ESMTPSA id tu3sm79899055pab.1.2014.03.17.19.20.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Mar 2014 19:20:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <47C1CC71-67F1-4AC7-96AA-48BF37040C29@gmail.com> Date: Tue, 18 Mar 2014 10:20:11 +0800 Content-Transfer-Encoding: 7bit Message-Id: <1502BDF5-6189-4297-8479-05B3345AC96A@gmail.com> References: <47C1CC71-67F1-4AC7-96AA-48BF37040C29@gmail.com> To: "dmm@ietf.org" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/BegAPTUl41M7B7DGIlIaCEsJuBY Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 02:20:28 -0000 Folks, Triggered by the question from Behcet, we should come up with the milestones. Few proposals: o The deployment models and scenarios I-D is obvious. o Anchor selection I-D is obvious. Could we also bundle the re-anchoring solution into this one or should it be a different I-D? o Mobility state exposing I-D. This would communication between the end host and the network. Maybe also covering the missing parts within the end host.. Are we OK with one I-D or how people want to see this? o .. - Jouni On Mar 17, 2014, at 2:41 PM, Jouni Korhonen wrote: > Folks, > > I have updated the charter draft text slightly: > https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt > > Basically: > > Added Sri's comment on PMIPv6 maintenance. > Added Alper's comment of location of mobility functions. > Added links to other IETF WGs on possible mobility enabling technologies. > Added a comment that virtualised network functions are in scope. > > - Jouni From nobody Mon Mar 17 20:49:28 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BD81A049C for ; Mon, 17 Mar 2014 20:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9k39xvj17yA9 for ; Mon, 17 Mar 2014 20:49:25 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF921A0371 for ; Mon, 17 Mar 2014 20:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1604; q=dns/txt; s=iport; t=1395114557; x=1396324157; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=DaGsDOrJPpZMtC2uReD2n52lBKD/w7niFTNAm3Chjyo=; b=O7xGWtumy9oX+7Ddebdpxgf8EHrpYRttszA+UZpdO4EKG17ETkxgf/V1 Yn8wxtN9ZFCrGCD6MYX4/yOF9/CyR321TJT60JG3d0hK2Lk6utZaemKb4 l7r9qJTMplLhKPfKptXMRKR98iscUt6c2hmQZrwaElmbBQxp9oBXkFox+ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAOfBJ1OtJXHB/2dsb2JhbABZgwaBEsIigScWdIIsOjgZAQg2MRElAgQBEhuHSgMRyX0NhzoXjEqCH4Q4AQOWWYFtjGiFSIMtgis X-IronPort-AV: E=Sophos;i="4.97,674,1389744000"; d="scan'208";a="28242795" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-8.cisco.com with ESMTP; 18 Mar 2014 03:49:15 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2I3nGtZ030908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Mar 2014 03:49:16 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.143]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Mon, 17 Mar 2014 22:49:15 -0500 From: "Sri Gundavelli (sgundave)" To: Jouni Korhonen , "dmm@ietf.org" Thread-Topic: [DMM] re-charter text updated Thread-Index: AQHPQl0IFo4qsJfMn0Op4Dq5/gIg4Q== Date: Tue, 18 Mar 2014 03:49:15 +0000 Message-ID: In-Reply-To: <1502BDF5-6189-4297-8479-05B3345AC96A@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.213] Content-Type: text/plain; charset="us-ascii" Content-ID: <28F31F04BFB5D3488DF5808CB06EA3D2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/ADocpCaMJYdYUrtRo6efmvMLo-Y Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 03:49:27 -0000 On 3/17/14 7:20 PM, "Jouni Korhonen" wrote: >Folks, > >Triggered by the question from Behcet, we should come up with the >milestones. Few proposals: > >o The deployment models and scenarios I-D is obvious. >o Anchor selection I-D is obvious. Could we also bundle > the re-anchoring solution into this one or should it be > a different I-D? IMO, these are two different topics and can be kept as separate work items. Anchor selection is tied to access network, request path, policy, handovers and load on the target elements. The entity using the gateway selection can be a end point, a network node or a policy system. The bulk of the work is around laying out the considerations for gateway selection and specifying the logic. The selection to most part is about the assigning a gateway during initial session establishment. Session Re-anchoring is about moving a session state between gateways, after the session got established. It has impact on the forwarding plane and is more about a routing problem. But, you may argue this is also touching the aspect of gateway (re)-selection at a failure point. In this sense there is some relation there, but it depends on how the re-anchoring solution is specified. IMO, its better to track them as separate work items. >o Mobility state exposing I-D. This would communication > between the end host and the network. Maybe also covering > the missing parts within the end host.. Are we OK with one > I-D or how people want to see this? Single ID is fine.=20 Regards Sri From nobody Mon Mar 17 21:07:11 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262821A04B4 for ; Mon, 17 Mar 2014 21:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuqrwzI7grnp for ; Mon, 17 Mar 2014 21:07:06 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id C04111A0267 for ; Mon, 17 Mar 2014 21:07:05 -0700 (PDT) X-ASG-Debug-ID: 1395115616-06daaa24ad2dfe00001-HzFf3l Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id 1fDrwmBggQTrAXgJ for ; Tue, 18 Mar 2014 00:06:56 -0400 (EDT) X-Barracuda-Envelope-From: JuanCarlos.Zuniga@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Mar 2014 00:07:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Mar 2014 00:07:40 -0400 X-ASG-Orig-Subj: RE: [DMM] re-charter text updated Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [DMM] re-charter text updated Thread-Index: AQHPQl0IFo4qsJfMn0Op4Dq5/gIg4ZrmOfZA References: <1502BDF5-6189-4297-8479-05B3345AC96A@gmail.com> From: "Zuniga, Juan Carlos" To: "Sri Gundavelli (sgundave)" , "Jouni Korhonen" , X-OriginalArrivalTime: 18 Mar 2014 04:07:41.0589 (UTC) FILETIME=[9B8A4450:01CF425F] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1395115616 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.4013 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Ia8mSqLRhZtPVDXJhLhZXSFb314 Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 04:07:08 -0000 Hi, > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli > (sgundave) > Sent: Monday, March 17, 2014 11:49 PM > To: Jouni Korhonen; dmm@ietf.org > Subject: Re: [DMM] re-charter text updated >=20 >=20 >=20 > On 3/17/14 7:20 PM, "Jouni Korhonen" wrote: >=20 > >Folks, > > > >Triggered by the question from Behcet, we should come up with the > >milestones. Few proposals: > > > >o The deployment models and scenarios I-D is obvious. > >o Anchor selection I-D is obvious. Could we also bundle > > the re-anchoring solution into this one or should it be > > a different I-D? >=20 >=20 > IMO, these are two different topics and can be kept as separate work items. >=20 > Anchor selection is tied to access network, request path, policy, handovers > and load on the target elements. The entity using the gateway selection can > be a end point, a network node or a policy system. The bulk of the work is > around laying out the considerations for gateway selection and specifying > the logic. The selection to most part is about the assigning a gateway during > initial session establishment. >=20 > Session Re-anchoring is about moving a session state between gateways, > after the session got established. It has impact on the forwarding plane and > is more about a routing problem. But, you may argue this is also touching > the aspect of gateway (re)-selection at a failure point. In this sense there is > some relation there, but it depends on how the re-anchoring solution is > specified. >=20 > IMO, its better to track them as separate work items. [JCZ] +1 >=20 >=20 > >o Mobility state exposing I-D. This would communication > > between the end host and the network. Maybe also covering > > the missing parts within the end host.. Are we OK with one > > I-D or how people want to see this? >=20 >=20 > Single ID is fine. [JCZ] Single ID is fine indeed. However, we still need to assess whether this will be a DMM or a MIF ID. Regards, Juan Carlos >=20 >=20 > Regards > Sri >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Tue Mar 18 00:00:07 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5B21A065F for ; Tue, 18 Mar 2014 00:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkLK-2-2rA3T for ; Tue, 18 Mar 2014 00:00:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 89F781A044A for ; Mon, 17 Mar 2014 23:59:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BER28120; Tue, 18 Mar 2014 06:59:50 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Mar 2014 06:59:47 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Mar 2014 06:59:49 +0000 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.24]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 18 Mar 2014 14:59:40 +0800 From: Weixinpeng To: Alper Yegin , Jouni Korhonen Thread-Topic: [DMM] DMM WG next steps Thread-Index: AQHPOHNv2zGsFUMmEUyW6mjUEN637ZrmeOGg Date: Tue, 18 Mar 2014 06:59:40 +0000 Message-ID: References: <30507101-509F-4CE0-AF77-BDF03BAE810C@yegin.org> In-Reply-To: <30507101-509F-4CE0-AF77-BDF03BAE810C@yegin.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.176] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46D7F9E04nkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/4bVPUhLWxmhKQd1R8m_Ns-YlxJw Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 07:00:03 -0000 --_000_C5C3BB522B1DDF478AA09545169155B46D7F9E04nkgeml507mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alper, Is there any essential difference between placing the mobility function clo= ser to the user and placing the mobility function closer to the CN? I think in some sense the user ho= st and it's corresponding node are the same for mobility management protoco= l. So what's the reason to distinguish between them? BR, xinpeng From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin Sent: Wednesday, March 05, 2014 9:04 PM To: Jouni Korhonen Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org Subject: Re: [DMM] DMM WG next steps Jouni, Thanks for the text. DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user. This part excludes the approaches that place the mobility function on or ne= ar the CN. I recommend the following revision: DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user and/or its corresponding nodes. Alper On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote: Folks, DMM WG has done some progress lately. The requirements document has already left the building and the gap analysis is heading to WGLC as we speak. It is about the time to think what we should do next now that we have grown out of the infancy. A smaller group of mobility enthusiasts have been discussing about possible next steps and how the possible new charter would look like. The current very draft text template can be found here: https://github.com/jounikor/dmm-re-charter As you can see, we are still in early stages and all input it welcome. Obviously, possible re-chartering depends on many things. For example, things like getting the gap analysis out of the WG and what the IESG says. Nothing has been fixed or decided yet. Anyhow, we will start the discussion on re-chartering with the expectation that the DMM WG will re-charter and continue developing new solutions and/or enhancements in the IP mobility space. - Jouni & Dapeng _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --_000_C5C3BB522B1DDF478AA09545169155B46D7F9E04nkgeml507mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alper,<= o:p>

Is there a= ny essential difference between placing the mobility function closer to the= user  and placing

the mobili= ty function closer to the CN?   I think in some sense the user ho= st and it’s corresponding node are the same for mobility management protocol.

So what= 217;s the reason to distinguish between them?

 = ;

BR,

xinpeng

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin
Sent: Wednesday, March 05, 2014 9:04 PM
To: Jouni Korhonen
Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org
Subject: Re: [DMM] DMM WG next steps

 

Jouni,

 

Thanks for the text.=

 

      DMM=
 can be used to realise such a distributed deployment

     &nbs=
p;model, by distributing mobility functions more closer to the user.

 

 

This part excludes the approach= es that place the mobility function on or near the CN.

 

I recommend the following revis= ion:

 

 

      DMM=
 can be used to realise such a distributed deployment

     &nbs=
p;model, by distributing mobility functions more closer to the user
      and=
/or its corresponding nodes.

 

Alper

 

 

 

 

 

 

On Mar 5, 2014, at 12:09 PM, Jo= uni Korhonen wrote:



Folks,

DMM WG has done some progress lately. The requirements document has
already left the building and the gap analysis is heading to WGLC as
we speak. It is about the time to think what we should do next now
that we have grown out of the infancy.

A smaller group of mobility enthusiasts have been discussing about
possible next steps and how the possible new charter would look like.
The current very draft text template can be found here:
     https://github.com/jounikor/dmm-= re-charter

As you can see, we are still in early stages and all input it welcome.
Obviously, possible re-chartering depends on many things. For example,
things like getting the gap analysis out of the WG and what the IESG
says. Nothing has been fixed or decided yet. Anyhow, we will start the
discussion on re-chartering with the expectation that the DMM WG will
re-charter and continue developing new solutions and/or enhancements
in the IP mobility space.

- Jouni & Dapeng

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

 

--_000_C5C3BB522B1DDF478AA09545169155B46D7F9E04nkgeml507mbxchi_-- From nobody Tue Mar 18 00:15:17 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9121A0085 for ; Tue, 18 Mar 2014 00:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mluz4FZE0bOg for ; Tue, 18 Mar 2014 00:10:03 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id B05A01A001B for ; Tue, 18 Mar 2014 00:10:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=EcxfEsZAngN0cj12X39Ir1EnwWLiMRybYSUbRFIzHdNfpI9Vf4NUwDelAhyeoLgq; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Transfer-Encoding:X-Mailer:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.41] (helo=elwamui-mouette.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WPo8x-0000uz-Sx; Tue, 18 Mar 2014 03:08:59 -0400 Received: from 123.124.234.161 by webmail.earthlink.net with HTTP; Tue, 18 Mar 2014 03:08:59 -0400 Message-ID: <4657461.1395126539884.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Date: Tue, 18 Mar 2014 00:08:59 -0700 (GMT-07:00) From: "Charlie P." To: Weixinpeng , Alper Yegin , Jouni Korhonen Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 Content-Type: text/html; charset=UTF-8 X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86be1c4c362d5a24af3c880469f71f53bc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.41 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/FjqWunLBOJhHqMNfNKEsM2i_f7A X-Mailman-Approved-At: Tue, 18 Mar 2014 00:15:16 -0700 Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: [DMM] Where to place mobility functions X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Charlie P." List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 07:10:05 -0000 Hello folks,
<= br>One difference is that a mobile node is likely to be located in a networ= k that supports mobility, whereas the network hosting a general CN may not = have any mobility support features.

Regards,
Charlie P.

-----Original Message-----
From: Weixinpeng
Sent: Mar 17, 2014 11:59 PM
To: Alper Yegin , Jouni Korhonen
Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org"
Subject: Re: [DMM] DMM WG next steps

Hi Alper,<= o:p>

Is there a= ny essential difference between placing the mobility function closer to the= user  and placing

the mobili= ty function closer to the CN?   I think in some sense the user ho= st and it=E2=80=99s corresponding node are the same for mobility management protocol.

So what=E2= =80=99s the reason to distinguish between them?

 = ;

BR,

xinpeng

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin
Sent: Wednesday, March 05, 2014 9:04 PM
To: Jouni Korhonen
Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org
Subject: Re: [DMM] DMM WG next steps

 

Jouni,

 

Thanks for the text.=

 

      DMM=
 can be used to realise such a distributed deployment

     &nbs=
p;model, by distributing mobility functions more closer to the user.

 

 

This part excludes the approach= es that place the mobility function on or near the CN.

 

I recommend the following revis= ion:

 

 

      DMM=
 can be used to realise such a distributed deployment

     &nbs=
p;model, by distributing mobility functions more closer to the user
      and=
/or its corresponding nodes.

 

Alper

 

 

 

 

 

 

On Mar 5, 2014, at 12:09 PM, Jo= uni Korhonen wrote:



Folks,

DMM WG has done some progress lately. The requirements document has
already left the building and the gap analysis is heading to WGLC as
we speak. It is about the time to think what we should do next now
that we have grown out of the infancy.

A smaller group of mobility enthusiasts have been discussing about
possible next steps and how the possible new charter would look like.
The current very draft text template can be found here:
     https://github= .com/jounikor/dmm-re-charter

As you can see, we are still in early stages and all input it welcome.
Obviously, possible re-chartering depends on many things. For example,
things like getting the gap analysis out of the WG and what the IESG
says. Nothing has been fixed or decided yet. Anyhow, we will start the
discussion on re-chartering with the expectation that the DMM WG will
re-charter and continue developing new solutions and/or enhancements
in the IP mobility space.

- Jouni & Dapeng

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

 
From nobody Tue Mar 18 01:41:31 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B510E1A03BD for ; Tue, 18 Mar 2014 01:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Yt8j7Vz930R for ; Tue, 18 Mar 2014 01:41:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 88E9C1A03A7 for ; Tue, 18 Mar 2014 01:41:28 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 8FDE53742EC; Tue, 18 Mar 2014 09:41:19 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 5CC5515807E; Tue, 18 Mar 2014 09:41:19 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 18 Mar 2014 09:41:19 +0100 From: To: "Zuniga, Juan Carlos" , "Sri Gundavelli (sgundave)" , Jouni Korhonen , "dmm@ietf.org" Thread-Topic: [DMM] re-charter text updated Thread-Index: AQHPQav8IqXuPPIWy06iKl9XwXGj+5rmDRGAgAAY44CAAAUlAIAAVVPA Date: Tue, 18 Mar 2014 08:41:18 +0000 Message-ID: <25923_1395132079_532806AF_25923_3978_1_81C77F07008CA24F9783A98CFD706F711420EAA3@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <1502BDF5-6189-4297-8479-05B3345AC96A@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.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.18.43915 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/ipkUJPEAFcsKnuNT_w7YLO0ZLqM Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 08:41:30 -0000 Hi, Mobility issues are not specifically in MIF scope. So, as long as we are ta= lking about exposing mobility state, the I-D should be in DMM. Another reas= on is that MIF is still discussing the generic MIF API, so, I'm not sure th= ey can go on the mobility area before a while. Pierrick >-----Message d'origine----- >De=A0: dmm [mailto:dmm-bounces@ietf.org] De la part de Zuniga, Juan Carlos >Envoy=E9=A0: mardi 18 mars 2014 05:08 >=C0=A0: Sri Gundavelli (sgundave); Jouni Korhonen; dmm@ietf.org >Objet=A0: Re: [DMM] re-charter text updated > >Hi, > >> -----Original Message----- >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli >> (sgundave) >> Sent: Monday, March 17, 2014 11:49 PM >> To: Jouni Korhonen; dmm@ietf.org >> Subject: Re: [DMM] re-charter text updated >> >> >> >> On 3/17/14 7:20 PM, "Jouni Korhonen" wrote: >> >> >Folks, >> > >> >Triggered by the question from Behcet, we should come up with the >> >milestones. Few proposals: >> > >> >o The deployment models and scenarios I-D is obvious. >> >o Anchor selection I-D is obvious. Could we also bundle >> > the re-anchoring solution into this one or should it be >> > a different I-D? >> >> >> IMO, these are two different topics and can be kept as separate work >items. >> >> Anchor selection is tied to access network, request path, policy, >handovers >> and load on the target elements. The entity using the gateway >selection can >> be a end point, a network node or a policy system. The bulk of the >work is >> around laying out the considerations for gateway selection and >specifying >> the logic. The selection to most part is about the assigning a gateway >during >> initial session establishment. >> >> Session Re-anchoring is about moving a session state between gateways, >> after the session got established. It has impact on the forwarding >plane and >> is more about a routing problem. But, you may argue this is also >touching >> the aspect of gateway (re)-selection at a failure point. In this sense >there is >> some relation there, but it depends on how the re-anchoring solution >is >> specified. >> >> IMO, its better to track them as separate work items. > >[JCZ] +1 > >> >> >> >o Mobility state exposing I-D. This would communication >> > between the end host and the network. Maybe also covering >> > the missing parts within the end host.. Are we OK with one >> > I-D or how people want to see this? >> >> >> Single ID is fine. > >[JCZ] Single ID is fine indeed. However, we still need to assess whether t= his >will be a DMM or a MIF ID. > >Regards, > >Juan Carlos > >> >> >> Regards >> Sri >> >> _______________________________________________ >> 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 ___________________________________________________________________________= ______________________________________________ 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 Tue Mar 18 02:07:25 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721931A06BF for ; Tue, 18 Mar 2014 02:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76y7Zjq8maCb for ; Tue, 18 Mar 2014 02:07:21 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 838FE1A06B1 for ; Tue, 18 Mar 2014 02:07:21 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LnPio-1X31oj2asA-00h62p; Tue, 18 Mar 2014 05:07:12 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: <1502BDF5-6189-4297-8479-05B3345AC96A@gmail.com> Date: Tue, 18 Mar 2014 11:07:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0A1920BD-67A7-4ECF-9EF7-7789891CF3D3@yegin.org> References: <47C1CC71-67F1-4AC7-96AA-48BF37040C29@gmail.com> <1502BDF5-6189-4297-8479-05B3345AC96A@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:L9lCNLp1mg0T7maSC6SrNJArpd/e9SUDzQ5WxhoWhLx rnw8CtbxbWc5nZqkWK2Fs6Ro8AJklExRl8nRdbVv/lpj39S6lG T/1Q1RLnhjNbMkZprdSTWK22oibsnsiFBk6htV2d58/AZ2OMsr H36roGwfwbNGqe7BT4vlhgphS6kXy2Ir1yoK+eBO+J5fBtU1mh cdqDMYUdF6POfJJj07+MxH8jRqCZ6fD+tl/OasM8LYxAlRBKpS TRYwmDr7ZrDnU5KU27Zm/vOD8yg1lVJg3n0FcgGkunMwEB3OQ4 LOUzcJomK3qiQ7j2brtDfAUzFkbNZ37c05qpwZbC9hGU4Mh6ix ZsEltPRhFqRk5h+eflV6jUWMyXtXxuOGDGhlEJlyKMO57CF5Fw GYvvAfKfAhLLw== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/KqwgIVnKGjy7GVe7EjjQeh83K5Y Cc: "dmm@ietf.org" Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 09:07:23 -0000 On Mar 18, 2014, at 4:20 AM, Jouni Korhonen wrote: > Folks, >=20 > Triggered by the question from Behcet, we should come up with the=20 > milestones. Few proposals: >=20 > o The deployment models and scenarios I-D is obvious. > o Anchor selection I-D is obvious. Could we also bundle > the re-anchoring solution into this one or should it be > a different I-D? I'd say re-anchoring is a separate I-D. Btw, I take "anchor selection" as the process/algorithm for selecting = the type of anchor (e.g., one in access or core or corresponding = network), and selecting a specific anchor node of that type (e.g., = determining its IP address). If so, that can be an I-D. But then, how the data-path is setup and maintained between the MN and = the anchor across handovers is another I-D.=20 And in fact, that's where more than one solutions is likely=85. So, = limiting this as "one I-D" may not work. > o Mobility state exposing I-D. This would communication=20 > between the end host and the network. Maybe also covering=20 > the missing parts within the end host.. Are we OK with one > I-D or how people want to see this? > o .. >=20 There's the API aspect on the terminal (one I-D), and there is the MN-network interface ones (e.g., extending RA, DHCP, = etc.) Alper > - Jouni >=20 >=20 > On Mar 17, 2014, at 2:41 PM, Jouni Korhonen = wrote: >=20 >> Folks, >>=20 >> I have updated the charter draft text slightly: >> = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >>=20 >> Basically: >>=20 >> Added Sri's comment on PMIPv6 maintenance. >> Added Alper's comment of location of mobility functions. >> Added links to other IETF WGs on possible mobility enabling = technologies. >> Added a comment that virtualised network functions are in scope. >>=20 >> - Jouni >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Tue Mar 18 02:08:20 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C861A06C3 for ; Tue, 18 Mar 2014 02:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qe4sxZVhNR70 for ; Tue, 18 Mar 2014 02:08:17 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id CC8FE1A06B1 for ; Tue, 18 Mar 2014 02:08:17 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MPUIT-1WUWy30bxp-005HW4; Tue, 18 Mar 2014 05:08:04 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: <25923_1395132079_532806AF_25923_3978_1_81C77F07008CA24F9783A98CFD706F711420EAA3@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Tue, 18 Mar 2014 11:07:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <86998C58-CD0E-44FA-87FD-4010E02B94B7@yegin.org> References: <1502BDF5-6189-4297-8479-05B3345AC96A@gmail.com> <25923_1395132079_532806AF_25923_3978_1_81C77F07008CA24F9783A98CFD706F711420EAA3@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:58N5UjzxUHfDhNu/EzScf5aBVypVfNFihHMwqwByYTA yMkhEYNMgRmLW80xrBm+Pj1Ip97U/M3XBClTlLT71HF3Vs9hPu iqzYPsIApjLyyC5aqJfNaytlaaRZ1NhziZvGD1IafM+8imcWFM JM9nLVTkH4eh3co3H8NmYmoPccQGJ5kv5o5KrihtwOpunM7KQT 2jEl0Qd4UuaPo9p8x/HyKmD4c6y6pOWCgSvcFdHYivJx3PLg44 lCcdjvoIzeVL120JSY6SNrvogVc7NJ0zrSWHD9fqF7H7XcCy2F Y5R8cmqgopqZPw/fJQKLjHNLF2KpGQdM2q6s6d1K3/QPMAXr/K OyZK9xTtwibBs5mWptvpQwp7e0+EnFGQAXNzmBKsb4YHcFnvWI hwyYB2APRz4eA== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/bJh7_yQhNKOEwtf_8n7e29JudPc Cc: "dmm@ietf.org" Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 09:08:19 -0000 I agree, let's not mixup DMM API with MIF API=85. On Mar 18, 2014, at 10:41 AM, wrote: > Hi, >=20 > Mobility issues are not specifically in MIF scope. So, as long as we = are talking about exposing mobility state, the I-D should be in DMM. = Another reason is that MIF is still discussing the generic MIF API, so, = I'm not sure they can go on the mobility area before a while. >=20 > Pierrick >=20 >> -----Message d'origine----- >> De : dmm [mailto:dmm-bounces@ietf.org] De la part de Zuniga, Juan = Carlos >> Envoy=E9 : mardi 18 mars 2014 05:08 >> =C0 : Sri Gundavelli (sgundave); Jouni Korhonen; dmm@ietf.org >> Objet : Re: [DMM] re-charter text updated >>=20 >> Hi, >>=20 >>> -----Original Message----- >>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli >>> (sgundave) >>> Sent: Monday, March 17, 2014 11:49 PM >>> To: Jouni Korhonen; dmm@ietf.org >>> Subject: Re: [DMM] re-charter text updated >>>=20 >>>=20 >>>=20 >>> On 3/17/14 7:20 PM, "Jouni Korhonen" wrote: >>>=20 >>>> Folks, >>>>=20 >>>> Triggered by the question from Behcet, we should come up with the >>>> milestones. Few proposals: >>>>=20 >>>> o The deployment models and scenarios I-D is obvious. >>>> o Anchor selection I-D is obvious. Could we also bundle >>>> the re-anchoring solution into this one or should it be >>>> a different I-D? >>>=20 >>>=20 >>> IMO, these are two different topics and can be kept as separate work >> items. >>>=20 >>> Anchor selection is tied to access network, request path, policy, >> handovers >>> and load on the target elements. The entity using the gateway >> selection can >>> be a end point, a network node or a policy system. The bulk of the >> work is >>> around laying out the considerations for gateway selection and >> specifying >>> the logic. The selection to most part is about the assigning a = gateway >> during >>> initial session establishment. >>>=20 >>> Session Re-anchoring is about moving a session state between = gateways, >>> after the session got established. It has impact on the forwarding >> plane and >>> is more about a routing problem. But, you may argue this is also >> touching >>> the aspect of gateway (re)-selection at a failure point. In this = sense >> there is >>> some relation there, but it depends on how the re-anchoring solution >> is >>> specified. >>>=20 >>> IMO, its better to track them as separate work items. >>=20 >> [JCZ] +1 >>=20 >>>=20 >>>=20 >>>> o Mobility state exposing I-D. This would communication >>>> between the end host and the network. Maybe also covering >>>> the missing parts within the end host.. Are we OK with one >>>> I-D or how people want to see this? >>>=20 >>>=20 >>> Single ID is fine. >>=20 >> [JCZ] Single ID is fine indeed. However, we still need to assess = whether this >> will be a DMM or a MIF ID. >>=20 >> Regards, >>=20 >> Juan Carlos >>=20 >>>=20 >>>=20 >>> Regards >>> Sri >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>=20 >> _______________________________________________ >> 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, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Tue Mar 18 02:20:46 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C171A06B9 for ; Tue, 18 Mar 2014 02:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO2HsbITKqY8 for ; Tue, 18 Mar 2014 02:20:43 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id CAE1C1A0690 for ; Tue, 18 Mar 2014 02:20:42 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MH0Be-1WM2YZ1Fre-00DxAj; Tue, 18 Mar 2014 05:19:42 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_D32186B4-7FD1-403D-971E-CE251A40364A" From: Alper Yegin In-Reply-To: <4657461.1395126539884.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Date: Tue, 18 Mar 2014 11:19:30 +0200 Message-Id: <7998EFA2-0203-4961-B290-F44E5814E3C6@yegin.org> References: <4657461.1395126539884.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> To: "Charlie P." , Weixinpeng X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:iNCVKkaBKzf08YkdeGyDYk1Uh2XbYwwm0W3mONKyh59 pMmiII4QIJGb5sMsmY88Su/L9TqSjuGv7BjtyOgV/0a5Lt34dt 2JYpODCweTDczo8mzviIKWEVB1IibCnNHOoUkT9Nde4+1IlLTz NkKumIcKAG9cI2wQHCzOTduhaPgisRZA4CFZukqfxAILBA+jBF ZYHsnFHTQ7K1RyQThlLeUdhidRb1BIS6hpLTwvjKJurOdSoFFI wUiSZyufUFCGCxUElzE9yvEjUYlZ2mz32vVAeeZahi1wK1PmTU KjNh6rUJj84Ly3J5wmUiJmt1cufuSkedcWvwFtQafHKg1ccLnt 2GeTW3NusK+Mh5GqWLsC6FXrqhlWMrvB1vQfMIy/eh/wh5Vqzs IkIghkkRO8kpQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/SnkTwAGwgTzevSYEKHCOHF2Su9Q Cc: dmm@ietf.org, dmm-chairs@tools.ietf.org Subject: Re: [DMM] Where to place mobility functions X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 09:20:45 -0000 --Apple-Mail=_D32186B4-7FD1-403D-971E-CE251A40364A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Xinpeng, In the legacy thinking, the mobility anchor is in the core network = (centrally-located HA). That's the basic Mobile IP design. Now people are also considering placing anchors in the access network. And then there's one more possibility, which is to place an anchor = near/on the corresponding node.=20 Please see the Cnet-homing presentation for more: = http://www.ietf.org/proceedings/87/slides/slides-87-dmm-2.pdf Questions/comments welcome. Charlie:=20 Yes, we cannot assume there'll be an anchor on/near every CN. Our = proposal takes that into account. In fact, today there's no anchor in every access network either. There's = basically none in any WiFi network today. Both situation is subject to change based on DMM developments. Alper On Mar 18, 2014, at 9:08 AM, Charlie P. wrote: > Hello folks, >=20 > One difference is that a mobile node is likely to be located in a = network that supports mobility, whereas the network hosting a general CN = may not have any mobility support features. >=20 > Regards, > Charlie P. >=20 > -----Original Message-----=20 > From: Weixinpeng=20 > Sent: Mar 17, 2014 11:59 PM=20 > To: Alper Yegin , Jouni Korhonen=20 > Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org"=20 > Subject: Re: [DMM] DMM WG next steps=20 >=20 > Hi Alper, > Is there any essential difference between placing the mobility = function closer to the user and placing > the mobility function closer to the CN? I think in some sense the = user host and it=92s corresponding node are the same for mobility = management protocol. > So what=92s the reason to distinguish between them? > =20 > BR, > xinpeng > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin > Sent: Wednesday, March 05, 2014 9:04 PM > To: Jouni Korhonen > Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org > Subject: Re: [DMM] DMM WG next steps > =20 > Jouni, > =20 > Thanks for the text. > =20 > DMM can be used to realise such a distributed deployment > model, by distributing mobility functions more closer to the = user. > =20 > =20 > This part excludes the approaches that place the mobility function on = or near the CN. > =20 > I recommend the following revision: > =20 > =20 > DMM can be used to realise such a distributed deployment > model, by distributing mobility functions more closer to the = user > and/or its corresponding nodes. > =20 > Alper > =20 > =20 > =20 > =20 > =20 > =20 > On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote: >=20 >=20 > Folks, >=20 > DMM WG has done some progress lately. The requirements document has > already left the building and the gap analysis is heading to WGLC as > we speak. It is about the time to think what we should do next now > that we have grown out of the infancy.=20 >=20 > A smaller group of mobility enthusiasts have been discussing about > possible next steps and how the possible new charter would look like.=20= > The current very draft text template can be found here: > https://github.com/jounikor/dmm-re-charter >=20 > As you can see, we are still in early stages and all input it welcome. > Obviously, possible re-chartering depends on many things. For example, > things like getting the gap analysis out of the WG and what the IESG > says. Nothing has been fixed or decided yet. Anyhow, we will start the > discussion on re-chartering with the expectation that the DMM WG will > re-charter and continue developing new solutions and/or enhancements > in the IP mobility space. >=20 > - Jouni & Dapeng >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > =20 --Apple-Mail=_D32186B4-7FD1-403D-971E-CE251A40364A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hello Xinpeng,

In the = legacy thinking, the mobility anchor is in the core network = (centrally-located HA). That's the basic Mobile IP design.
Now = people are also considering placing anchors in the access = network.
And then there's one more possibility, which is to = place an anchor near/on the corresponding = node. 

Please see the Cnet-homing = presentation for more: htt= p://www.ietf.org/proceedings/87/slides/slides-87-dmm-2.pdf
<= br>
Questions/comments = welcome.

Charlie: 

= Yes, we cannot assume there'll be an anchor on/near every CN. Our = proposal takes that into account.

In fact, = today there's no anchor in every access network either. There's = basically none in any WiFi network today.

Both = situation is subject to change based on DMM = developments.

Alper


=





On Mar 18, 2014, at 9:08 AM, Charlie P. = wrote:

Hello folks,

One difference is that a = mobile node is likely to be located in a network that supports mobility, = whereas the network hosting a general CN may not have any mobility = support features.

Regards,
Charlie = P.

-----Original Message----- 
From: Weixinpeng 
Se= nt: Mar 17, 2014 11:59 PM 
To: Alper Yegin , = Jouni Korhonen 
C= c: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps 

=
Hi = Alper,
Is there any essential difference between placing = the mobility function closer to the user  and = placing
the mobility function closer to the CN? =   I think in some sense the user host and it=92s corresponding = node are the same for mobility management = protocol.
So what=92s the reason to distinguish between = them?
 
xinpeng
From: dmm = [mailto:dmm-bounces@ietf.org] On Behalf Of Alper = Yegin
Sent: Wednesday, March 05, 2014 = 9:04 PM
To: Jouni = Korhonen
Cc: dmm@ietf.org; dmm-chairs@tools.ietf.orgSubject: Re: = [DMM] DMM WG next steps
 
Jouni,
 
Thanks for the = text.
 
 
 
This part excludes the approaches that = place the mobility function on or near the = CN.
 
I recommend the following = revision:
 
 
 
Alper
 
 
 
 
 
 
On Mar 5, 2014, at 12:09 PM, Jouni = Korhonen wrote:


Folks,

DMM WG has done some = progress lately. The requirements document has
already left the = building and the gap analysis is heading to WGLC as
we speak. It is = about the time to think what we should do next now
that we have grown = out of the infancy. 

A smaller group of = mobility enthusiasts have been discussing about
possible next steps = and how the possible new charter would look like. 
The current very draft = text template can be found here:
     https://github.com/jou= nikor/dmm-re-charter

As you can see, we are still in early = stages and all input it welcome.
Obviously, possible re-chartering = depends on many things. For example,
things like getting the gap = analysis out of the WG and what the IESG
says. Nothing has been fixed = or decided yet. Anyhow, we will start the
discussion on re-chartering = with the expectation that the DMM WG will
re-charter and continue = developing new solutions and/or enhancements
in the IP mobility = space.

- Jouni & = Dapeng

_______________________________________________
dmm = mailing list
dmm@ietf.org
https://www.ietf.org/ma= ilman/listinfo/dmm
 
<= /zzzhtml>
= --Apple-Mail=_D32186B4-7FD1-403D-971E-CE251A40364A-- From nobody Tue Mar 18 04:04:28 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FF61A03C9 for ; Tue, 18 Mar 2014 04:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJ9p6XkAWPTc for ; Tue, 18 Mar 2014 04:04:16 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8CE1A03D8 for ; Tue, 18 Mar 2014 04:04:16 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 1A6DC2AC372; Tue, 18 Mar 2014 12:04:07 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id B57F118005C; Tue, 18 Mar 2014 12:04:06 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 18 Mar 2014 12:04:06 +0100 From: To: Alper Yegin , Charlie P. , Weixinpeng Thread-Topic: [DMM] Where to place mobility functions Thread-Index: AQHPQotVVMDTcyItw0eSPoFwjfFE35rmpb5A Date: Tue, 18 Mar 2014 11:04:06 +0000 Message-ID: <15533_1395140647_53282826_15533_3650_1_81C77F07008CA24F9783A98CFD706F711420EC3F@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <4657461.1395126539884.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> <7998EFA2-0203-4961-B290-F44E5814E3C6@yegin.org> In-Reply-To: <7998EFA2-0203-4961-B290-F44E5814E3C6@yegin.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F711420EC3FPEXCVZYM12corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.18.43915 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/whCOcPKkI8FNMp4ifHUrAbghcOY Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] Where to place mobility functions X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 11:04:23 -0000 --_000_81C77F07008CA24F9783A98CFD706F711420EC3FPEXCVZYM12corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Distributing mobility anchors closer either to the MN or CN are both valid = scenarios. But, maybe there are other optimal anchor location; actually, he= re, we are seeking to reach optimal routing by placing the anchor closer to= the optimal data path. Also, we may also want to keep a centralized anchor= , for example, reachability purpose; in this case, we could say that data p= ath going via the central anchor is the "most" optimal, because of the reac= hability constraint. In CP/DP distributions scenarios, we may want to distr= ibute DP function and keep centralized some CP functions (e.g. billing... y= es, operators like this function :)). So, I think that anchoring location considerations should be more generic a= nd should focus on datapath management. I'd suggest the following rewording: ------- OLD TEXT ------------ by distributing mobility functions more closer to the user and/or its corre= sponding nodes. ---------- NEW TEXT --------- by distributing forwarding functions more closer to the optimal data path; = for example, closer either to the mobile user or the corresponding node. Pirrick De : dmm [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin Envoy=E9 : mardi 18 mars 2014 10:19 =C0 : Charlie P.; Weixinpeng Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org Objet : Re: [DMM] Where to place mobility functions Hello Xinpeng, In the legacy thinking, the mobility anchor is in the core network (central= ly-located HA). That's the basic Mobile IP design. Now people are also considering placing anchors in the access network. And then there's one more possibility, which is to place an anchor near/on = the corresponding node. Please see the Cnet-homing presentation for more: http://www.ietf.org/proce= edings/87/slides/slides-87-dmm-2.pdf Questions/comments welcome. Charlie: Yes, we cannot assume there'll be an anchor on/near every CN. Our proposal = takes that into account. In fact, today there's no anchor in every access network either. There's ba= sically none in any WiFi network today. Both situation is subject to change based on DMM developments. Alper On Mar 18, 2014, at 9:08 AM, Charlie P. wrote: Hello folks, One difference is that a mobile node is likely to be located in a network t= hat supports mobility, whereas the network hosting a general CN may not hav= e any mobility support features. Regards, Charlie P. -----Original Message----- From: Weixinpeng Sent: Mar 17, 2014 11:59 PM To: Alper Yegin , Jouni Korhonen Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps Hi Alper, Is there any essential difference between placing the mobility function clo= ser to the user and placing the mobility function closer to the CN? I think in some sense the user ho= st and it's corresponding node are the same for mobility management protoco= l. So what's the reason to distinguish between them? BR, xinpeng From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin Sent: Wednesday, March 05, 2014 9:04 PM To: Jouni Korhonen Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org Subject: Re: [DMM] DMM WG next steps Jouni, Thanks for the text. DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user. This part excludes the approaches that place the mobility function on or ne= ar the CN. I recommend the following revision: DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user and/or its corresponding nodes. Alper On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote: Folks, DMM WG has done some progress lately. The requirements document has already left the building and the gap analysis is heading to WGLC as we speak. It is about the time to think what we should do next now that we have grown out of the infancy. A smaller group of mobility enthusiasts have been discussing about possible next steps and how the possible new charter would look like. The current very draft text template can be found here: https://github.com/jounikor/dmm-re-charter As you can see, we are still in early stages and all input it welcome. Obviously, possible re-chartering depends on many things. For example, things like getting the gap analysis out of the WG and what the IESG says. Nothing has been fixed or decided yet. Anyhow, we will start the discussion on re-chartering with the expectation that the DMM WG will re-charter and continue developing new solutions and/or enhancements in the IP mobility space. - Jouni & Dapeng _______________________________________________ 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. --_000_81C77F07008CA24F9783A98CFD706F711420EC3FPEXCVZYM12corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

Distributing mobility anchors closer either= to the MN or CN are both valid scenarios. But, maybe there are other optim= al anchor location; actually, here, we are seeking to reach optimal routing by placing the anchor closer to the optimal data = path. Also, we may also want to keep a centralized anchor, for example, rea= chability purpose; in this case, we could say that data path going via the = central anchor is the “most” optimal, because of the reachability constraint. In CP/DP distributions scenarios, = we may want to distribute DP function and keep centralized some CP function= s (e.g. billing… yes, operators like this function J).

 

So, I think that anchoring location conside= rations should be more generic and should focus on datapath management. I&#= 8217;d suggest the following rewording:

 

------- OLD TEXT ------------

 

by distributing mobility functions more clo= ser to the user and/or its corresponding nodes.

 

 

---------- NEW TEXT ---------

 

by distributing forwarding functions more c= loser to the optimal data path; for example, closer either to the mobile us= er or the corresponding node.

 

Pirrick

 = ;

 = ;

De : dmm = [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin
Envoy=E9 : mardi 18 mars 2014 10:19
=C0 : Charlie P.; Weixinpeng
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions <was, Re= : DMM WG next steps>

 

Hello Xinpeng,

 

In the legacy thinking, the mobility anchor is in th= e core network (centrally-located HA). That's the basic Mobile IP design.

Now people are also considering placing anchors in t= he access network.

And then there's one more possibility, which is to p= lace an anchor near/on the corresponding node. 

 

Please see the Cnet-homing presentation for more:&nb= sp;http://www.ietf.org/proceedings/87/slides/slides-87-dmm-2.pdf

 

Questions/comments welcome.

 

Charlie: 

 

Yes, we cannot assume there'll be an anchor on/near = every CN. Our proposal takes that into account.

 

In fact, today there's no anchor in every access net= work either. There's basically none in any WiFi network today.

 

Both situation is subject to change based on DMM dev= elopments.

 

Alper

 

 

 

 

 

 

 

 

On Mar 18, 2014, at 9:08 AM, Charlie P. wrote:<= /o:p>



Hello folks,

One difference is that a mobile node is likely to be located in a network t= hat supports mobility, whereas the network hosting a general CN may not hav= e any mobility support features.

Regards,
Charlie P.

--= ---Original Message----- =
From: Weixinpeng 
Sent: Mar 17, 2014 11:59 PM 
To: Alper Yegin , Jouni K= orhonen 
Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" 
Subject: Re: [DMM] DMM WG next steps&= nbsp;


Hi Alper,

Is there any essential difference between placing the mobi= lity function closer to the user  and placing

the mobility function closer to the CN?   I thin= k in some sense the user host and it’s corresponding node are the same for mobility management protocol.<= /o:p>

So what’s the reason to distinguish between them?

 

BR,

xinpeng

From: dmm [mailto:dmm-bounces@ietf.org] <= /span>On Behalf Of Alper Yegin
Sent: Wednesday, M= arch 05, 2014 9:04 PM
To: Jouni Korhonen=
Cc: dmm@ietf.org;&n= bsp;dmm-chairs@tools.ie= tf.org
Subject: Re: [DMM]= DMM WG next steps

 

Jouni,

 

Thanks for the text.

 

   =
;   DMM can be used to realise such a distributed deployment
   =
;   model, by distributing mobility functions more closer to=
 the user.

 

 

This part excludes the approaches that place the mobility= function on or near the CN.<= /span>

 

I recommend the following revision:

 

 

   =
;   DMM can be used to realise such a distributed deployment
   =
;   model, by distributing mobility functions more closer to=
 the user
   =
;   and/or its corresponding nodes.

 

Alper

 

 

 

 

 

 

On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote:=




Folks,

DMM WG has done some progress lately. The requirements document has
already left the building and the gap analysis is heading to WGLC as
we speak. It is about the time to think what we should do next now
that we have grown out of the infancy. 

A smaller group of mobility enthusiasts have been discussing about
possible next steps and how the possible new charter would look like. 
The current very draft text template can be found here:
     https://github.com/jounikor/dmm-re-ch= arter

As you can see, we are still in early stages and all input it welcome.
Obviously, possible re-chartering depends on many things. For example,
things like getting the gap analysis out of the WG and what the IESG
says. Nothing has been fixed or decided yet. Anyhow, we will start the
discussion on re-chartering with the expectation that the DMM WG will
re-charter and continue developing new solutions and/or enhancements
in the IP mobility space.

- Jouni & Dapeng

_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://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.
--_000_81C77F07008CA24F9783A98CFD706F711420EC3FPEXCVZYM12corpo_-- From nobody Tue Mar 18 05:43:41 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8161A03D3 for ; Tue, 18 Mar 2014 05:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWdUil8KO-xk for ; Tue, 18 Mar 2014 05:43:34 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5991A03D1 for ; Tue, 18 Mar 2014 05:43:33 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 9DBAB22C47D; Tue, 18 Mar 2014 13:43:23 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id BAED627C054; Tue, 18 Mar 2014 13:43:22 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 18 Mar 2014 13:43:18 +0100 From: To: SEITE Pierrick IMT/OLN , Alper Yegin , Charlie P. , Weixinpeng Thread-Topic: [DMM] Where to place mobility functions Thread-Index: AQHPQotVVMDTcyItw0eSPoFwjfFE35rmpb5AgAAjw/A= Date: Tue, 18 Mar 2014 12:43:17 +0000 Message-ID: <6979_1395146603_53283F6B_6979_768_1_8da19a47-f4d0-4410-bd96-0b54e482333a@PEXCVZYH01.corporate.adroot.infra.ftgroup> References: <4657461.1395126539884.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> <7998EFA2-0203-4961-B290-F44E5814E3C6@yegin.org> <15533_1395140647_53282826_15533_3650_1_81C77F07008CA24F9783A98CFD706F711420EC3F@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <15533_1395140647_53282826_15533_3650_1_81C77F07008CA24F9783A98CFD706F711420EC3F@PEXCVZYM12.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.197.38.6] Content-Type: multipart/alternative; boundary="_000_8da19a47f4d04410bd960b54e482333aPEXCVZYH01corporateadro_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/7jJnZTLrAwqvb-TdYNd9RNFnlxE Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] Where to place mobility functions X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 12:43:39 -0000 --_000_8da19a47f4d04410bd960b54e482333aPEXCVZYH01corporateadro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I realize that I gave a very bad example of centralized control functions..= . In our context, we should rather talk about centralized mobility control = function (with distributed DP function)... anyway, my proposal for text rev= ision is still valid. De : dmm [mailto:dmm-bounces@ietf.org] De la part de pierrick.seite@orange.= com Envoy=E9 : mardi 18 mars 2014 12:04 =C0 : Alper Yegin; Charlie P.; Weixinpeng Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org Objet : Re: [DMM] Where to place mobility functions Hello, Distributing mobility anchors closer either to the MN or CN are both valid = scenarios. But, maybe there are other optimal anchor location; actually, he= re, we are seeking to reach optimal routing by placing the anchor closer to= the optimal data path. Also, we may also want to keep a centralized anchor= , for example, reachability purpose; in this case, we could say that data p= ath going via the central anchor is the "most" optimal, because of the reac= hability constraint. In CP/DP distributions scenarios, we may want to distr= ibute DP function and keep centralized some CP functions (e.g. billing... y= es, operators like this function :)). So, I think that anchoring location considerations should be more generic a= nd should focus on datapath management. I'd suggest the following rewording: ------- OLD TEXT ------------ by distributing mobility functions more closer to the user and/or its corre= sponding nodes. ---------- NEW TEXT --------- by distributing forwarding functions more closer to the optimal data path; = for example, closer either to the mobile user or the corresponding node. Pirrick De : dmm [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin Envoy=E9 : mardi 18 mars 2014 10:19 =C0 : Charlie P.; Weixinpeng Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org Objet : Re: [DMM] Where to place mobility functions Hello Xinpeng, In the legacy thinking, the mobility anchor is in the core network (central= ly-located HA). That's the basic Mobile IP design. Now people are also considering placing anchors in the access network. And then there's one more possibility, which is to place an anchor near/on = the corresponding node. Please see the Cnet-homing presentation for more: http://www.ietf.org/proce= edings/87/slides/slides-87-dmm-2.pdf Questions/comments welcome. Charlie: Yes, we cannot assume there'll be an anchor on/near every CN. Our proposal = takes that into account. In fact, today there's no anchor in every access network either. There's ba= sically none in any WiFi network today. Both situation is subject to change based on DMM developments. Alper On Mar 18, 2014, at 9:08 AM, Charlie P. wrote: Hello folks, One difference is that a mobile node is likely to be located in a network t= hat supports mobility, whereas the network hosting a general CN may not hav= e any mobility support features. Regards, Charlie P. -----Original Message----- From: Weixinpeng Sent: Mar 17, 2014 11:59 PM To: Alper Yegin , Jouni Korhonen Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps Hi Alper, Is there any essential difference between placing the mobility function clo= ser to the user and placing the mobility function closer to the CN? I think in some sense the user ho= st and it's corresponding node are the same for mobility management protoco= l. So what's the reason to distinguish between them? BR, xinpeng From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin Sent: Wednesday, March 05, 2014 9:04 PM To: Jouni Korhonen Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org Subject: Re: [DMM] DMM WG next steps Jouni, Thanks for the text. DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user. This part excludes the approaches that place the mobility function on or ne= ar the CN. I recommend the following revision: DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user and/or its corresponding nodes. Alper On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote: Folks, DMM WG has done some progress lately. The requirements document has already left the building and the gap analysis is heading to WGLC as we speak. It is about the time to think what we should do next now that we have grown out of the infancy. A smaller group of mobility enthusiasts have been discussing about possible next steps and how the possible new charter would look like. The current very draft text template can be found here: https://github.com/jounikor/dmm-re-charter As you can see, we are still in early stages and all input it welcome. Obviously, possible re-chartering depends on many things. For example, things like getting the gap analysis out of the WG and what the IESG says. Nothing has been fixed or decided yet. Anyhow, we will start the discussion on re-chartering with the expectation that the DMM WG will re-charter and continue developing new solutions and/or enhancements in the IP mobility space. - Jouni & Dapeng _______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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_8da19a47f4d04410bd960b54e482333aPEXCVZYH01corporateadro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I realize = that I gave a very bad example of centralized control functions… In o= ur context, we should rather talk about centralized mobility control function (with distributed DP function)… anyway, my proposal for tex= t revision is still valid.

 = ;

De : dmm = [mailto:dmm-bounces@ietf.org] De la part de pierrick.seite@orange.com
Envoy=E9 : mardi 18 mars 2014 12:04
=C0 : Alper Yegin; Charlie P.; Weixinpeng
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions <was, Re= : DMM WG next steps>

 

Hello,

 

Distributing mobility anchors closer either= to the MN or CN are both valid scenarios. But, maybe there are other optim= al anchor location; actually, here, we are seeking to reach optimal routing by placing the anchor closer to the optimal data = path. Also, we may also want to keep a centralized anchor, for example, rea= chability purpose; in this case, we could say that data path going via the = central anchor is the “most” optimal, because of the reachability constraint. In CP/DP distributions scenarios, = we may want to distribute DP function and keep centralized some CP function= s (e.g. billing… yes, operators like this function J).

 

So, I think that anchoring location conside= rations should be more generic and should focus on datapath management. I&#= 8217;d suggest the following rewording:

 

------- OLD TEXT ------------

 

by distributing mobility functions more clo= ser to the user and/or its corresponding nodes.

 

 

---------- NEW TEXT ---------

 

by distributing forwarding functions more c= loser to the optimal data path; for example, closer either to the mobile us= er or the corresponding node.

 

Pirrick

 = ;

 = ;

De : dmm = [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin
Envoy=E9 : mardi 18 mars 2014 10:19
=C0 : Charlie P.; Weixinpeng
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions <was, Re= : DMM WG next steps>

 

Hello Xinpeng,

 

In the legacy thinking, the mobility anchor is in th= e core network (centrally-located HA). That's the basic Mobile IP design.

Now people are also considering placing anchors in t= he access network.

And then there's one more possibility, which is to p= lace an anchor near/on the corresponding node. 

 

Please see the Cnet-homing presentation for more:&nb= sp;http://www.ietf.org/proceedings/87/slides/slides-87-dmm-2.pdf

 

Questions/comments welcome.

 

Charlie: 

 

Yes, we cannot assume there'll be an anchor on/near = every CN. Our proposal takes that into account.

 

In fact, today there's no anchor in every access net= work either. There's basically none in any WiFi network today.

 

Both situation is subject to change based on DMM dev= elopments.

 

Alper

 

 

 

 

 

 

 

 

On Mar 18, 2014, at 9:08 AM, Charlie P. wrote:<= /o:p>

 

Hello folks,

One difference is that a mobile node is likely to be located in a network t= hat supports mobility, whereas the network hosting a general CN may not hav= e any mobility support features.

Regards,
Charlie P.

-----Original Message----- 
From: Weixinpeng 
Sent: Mar 17, 2014 11:59 PM 
To: Alper Yegin , Jouni K= orhonen 
Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" 
Subject: Re: [DMM] DMM WG next steps&= nbsp;

Hi Alper,

Is there any essential difference between placing the mobi= lity function closer to the user  and placing

the mobility function closer to the CN?   I thin= k in some sense the user host and it’s corresponding node are the same for mobility management protocol.<= /o:p>

So what’s the reason to distinguish between them?

 

BR,

xinpeng

From: dmm [mailto:dmm-bounces@ietf.org] <= /span>On Behalf Of Alper Yegin
Sent: Wednesday, M= arch 05, 2014 9:04 PM
To: Jouni Korhonen=
Cc: dmm@ietf.org;&n= bsp;dmm-chairs@tools.ie= tf.org
Subject: Re: [DMM]= DMM WG next steps

 

Jouni,

 

Thanks for the text.

 

   =
;   DMM can be used to realise such a distributed deployment
   =
;   model, by distributing mobility functions more closer to=
 the user.

 

 

This part excludes the approaches that place the mobility= function on or near the CN.<= /span>

 

I recommend the following revision:

 

 

   =
;   DMM can be used to realise such a distributed deployment
   =
;   model, by distributing mobility functions more closer to=
 the user
   =
;   and/or its corresponding nodes.

 

Alper

 

 

 

 

 

 

On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote:=



Folks,

DMM WG has done some progress lately. The requirements document has
already left the building and the gap analysis is heading to WGLC as
we speak. It is about the time to think what we should do next now
that we have grown out of the infancy. 

A smaller group of mobility enthusiasts have been discussing about
possible next steps and how the possible new charter would look like. 
The current very draft text template can be found here:
     https://github.com/jounikor/dmm-re-ch= arter

As you can see, we are still in early stages and all input it welcome.
Obviously, possible re-chartering depends on many things. For example,
things like getting the gap analysis out of the WG and what the IESG
says. Nothing has been fixed or decided yet. Anyhow, we will start the
discussion on re-chartering with the expectation that the DMM WG will
re-charter and continue developing new solutions and/or enhancements
in the IP mobility space.

- Jouni & Dapeng

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

 

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

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_8da19a47f4d04410bd960b54e482333aPEXCVZYH01corporateadro_-- From nobody Tue Mar 18 07:00:49 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BCB1A040A for ; Tue, 18 Mar 2014 07:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fW-Va2dIeeh3 for ; Tue, 18 Mar 2014 07:00:40 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0411A02E8 for ; Tue, 18 Mar 2014 07:00:39 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id l18so5866871wgh.31 for ; Tue, 18 Mar 2014 07:00:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=rvshHN9H9M83Iho4TErUUn4c5nTTcVF+uEqmJY0a8Ko=; b=HMO2ENIboI31xCh4lXLtT9Zec7W+rPlsJ6Jk6iZ5Rat/AC2+Wu1IJB6pK/Cg667npg 6Ixtop2VVatR1IzzBep8WP37X5/hNn8pOuTDvmIAYnrq7W466ki0OC1lnbb3kJKoiuOL I3Eqv4td0aj2pfGt9yYVK3TRfXtgrpBDlikBaz8QkoeBtIyOLJy5PmNT4uBP/aINZtcR tfXwzPh7doA2Jlc+5TFd2J0E7wKI5WoKNZFZCBwZV+YFLip62RKn6ViMJbnl4W1DuOVJ 1B8GIlZ7xk5OhllmP2GDo4+d3Yn4xAt7ASRRzqSrpP1P2pG8bffQPTxBAEA0N07tr3Ih M9jw== X-Gm-Message-State: ALoCoQlnnF42rw4/Y9dUC6G89Xz7rrANkgU6QL+B1sLTQzd5WF17swhzOZgbMpW2pYa3QvfXrwet X-Received: by 10.180.98.165 with SMTP id ej5mr14136189wib.33.1395151230817; Tue, 18 Mar 2014 07:00:30 -0700 (PDT) Received: from [11.0.0.215] (sitivoip.ulusofona.pt. [193.137.75.156]) by mx.google.com with ESMTPSA id fs8sm34277436wib.8.2014.03.18.07.00.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Mar 2014 07:00:29 -0700 (PDT) Message-ID: <5328517B.9070602@ulusofona.pt> Date: Tue, 18 Mar 2014 14:00:27 +0000 From: Rute Sofia Organization: COPELABS, ULHT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: pierrick.seite@orange.com References: <4657461.1395126539884.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> <7998EFA2-0203-4961-B290-F44E5814E3C6@yegin.org> <15533_1395140647_53282826_15533_3650_1_81C77F07008CA24F9783A98CFD706F711420EC3F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <6979_1395146603_53283F6B_6979_768_1_8da19a47-f4d0-4410-bd96-0b54e482333a@PEXCVZYH01.corporate.adroot.infra.ftgroup> In-Reply-To: <6979_1395146603_53283F6B_6979_768_1_8da19a47-f4d0-4410-bd96-0b54e482333a@PEXCVZYH01.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------070600030303020802040104" Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/XjV2OGCTljgqGKnsTEQQnMLbjro Cc: "Charlie P." , "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] Where to place mobility functions X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: rute.sofia@ulusofona.pt List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 14:00:46 -0000 This is a multi-part message in MIME format. --------------070600030303020802040104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hello Pierrick, by stating that the MAPs are closer to the optimal data path, we are advocating that the signaling should be in-band. MAPs work on the control plane. Is there a reason for this? Also, I do not understand why we need to make a distinction between "user" and CN. The distinction is between MN and CN which are both functionality (control plane) that reside on user-equipment, usually in customer premises... I actually prefer "close to the user", as this i) does not prevent solutions from being centralized or de-centralized; ii) does not block solutions that are as of today on the access; iii) allows for new solutions, user-based, and where functionality may be split among multiple nodes on the network (access, customer premises, etc) to exist... BR Rute Sofia On 18-03-2014 12:43, pierrick.seite@orange.com wrote: > > I realize that I gave a very bad example of centralized control > functions... In our context, we should rather talk about centralized > mobility control function (with distributed DP function)... anyway, my > proposal for text revision is still valid. > > *De :*dmm [mailto:dmm-bounces@ietf.org] *De la part de* > pierrick.seite@orange.com > *Envoyé :* mardi 18 mars 2014 12:04 > *À :* Alper Yegin; Charlie P.; Weixinpeng > *Cc :* dmm@ietf.org; dmm-chairs@tools.ietf.org > *Objet :* Re: [DMM] Where to place mobility functions next steps> > > Hello, > > Distributing mobility anchors closer either to the MN or CN are both > valid scenarios. But, maybe there are other optimal anchor location; > actually, here, we are seeking to reach optimal routing by placing the > anchor closer to the optimal data path. Also, we may also want to keep > a centralized anchor, for example, reachability purpose; in this case, > we could say that data path going via the central anchor is the "most" > optimal, because of the reachability constraint. In CP/DP > distributions scenarios, we may want to distribute DP function and > keep centralized some CP functions (e.g. billing... yes, operators > like this function J). > > So, I think that anchoring location considerations should be more > generic and should focus on datapath management. I'd suggest the > following rewording: > > ------- OLD TEXT ------------ > > by distributing mobility functions more closer to the user and/or its > corresponding nodes. > > ---------- NEW TEXT --------- > > by distributing forwarding functions more closer to the optimal data > path; for example, closer either to the mobile user or the > corresponding node. > > Pirrick > > *De :*dmm [mailto:dmm-bounces@ietf.org] *De la part de* Alper Yegin > *Envoyé :* mardi 18 mars 2014 10:19 > *À :* Charlie P.; Weixinpeng > *Cc :* dmm@ietf.org; dmm-chairs@tools.ietf.org > *Objet :* Re: [DMM] Where to place mobility functions next steps> > > Hello Xinpeng, > > In the legacy thinking, the mobility anchor is in the core network > (centrally-located HA). That's the basic Mobile IP design. > > Now people are also considering placing anchors in the access network. > > And then there's one more possibility, which is to place an anchor > near/on the corresponding node. > > Please see the Cnet-homing presentation for more: > http://www.ietf.org/proceedings/87/slides/slides-87-dmm-2.pdf > > Questions/comments welcome. > > Charlie: > > Yes, we cannot assume there'll be an anchor on/near every CN. Our > proposal takes that into account. > > In fact, today there's no anchor in every access network either. > There's basically none in any WiFi network today. > > Both situation is subject to change based on DMM developments. > > Alper > > On Mar 18, 2014, at 9:08 AM, Charlie P. wrote: > > Hello folks, > > One difference is that a mobile node is likely to be located in a > network that supports mobility, whereas the network hosting a general > CN may not have any mobility support features. > > Regards, > Charlie P. > > -----Original Message----- > From: Weixinpeng > Sent: Mar 17, 2014 11:59 PM > To: Alper Yegin, Jouni Korhonen > Cc: "dmm@ietf.org ", "dmm-chairs@tools.ietf.org > " > Subject: Re: [DMM] DMM WG next steps > > Hi Alper, > > Is there any essential difference between placing the mobility > function closer to the user and placing > > the mobility function closer to the CN? I think in some sense the > user host and it's corresponding node are the same for mobility > management protocol. > > So what's the reason to distinguish between them? > > BR, > > xinpeng > > *From:*dmm [mailto:dmm-bounces@ietf.org]*On Behalf Of*Alper Yegin > *Sent:*Wednesday, March 05, 2014 9:04 PM > *To:*Jouni Korhonen > *Cc:*dmm@ietf.org ;dmm-chairs@tools.ietf.org > > *Subject:*Re: [DMM] DMM WG next steps > > Jouni, > > Thanks for the text. > > DMM can be used to realise such a distributed deployment > model, by distributing mobility functions more closer to the user. > > This part excludes the approaches that place the mobility function on > or near the CN. > > I recommend the following revision: > > DMM can be used to realise such a distributed deployment > model, by distributing mobility functions more closer to the user > and/or its corresponding nodes. > > Alper > > On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote: > > > > Folks, > > DMM WG has done some progress lately. The requirements document has > already left the building and the gap analysis is heading to WGLC as > we speak. It is about the time to think what we should do next now > that we have grown out of the infancy. > > A smaller group of mobility enthusiasts have been discussing about > possible next steps and how the possible new charter would look like. > The current very draft text template can be found here: > https://github.com/jounikor/dmm-re-charter > > As you can see, we are still in early stages and all input it welcome. > Obviously, possible re-chartering depends on many things. For example, > things like getting the gap analysis out of the WG and what the IESG > says. Nothing has been fixed or decided yet. Anyhow, we will start the > discussion on re-chartering with the expectation that the DMM WG will > re-charter and continue developing new solutions and/or enhancements > in the IP mobility space. > > - Jouni & Dapeng > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm -- Best Regards/Melhores Cumprimentos/mit freundlichen Gruessen, Rute Sofia .............................................. COPELABS - Association for the Research and Development of Cognition and People-centric Computing Direction http://copelabs.ulusofona.pt ......................................... --------------070600030303020802040104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello Pierrick,

by stating that the MAPs are closer to the optimal data path, we are advocating that the signaling should be in-band. MAPs work on the control plane. Is there a reason for this?

Also, I do not understand why we need to make a distinction between "user" and CN. The distinction is between MN and CN which are both functionality (control plane) that reside on user-equipment, usually in customer premises...

I actually prefer "close to the user", as this i) does not prevent solutions from being centralized or de-centralized; ii) does not block solutions that are as of today on the access; iii) allows for new solutions, user-based, and where functionality may be split among multiple nodes on the network (access, customer premises, etc) to exist...

BR
Rute Sofia

On 18-03-2014 12:43, pierrick.seite@orange.com wrote:

I realize that I gave a very bad example of centralized control functions… In our context, we should rather talk about centralized mobility control function (with distributed DP function)… anyway, my proposal for text revision is still valid.

 

De : dmm [mailto:dmm-bounces@ietf.org] De la part de pierrick.seite@orange.com
Envoyé : mardi 18 mars 2014 12:04
À : Alper Yegin; Charlie P.; Weixinpeng
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions <was, Re: DMM WG next steps>

 

Hello,

 

Distributing mobility anchors closer either to the MN or CN are both valid scenarios. But, maybe there are other optimal anchor location; actually, here, we are seeking to reach optimal routing by placing the anchor closer to the optimal data path. Also, we may also want to keep a centralized anchor, for example, reachability purpose; in this case, we could say that data path going via the central anchor is the “most” optimal, because of the reachability constraint. In CP/DP distributions scenarios, we may want to distribute DP function and keep centralized some CP functions (e.g. billing… yes, operators like this function J).

 

So, I think that anchoring location considerations should be more generic and should focus on datapath management. I’d suggest the following rewording:

 

------- OLD TEXT ------------

 

by distributing mobility functions more closer to the user and/or its corresponding nodes.

 

 

---------- NEW TEXT ---------

 

by distributing forwarding functions more closer to the optimal data path; for example, closer either to the mobile user or the corresponding node.

 

Pirrick

 

 

De : dmm [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin
Envoyé : mardi 18 mars 2014 10:19
À : Charlie P.; Weixinpeng
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions <was, Re: DMM WG next steps>

 

Hello Xinpeng,

 

In the legacy thinking, the mobility anchor is in the core network (centrally-located HA). That's the basic Mobile IP design.

Now people are also considering placing anchors in the access network.

And then there's one more possibility, which is to place an anchor near/on the corresponding node. 

 

Please see the Cnet-homing presentation for more: http://www.ietf.org/proceedings/87/slides/slides-87-dmm-2.pdf

 

Questions/comments welcome.

 

Charlie: 

 

Yes, we cannot assume there'll be an anchor on/near every CN. Our proposal takes that into account.

 

In fact, today there's no anchor in every access network either. There's basically none in any WiFi network today.

 

Both situation is subject to change based on DMM developments.

 

Alper

 

 

 

 

 

 

 

 

On Mar 18, 2014, at 9:08 AM, Charlie P. wrote:

 

Hello folks,

One difference is that a mobile node is likely to be located in a network that supports mobility, whereas the network hosting a general CN may not have any mobility support features.

Regards,
Charlie P.

-----Original Message----- 
From: Weixinpeng 
Sent: Mar 17, 2014 11:59 PM 
To: Alper Yegin , Jouni Korhonen 
Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" 
Subject: Re: [DMM] DMM WG next steps 

Hi Alper,

Is there any essential difference between placing the mobility function closer to the user  and placing

the mobility function closer to the CN?   I think in some sense the user host and it’s corresponding node are the same for mobility management protocol.

So what’s the reason to distinguish between them?

 

BR,

xinpeng

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin
Sent: Wednesday, March 05, 2014 9:04 PM
To: Jouni Korhonen
Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org
Subject: Re: [DMM] DMM WG next steps

 

Jouni,

 

Thanks for the text.

 

      DMM can be used to realise such a distributed deployment
      model, by distributing mobility functions more closer to the user.

 

 

This part excludes the approaches that place the mobility function on or near the CN.

 

I recommend the following revision:

 

 

      DMM can be used to realise such a distributed deployment
      model, by distributing mobility functions more closer to the user
      and/or its corresponding nodes.

 

Alper

 

 

 

 

 

 

On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote:



Folks,

DMM WG has done some progress lately. The requirements document has
already left the building and the gap analysis is heading to WGLC as
we speak. It is about the time to think what we should do next now
that we have grown out of the infancy. 

A smaller group of mobility enthusiasts have been discussing about
possible next steps and how the possible new charter would look like. 
The current very draft text template can be found here:
     https://github.com/jounikor/dmm-re-charter

As you can see, we are still in early stages and all input it welcome.
Obviously, possible re-chartering depends on many things. For example,
things like getting the gap analysis out of the WG and what the IESG
says. Nothing has been fixed or decided yet. Anyhow, we will start the
discussion on re-chartering with the expectation that the DMM WG will
re-charter and continue developing new solutions and/or enhancements
in the IP mobility space.

- Jouni & Dapeng

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

 

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________

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

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


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



-- 
Best Regards/Melhores Cumprimentos/mit freundlichen Gruessen,

Rute Sofia
..............................................
COPELABS - Association for the Research and Development of Cognition and People-centric Computing
Direction
http://copelabs.ulusofona.pt
.........................................
--------------070600030303020802040104-- From nobody Tue Mar 18 07:38:31 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F261A06D5 for ; Tue, 18 Mar 2014 07:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03vVp7s-YxaN for ; Tue, 18 Mar 2014 07:38:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 05FBB1A06D8 for ; Tue, 18 Mar 2014 07:38:20 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id A174D2AC3B1; Tue, 18 Mar 2014 15:38:11 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 52485384072; Tue, 18 Mar 2014 15:38:11 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 18 Mar 2014 15:38:10 +0100 From: To: "rute.sofia@ulusofona.pt" Thread-Topic: [DMM] Where to place mobility functions Thread-Index: AQHPQotVVMDTcyItw0eSPoFwjfFE35rmpb5AgAA6BvqAAAOTsA== Date: Tue, 18 Mar 2014 14:38:10 +0000 Message-ID: <2556_1395153491_53285A53_2556_10077_1_81C77F07008CA24F9783A98CFD706F711420EE86@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <4657461.1395126539884.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> <7998EFA2-0203-4961-B290-F44E5814E3C6@yegin.org> <15533_1395140647_53282826_15533_3650_1_81C77F07008CA24F9783A98CFD706F711420EC3F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <6979_1395146603_53283F6B_6979_768_1_8da19a47-f4d0-4410-bd96-0b54e482333a@PEXCVZYH01.corporate.adroot.infra.ftgroup> <5328517B.9070602@ulusofona.pt> In-Reply-To: <5328517B.9070602@ulusofona.pt> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F711420EE86PEXCVZYM12corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.18.134216 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/qhQ87baIQY6uRO0ZvaUSdMIgOoM Cc: "Charlie P." , "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] Where to place mobility functions X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 14:38:29 -0000 --_000_81C77F07008CA24F9783A98CFD706F711420EE86PEXCVZYM12corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Rute, De : Rute Sofia [mailto:rute.sofia@ulusofona.pt] Envoy=E9 : mardi 18 mars 2014 15:00 =C0 : SEITE Pierrick IMT/OLN Cc : Alper Yegin; Charlie P.; Weixinpeng; dmm@ietf.org; dmm-chairs@tools.ie= tf.org Objet : Re: [DMM] Where to place mobility functions Hello Pierrick, by stating that the MAPs are closer to the optimal data path, we are advoca= ting that the signaling should be in-band. >>it could be but CP/DP is also on the radar screen. Actually, the charte= r text is talking about "mobility functions", and not MAP; I think it is a = good way to remain generic and to avoid focusing on a single solution space. MAPs work on the control plane. Is there a reason for this? Also, I do not understand why we need to make a distinction between "user" = and CN. The distinction is between MN and CN which are both functionality (= control plane) that reside on user-equipment, usually in customer premises.= .. >> right, it is MN and CN. My understanding is that we want to stress that the anchor could be deploye= d closer to the communications endpoints (I prefer to talk about optimal pa= th). However, many DMM solutions, currently on the table, place the anchor= close to the MN; so to clearly remind that other deployment exist, MN/CN = distinction is introduced ... just my understanding.... I actually prefer "close to the user", as this i) does not prevent solution= s from being centralized or de-centralized; ii) does not block solutions th= at are as of today on the access; iii) allows for new solutions, user-based= , and where functionality may be split among multiple nodes on the network = (access, customer premises, etc) to exist... >> the user is implicitly assumed to be the MN, but the MN can establish a = communications with a server, close to which we could deploy anchoring capa= bilities. So I prefer to keep MN/CN wording. BR Rute Sofia On 18-03-2014 12:43, pierrick.seite@orange.com wrote: I realize that I gave a very bad example of centralized control functions..= . In our context, we should rather talk about centralized mobility control = function (with distributed DP function)... anyway, my proposal for text rev= ision is still valid. De : dmm [mailto:dmm-bounces@ietf.org] De la part de pierrick.seite@orange.= com Envoy=E9 : mardi 18 mars 2014 12:04 =C0 : Alper Yegin; Charlie P.; Weixinpeng Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org Objet : Re: [DMM] Where to place mobility functions Hello, Distributing mobility anchors closer either to the MN or CN are both valid = scenarios. But, maybe there are other optimal anchor location; actually, he= re, we are seeking to reach optimal routing by placing the anchor closer to= the optimal data path. Also, we may also want to keep a centralized anchor= , for example, reachability purpose; in this case, we could say that data p= ath going via the central anchor is the "most" optimal, because of the reac= hability constraint. In CP/DP distributions scenarios, we may want to distr= ibute DP function and keep centralized some CP functions (e.g. billing... y= es, operators like this function :)). So, I think that anchoring location considerations should be more generic a= nd should focus on datapath management. I'd suggest the following rewording: ------- OLD TEXT ------------ by distributing mobility functions more closer to the user and/or its corre= sponding nodes. ---------- NEW TEXT --------- by distributing forwarding functions more closer to the optimal data path; = for example, closer either to the mobile user or the corresponding node. Pirrick De : dmm [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin Envoy=E9 : mardi 18 mars 2014 10:19 =C0 : Charlie P.; Weixinpeng Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org Objet : Re: [DMM] Where to place mobility functions Hello Xinpeng, In the legacy thinking, the mobility anchor is in the core network (central= ly-located HA). That's the basic Mobile IP design. Now people are also considering placing anchors in the access network. And then there's one more possibility, which is to place an anchor near/on = the corresponding node. Please see the Cnet-homing presentation for more: http://www.ietf.org/proce= edings/87/slides/slides-87-dmm-2.pdf Questions/comments welcome. Charlie: Yes, we cannot assume there'll be an anchor on/near every CN. Our proposal = takes that into account. In fact, today there's no anchor in every access network either. There's ba= sically none in any WiFi network today. Both situation is subject to change based on DMM developments. Alper On Mar 18, 2014, at 9:08 AM, Charlie P. wrote: Hello folks, One difference is that a mobile node is likely to be located in a network t= hat supports mobility, whereas the network hosting a general CN may not hav= e any mobility support features. Regards, Charlie P. -----Original Message----- From: Weixinpeng Sent: Mar 17, 2014 11:59 PM To: Alper Yegin , Jouni Korhonen Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps Hi Alper, Is there any essential difference between placing the mobility function clo= ser to the user and placing the mobility function closer to the CN? I think in some sense the user ho= st and it's corresponding node are the same for mobility management protoco= l. So what's the reason to distinguish between them? BR, xinpeng From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin Sent: Wednesday, March 05, 2014 9:04 PM To: Jouni Korhonen Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org Subject: Re: [DMM] DMM WG next steps Jouni, Thanks for the text. DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user. This part excludes the approaches that place the mobility function on or ne= ar the CN. I recommend the following revision: DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user and/or its corresponding nodes. Alper On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote: Folks, DMM WG has done some progress lately. The requirements document has already left the building and the gap analysis is heading to WGLC as we speak. It is about the time to think what we should do next now that we have grown out of the infancy. A smaller group of mobility enthusiasts have been discussing about possible next steps and how the possible new charter would look like. The current very draft text template can be found here: https://github.com/jounikor/dmm-re-charter As you can see, we are still in early stages and all input it welcome. Obviously, possible re-chartering depends on many things. For example, things like getting the gap analysis out of the WG and what the IESG says. Nothing has been fixed or decided yet. Anyhow, we will start the discussion on re-chartering with the expectation that the DMM WG will re-charter and continue developing new solutions and/or enhancements in the IP mobility space. - Jouni & Dapeng _______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm -- Best Regards/Melhores Cumprimentos/mit freundlichen Gruessen, Rute Sofia .............................................. COPELABS - Association for the Research and Development of Cognition and Pe= ople-centric Computing Direction http://copelabs.ulusofona.pt ......................................... ___________________________________________________________________________= ______________________________________________ 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_81C77F07008CA24F9783A98CFD706F711420EE86PEXCVZYM12corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Rute,

 <= /p>

De := Rute Sofia [mailto:rute.sofia@ulusofona.pt]
Envoy=E9 : mardi 18 mars 2014 15:00
=C0 : SEITE Pierrick IMT/OLN
Cc : Alper Yegin; Charlie P.; Weixinpeng; dmm@ietf.org; dmm-cha= irs@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions <was, Re= : DMM WG next steps>

 


Hello Pierrick,

by stating that the MAPs are closer to the optimal data path, we are advoca= ting that the signaling should be in-band.

 <= /p>

>>it=  could be but CP/DP is also on the radar screen. Actually,  the = charter text is talking about “mobility functions”, and not MAP= ; I think it is a good way to remain generic and to avoid focusing on a single solution= space.

 = ;

MAPs work on the control plane.= Is there a reason for this?

Also, I do not understand why we need to make a distinction between = "user" and CN. The distinction is between MN and CN which are bot= h functionality (control plane) that reside on user-equipment, usually in c= ustomer premises...

>> r= ight, it is MN and CN.

My underst= anding is that we want to stress that the anchor could be deployed closer t= o the communications endpoints (I prefer to talk about optimal path). However, many DMM solutions, currently  on the table, place th= e anchor close to the MN; so to clearly remind that  other deployment = exist, MN/CN distinction is introduced … just my understanding…= .


I actually prefer "close to the user", as this i) does not preven= t solutions from being centralized or de-centralized; ii) does not block so= lutions that are as of today on the access; iii) allows for new solutions, = user-based, and where functionality may be split among multiple nodes on the network (access, customer premises, etc)= to exist...=

 = ;

>> t= he user is implicitly assumed to be the MN, but the MN can establish a comm= unications with a server, close to which we could deploy anchoring capabilities. So I prefer to keep MN/CN wording.



BR
Rute Sofia

On 18-03-2014 12:43, pierrick.seite@orange.com wrote:

I realize that I gave a = very bad example of centralized control functions… In our context, we= should rather talk about centralized mobility control function (with distributed DP function)… anyway, my proposal for text revisio= n is still valid.

 =

De : dmm = [mailto:dmm-bounces@ietf.org] De la part de pierrick.= seite@orange.com
Envoy=E9 : mardi 18 mars 2014 12:04
=C0 : Alper Yegin; Charlie P.; Weixinpeng
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions <was, Re= : DMM WG next steps>

 

Hello,

 

Distributing mobility anchors closer either= to the MN or CN are both valid scenarios. But, maybe there are other optim= al anchor location; actually, here, we are seeking to reach optimal routing by placing the anchor closer to the optimal data = path. Also, we may also want to keep a centralized anchor, for example, rea= chability purpose; in this case, we could say that data path going via the = central anchor is the “most” optimal, because of the reachability constraint. In CP/DP distributions scenarios, = we may want to distribute DP function and keep centralized some CP function= s (e.g. billing… yes, operators like this function J).

 

So, I think that anchoring location conside= rations should be more generic and should focus on datapath management. I&#= 8217;d suggest the following rewording:

 

------- OLD TEXT ------------

 

by distributing mobility functions more clo= ser to the user and/or its corresponding nodes.

 

 

---------- NEW TEXT ---------

 

by distributing forwarding functions more c= loser to the optimal data path; for example, closer either to the mobile us= er or the corresponding node.

 

Pirrick

 

 

De : dmm = [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin
Envoy=E9 : mardi 18 mars 2014 10:19
=C0 : Charlie P.; Weixinpeng
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions <was, Re= : DMM WG next steps>

 

Hello Xinpeng,

 

In the legacy thinking, the mobility anchor is in th= e core network (centrally-located HA). That's the basic Mobile IP design.

Now people are also considering placing anchors in t= he access network.

And then there's one more possibility, which is to p= lace an anchor near/on the corresponding node. 

 

Please see the Cnet-homing presentation for more:&nb= sp;http://www.ietf.org/proceedings/87/slides/slides-87-dmm-2.pdf

 

Questions/comments welcome.

 

Charlie: 

 

Yes, we cannot assume there'll be an anchor on/near = every CN. Our proposal takes that into account.

 

In fact, today there's no anchor in every access net= work either. There's basically none in any WiFi network today.

 

Both situation is subject to change based on DMM dev= elopments.

 

Alper

 

 

 

 

 

 

 

 

On Mar 18, 2014, at 9:08 AM, Charlie P. wrote:<= /o:p>

 

Hello folks,

One difference is that a mobile node is likely to be located in a network t= hat supports mobility, whereas the network hosting a general CN may not hav= e any mobility support features.

Regards,
Charlie P.

-----Original Message-----=  
From: Weixinpeng 
Sent: Mar 17, 2014 11:59 PM 
To: Alper Yegin , Jouni K= orhonen 
Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" 
Subject: Re: [DMM] DMM WG next steps&= nbsp;


Hi Alper,

Is there any essential difference= between placing the mobility function closer to the user  and placing=

the mobility function closer to t= he CN?   I think in some sense the user host and it’s corre= sponding node are the same for mobility management protocol.

So what’s the reason to dis= tinguish between them?

 

BR,

xinpeng

From: dmm [mailto:dmm-bounces@ietf.org]<= span class=3D"apple-converted-space"> On Behalf Of Alper Yegin
Sent: Wednesday, M= arch 05, 2014 9:04 PM
To: Jouni Korhonen=
Cc: dmm@ietf.org;&n= bsp;dmm-chairs@tools.ie= tf.org
Subject: Re: [DMM]= DMM WG next steps

 

Jouni,

 

Thanks for the text.

 

   =
;   DMM can be used to realise such a distributed deployment
   =
;   model, by distributing mobility functions more closer to=
 the user.

 

 

This part excludes the approaches that place the mobil= ity function on or near the CN.

 

I recommend the following revision:<= /p>

 

 

   =
;   DMM can be used to realise such a distributed deployment
   =
;   model, by distributing mobility functions more closer to=
 the user
   =
;   and/or its corresponding nodes.

 

Alper

 

 

 

 

 

 

On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote:




Folks,

DMM WG has done some progress lately. The requirements document has
already left the building and the gap analysis is heading to WGLC as
we speak. It is about the time to think what we should do next now
that we have grown out of the infancy. 

A smaller group of mobility enthusiasts have been discussing about
possible next steps and how the possible new charter would look like. 
The current very draft text template can be found here:
     https://github.com/jounikor/dmm-re-ch= arter

As you can see, we are still in early stages and all input it welcome.
Obviously, possible re-chartering depends on many things. For example,
things like getting the gap analysis out of the WG and what the IESG
says. Nothing has been fixed or decided yet. Anyhow, we will start the
discussion on re-chartering with the expectation that the DMM WG will
re-charter and continue developing new solutions and/or enhancements
in the IP mobility space.

- Jouni & Dapeng

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

 

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
 
 
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf=
.org/mailman/listinfo/dmm




-- 
Best Regards/Melhores Cumprimentos/mit freundlichen Gruessen,
 
Rute Sofia
..............................................
COPELABS - Association for the Research and Development of Cognition a=
nd People-centric Computing
Direction
http://copelabs.ulusofona.pt<=
/a>
.........................................
______________________________________________________________________=
___________________________________________________

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_81C77F07008CA24F9783A98CFD706F711420EE86PEXCVZYM12corpo_-- From nobody Tue Mar 18 08:04:00 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D821A02EE for ; Tue, 18 Mar 2014 08:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-sMQmINTYeV for ; Tue, 18 Mar 2014 08:03:53 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 51E621A017E for ; Tue, 18 Mar 2014 08:03:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s2IF3i23012630; Tue, 18 Mar 2014 10:03:44 -0500 Received: from XCH-PHX-109.sw.nos.boeing.com (xch-phx-109.sw.nos.boeing.com [130.247.25.36]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s2IF3Xl7012473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 18 Mar 2014 10:03:34 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.87]) by XCH-PHX-109.sw.nos.boeing.com ([169.254.9.36]) with mapi id 14.03.0174.001; Tue, 18 Mar 2014 08:03:32 -0700 From: "Templin, Fred L" To: "sarikaya@ieee.org" Thread-Topic: [DMM] DMM WG next steps Thread-Index: AQHPQkIjvo94f8eUfUyESxtA5yGOGZrm8YrA Date: Tue, 18 Mar 2014 15:03:31 +0000 Message-ID: <2134F8430051B64F815C691A62D983182022DA@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181EC042@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831820153C@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D983182022DAXCHBLV504nwnosboe_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/hDbfe71ASFMqhSp6KRK8yOd6CH4 Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 15:03:56 -0000 --_000_2134F8430051B64F815C691A62D983182022DAXCHBLV504nwnosboe_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Behcet, How do you mean to submit it as a solution draft to dmm? That is essentiall= y what I am already proposing. Thanks - Fred From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] Sent: Monday, March 17, 2014 5:37 PM To: Templin, Fred L Cc: Jouni Korhonen; dmm@ietf.org; dmm-chairs@tools.ietf.org Subject: Re: [DMM] DMM WG next steps Hi Fred, Why don't you submit it as a solution draft to dmm? Then you can push for your draft instead of arguing for something that we d= on't know what. Regards, Behcet On Mon, Mar 17, 2014 at 1:31 PM, Templin, Fred L > wrote: Hi Jouni, > -----Original Message----- > From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] > Sent: Saturday, March 15, 2014 9:04 PM > To: Templin, Fred L > Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org > Subject: Re: [DMM] DMM WG next steps > > Fred, > > On Mar 11, 2014, at 11:48 PM, "Templin, Fred L" > wrote: > > > Hi Jouni, > > > > I think AERO fits paragraph 3 of the proposed new charter. AERO is a > > mobility solution for IPv6, where each node gets at least a /64. It > > has in-built route optimization, and can run over either IPv6 or IPv4 > > networks as a "link layer" for mobility. AERO expects a distributed > > mobility management environment, where a network of servers and > > relays keeps track of mobile node locations without single point > > of failure concerns. > > > > AERO is somewhat like MIPv6, but differs in that it treats the > > underlying network as a link-layer for IPv6 using a non-broadcast > > multiple access (NBMA) interface model. AERO uses IPv6 ND messaging > > and the IPv6 neighbor cache on the AERO "link" instead of MIPv6 > > mechanisms, and uses DHCPv6 PD exchanges instead of RS/RA for mobile > > node coordinations. The mobile nodes can therefore act as mobile > > routers and can provide stable network access for their connected > > networks (where each mobile node and its connected networks is > > a "site"). > > > > Here is a pointer to the spec. Please have a look and let me know > > what you think, > > There has been zero prior discussion or activity on this > topic in DMM that I recall. Furthermore, the current draft > seems to be a bis of RFC6707, driven by a single individual > and quite far in the preparation so I do not see a reason > involving this into the WG work. AERO is about mobility in general and distributed mobility management in particular. It also provides a solution to the route optimization problem cited in RFC5522 (which came from MEXT). AERO should be of interest to anyone interested in network mobilitiy, route optimization and distributed mobility management. IMHO, it is a better way of doing things than prior methods and this group would do well to consider it. Thanks - Fred fred.l.templin@boeing.com > - JOuni > > > > > > https://datatracker.ietf.org/doc/draft-templin-aerolink/ > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: dmm [mailto:dmm-bounces@ietf.org] O= n Behalf Of Jouni Korhonen > >> Sent: Wednesday, March 05, 2014 2:10 AM > >> To: dmm@ietf.org > >> Cc: dmm-chairs@tools.ietf.org > >> Subject: [DMM] DMM WG next steps > >> > >> Folks, > >> > >> DMM WG has done some progress lately. The requirements document has > >> already left the building and the gap analysis is heading to WGLC as > >> we speak. It is about the time to think what we should do next now > >> that we have grown out of the infancy. > >> > >> A smaller group of mobility enthusiasts have been discussing about > >> possible next steps and how the possible new charter would look like. > >> The current very draft text template can be found here: > >> https://github.com/jounikor/dmm-re-charter > >> > >> As you can see, we are still in early stages and all input it welcome. > >> Obviously, possible re-chartering depends on many things. For example, > >> things like getting the gap analysis out of the WG and what the IESG > >> says. Nothing has been fixed or decided yet. Anyhow, we will start the > >> discussion on re-chartering with the expectation that the DMM WG will > >> re-charter and continue developing new solutions and/or enhancements > >> in the IP mobility space. > >> > >> - 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 --_000_2134F8430051B64F815C691A62D983182022DAXCHBLV504nwnosboe_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Behcet,

 <= /p>

How do you mean to submit= it as a solution draft to dmm? That is essentially

what I am already proposi= ng.

 <= /p>

Thanks - Fred<= /span>

 <= /p>

From: Behcet S= arikaya [mailto:sarikaya2012@gmail.com]
Sent: Monday, March 17, 2014 5:37 PM
To: Templin, Fred L
Cc: Jouni Korhonen; dmm@ietf.org; dmm-chairs@tools.ietf.org
Subject: Re: [DMM] DMM WG next steps

 

Hi Fred,

Why don't you submit = it as a solution draft to dmm?

Then you can push for= your draft instead of arguing for something that we don't know what.<= /o:p>

Regards,

Behcet

 

On Mon, Mar 17, 2014 at 1:31 PM, Templin, Fred L <= ;Fred.L.Temp= lin@boeing.com> wrote:

Hi Jouni,


> -----Original Message-----
> From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]
> Sent: Saturday, March 15, 2014 9:04 PM
> To: Templin, Fred L
> Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org
> Subject: Re: [DMM] DMM WG next steps
>
> Fred,
>
> On Mar 11, 2014, at 11:48 PM, "Templin, Fred L" <Fred.L.Templin@boeing.com> wro= te:
>
> > Hi Jouni,
> >
> > I think AERO fits paragraph 3 of the proposed new charter. AERO i= s a
> > mobility solution for IPv6, where each node gets at least a /64. = It
> > has in-built route optimization, and can run over either IPv6 or = IPv4
> > networks as a "link layer" for mobility. AERO expects a= distributed
> > mobility management environment, where a network of servers and > > relays keeps track of mobile node locations without single point<= br> > > of failure concerns.
> >
> > AERO is somewhat like MIPv6, but differs in that it treats the > > underlying network as a link-layer for IPv6 using a non-broadcast=
> > multiple access (NBMA) interface model. AERO uses IPv6 ND messagi= ng
> > and the IPv6 neighbor cache on the AERO "link" instead = of MIPv6
> > mechanisms, and uses DHCPv6 PD exchanges instead of RS/RA for mob= ile
> > node coordinations. The mobile nodes can therefore act as mobile<= br> > > routers and can provide stable network access for their connected=
> > networks (where each mobile node and its connected networks is > > a "site").
> >
> > Here is a pointer to the spec. Please have a look and let me know=
> > what you think,
>
> There has been zero prior discussion or activity on this
> topic in DMM that I recall. Furthermore, the current draft
> seems to be a bis of RFC6707, driven by a single individual
> and quite far in the preparation so I do not see a reason
> involving this into the WG work.

AERO is about mobility in general and distributed mo= bility management
in particular. It also provides a solution to the route optimization
problem cited in RFC5522 (which came from MEXT).

AERO should be of interest to anyone interested in network mobilitiy,
route optimization and distributed mobility management. IMHO, it is
a better way of doing things than prior methods and this group would
do well to consider it.

Thanks - Fred
fred.l.templin@boeing.com<= o:p>


> - JOuni
>
>
> >
> > https://datatracker.ietf.org/doc/draft-templin-aerolink/
> >
> > Thanks - Fred
> > fred.l.templin@boein= g.com
> >
> >> -----Original Message-----
> >> From: dmm [mailto:dmm= -bounces@ietf.org] On Behalf Of Jouni Korhonen
> >> Sent: Wednesday, March 05, 2014 2:10 AM
> >> To: dmm@ietf.org
> >> Cc: dmm-chairs@t= ools.ietf.org
> >> Subject: [DMM] DMM WG next steps
> >>
> >> Folks,
> >>
> >> DMM WG has done some progress lately. The requirements docume= nt has
> >> already left the building and the gap analysis is heading to = WGLC as
> >> we speak. It is about the time to think what we should do nex= t now
> >> that we have grown out of the infancy.
> >>
> >> A smaller group of mobility enthusiasts have been discussing = about
> >> possible next steps and how the possible new charter would lo= ok like.
> >> The current very draft text template can be found here:
> >>    https://github.com/jounikor/dmm-re-charter
> >>
> >> As you can see, we are still in early stages and all input it= welcome.
> >> Obviously, possible re-chartering depends on many things. For= example,
> >> things like getting the gap analysis out of the WG and what t= he IESG
> >> says. Nothing has been fixed or decided yet. Anyhow, we will = start the
> >> discussion on re-chartering with the expectation that the DMM= WG will
> >> re-charter and continue developing new solutions and/or enhan= cements
> >> in the IP mobility space.
> >>
> >> - Jouni & Dapeng
> >>
> >> _______________________________________________
> >> dmm mailing list
> >> dmm@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dmm

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

 

--_000_2134F8430051B64F815C691A62D983182022DAXCHBLV504nwnosboe_-- From nobody Tue Mar 18 19:13:48 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F24F1A0344 for ; Tue, 18 Mar 2014 19:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VeoH9s2reZj for ; Tue, 18 Mar 2014 19:13:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CA9AF1A0308 for ; Tue, 18 Mar 2014 19:13:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCF05881; Wed, 19 Mar 2014 02:13:28 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Mar 2014 02:13:16 +0000 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Mar 2014 02:13:27 +0000 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.24]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Wed, 19 Mar 2014 10:13:18 +0800 From: Weixinpeng To: "pierrick.seite@orange.com" , Alper Yegin , "Charlie P." Thread-Topic: [DMM] Where to place mobility functions Thread-Index: AQHPQpnSZ8BM0UGYekarrZLnkSmZL5rmQ/WAgAFfZXA= Date: Wed, 19 Mar 2014 02:13:17 +0000 Message-ID: References: <4657461.1395126539884.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> <7998EFA2-0203-4961-B290-F44E5814E3C6@yegin.org> <15533_1395140647_53282826_15533_3650_1_81C77F07008CA24F9783A98CFD706F711420EC3F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <6979_1395146603_53283F6B_6979_768_1_8da19a47-f4d0-4410-bd96-0b54e482333a@PEXCVZYH01.corporate.adroot.infra.ftgroup> In-Reply-To: <6979_1395146603_53283F6B_6979_768_1_8da19a47-f4d0-4410-bd96-0b54e482333a@PEXCVZYH01.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.176] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46D7FA0EBnkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/9x2oX45y0suvIjbuoRoflCslOL8 Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] Where to place mobility functions X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 02:13:44 -0000 --_000_C5C3BB522B1DDF478AA09545169155B46D7FA0EBnkgeml507mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pirrick, I agree with you that the anchoring location considerations should be more = generic. But for your suggested NEW TEXT, I think it's a bit of ambiguous to say "closer to the optimal data path", and as my understanding what DMM = is trying to do is to eliminate sub-optimal routing path between MN and CN, so if the anchor is just close to optimal data path, but not on the optimal= data path, it's not what DMM wants. So what's your opinion? Here is my suggested TEXT: by distributing forwarding functions at optimal location; for example, clos= er either to the mobile user or the corresponding node. BR, Xinpeng De : dmm [mailto:dmm-bounces@ietf.org] De la part de pierrick.seite@orange.= com Envoy=E9 : mardi 18 mars 2014 12:04 =C0 : Alper Yegin; Charlie P.; Weixinpeng Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org Objet : Re: [DMM] Where to place mobility functions Hello, Distributing mobility anchors closer either to the MN or CN are both valid = scenarios. But, maybe there are other optimal anchor location; actually, he= re, we are seeking to reach optimal routing by placing the anchor closer to= the optimal data path. Also, we may also want to keep a centralized anchor= , for example, reachability purpose; in this case, we could say that data p= ath going via the central anchor is the "most" optimal, because of the reac= hability constraint. In CP/DP distributions scenarios, we may want to distr= ibute DP function and keep centralized some CP functions (e.g. billing... y= es, operators like this function :)). So, I think that anchoring location considerations should be more generic a= nd should focus on datapath management. I'd suggest the following rewording= : ------- OLD TEXT ------------ by distributing mobility functions more closer to the user and/or its corre= sponding nodes. ---------- NEW TEXT --------- by distributing forwarding functions more closer to the optimal data path; = for example, closer either to the mobile user or the corresponding node. Pirrick De : dmm [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin Envoy=E9 : mardi 18 mars 2014 10:19 =C0 : Charlie P.; Weixinpeng Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org Objet : Re: [DMM] Where to place mobility functions Hello Xinpeng, In the legacy thinking, the mobility anchor is in the core network (central= ly-located HA). That's the basic Mobile IP design. Now people are also considering placing anchors in the access network. And then there's one more possibility, which is to place an anchor near/on = the corresponding node. Please see the Cnet-homing presentation for more: http://www.ietf.org/proce= edings/87/slides/slides-87-dmm-2.pdf Questions/comments welcome. Charlie: Yes, we cannot assume there'll be an anchor on/near every CN. Our proposal = takes that into account. In fact, today there's no anchor in every access network either. There's ba= sically none in any WiFi network today. Both situation is subject to change based on DMM developments. Alper On Mar 18, 2014, at 9:08 AM, Charlie P. wrote: Hello folks, One difference is that a mobile node is likely to be located in a network t= hat supports mobility, whereas the network hosting a general CN may not hav= e any mobility support features. Regards, Charlie P. -----Original Message----- From: Weixinpeng Sent: Mar 17, 2014 11:59 PM To: Alper Yegin , Jouni Korhonen Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps Hi Alper, Is there any essential difference between placing the mobility function clo= ser to the user and placing the mobility function closer to the CN? I think in some sense the user ho= st and it's corresponding node are the same for mobility management protoco= l. So what's the reason to distinguish between them? BR, xinpeng From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin Sent: Wednesday, March 05, 2014 9:04 PM To: Jouni Korhonen Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org Subject: Re: [DMM] DMM WG next steps Jouni, Thanks for the text. DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user. This part excludes the approaches that place the mobility function on or ne= ar the CN. I recommend the following revision: DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user and/or its corresponding nodes. Alper On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote: Folks, DMM WG has done some progress lately. The requirements document has already left the building and the gap analysis is heading to WGLC as we speak. It is about the time to think what we should do next now that we have grown out of the infancy. A smaller group of mobility enthusiasts have been discussing about possible next steps and how the possible new charter would look like. The current very draft text template can be found here: https://github.com/jounikor/dmm-re-charter As you can see, we are still in early stages and all input it welcome. Obviously, possible re-chartering depends on many things. For example, things like getting the gap analysis out of the WG and what the IESG says. Nothing has been fixed or decided yet. Anyhow, we will start the discussion on re-chartering with the expectation that the DMM WG will re-charter and continue developing new solutions and/or enhancements in the IP mobility space. - Jouni & Dapeng _______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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_C5C3BB522B1DDF478AA09545169155B46D7FA0EBnkgeml507mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi<= span lang=3D"EN-US"> Pirrick,=

I agree wi= th you that the anchoring location considerations should be more generic. B= ut for your suggested NEW TEXT, I think it’s a bit of ambiguous

to say = 220;closer to the optimal data path”, and as my understanding what DM= M is trying to do is to eliminate sub-optimal routing path between MN and CN,

so if the = anchor is just close to optimal data path, but not on the optimal data path= , it’s not what DMM wants. So what’s your opinion?

 = ;

Here is my= suggested TEXT:

by distrib= uting forwarding functions at optimal location; for example, closer either = to the mobile user or the corresponding node.

 = ;

BR,

Xinpeng

 = ;

 

De : dmm [mailto:dmm= -bounces@ietf.org] De la part de pierrick.= seite@orange.com
Envoy=E9 : mardi 18 mars 2014 12:04
=C0 : Alper Yegin; Charlie P.; Weixinpeng
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions <was, Re= : DMM WG next steps>

 

Hello,<= /span>

 <= /span>

Distributing mobility anchors closer either= to the MN or CN are both valid scenarios. But, maybe there are other optim= al anchor location; actually, here, we are seeking to reach optimal routing by placing the anchor closer to the optimal data = path. Also, we may also want to keep a centralized anchor, for example, rea= chability purpose; in this case, we could say that data path going via the = central anchor is the “most” optimal, because of the reachability constraint. In CP/DP distributions scenarios, = we may want to distribute DP function and keep centralized some CP function= s (e.g. billing… yes, operators like this function J).

 <= /span>

So, I think that anchoring location conside= rations should be more generic and should focus on datapath management. I&#= 8217;d suggest the following rewording:=

 <= /span>

------- OLD TEXT ------------

 <= /span>

by distributing mobility functions more clo= ser to the user and/or its corresponding nodes.

 <= /span>

 <= /span>

---------- NEW TEXT ---------

 <= /span>

by distributing forwarding functions more c= loser to the optimal data path; for example, closer either to the mobile us= er or the corresponding node.

 <= /span>

Pirrick=

 

 

De : dmm [mailto:dmm= -bounces@ietf.org] De la part de Alper Yegin
Envoy=E9 : mardi 18 mars 2014 10:19
=C0 : Charlie P.; Weixinpeng
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions <was, Re= : DMM WG next steps>

 

Hello Xinpeng,

 

In the legacy thinking, the mobili= ty anchor is in the core network (centrally-located HA). That's the basic M= obile IP design.

Now people are also considering pl= acing anchors in the access network.

And then there's one more possibil= ity, which is to place an anchor near/on the corresponding node. =

 

Please see the Cnet-homing present= ation for more: http://www.ietf.org/proceedings/87/slides/slides-87-dmm= -2.pdf

 

Questions/comments welcome.

 

Charlie: 

 

Yes, we cannot assume there'll be = an anchor on/near every CN. Our proposal takes that into account.

 

In fact, today there's no anchor i= n every access network either. There's basically none in any WiFi network t= oday.

 

Both situation is subject to chang= e based on DMM developments.

 

Alper

 

 

 

 

 

 

 

 

On Mar 18, 2014, at 9:08 AM, Charl= ie P. wrote:

&nb= sp;

Hello folks,

One difference is that a mobile node is likely to be located in a network t= hat supports mobility, whereas the network hosting a general CN may not hav= e any mobility support features.

Regards,
Charlie P.

-----Original Message----- 
From: Weixinpeng 
Sent: Mar 17, 2014 11:59 PM 
To: Alper Yegin , Jouni K= orhonen 
Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" 
Subject: Re: [DMM] DMM WG next steps&= nbsp;


Hi Alper,

Is there any essential difference between placing the mobi= lity function closer to the user  and placing=

the mobility function closer to the CN?   I thin= k in some sense the user host and it’s corresponding node are the sam= e for mobility management protocol.

So what’s the reason to distinguish between them?

 

BR,

xinpeng

From: dmm [mailto:dmm-bounces@ietf.org]<= span class=3D"apple-converted-space"> On Behalf Of Alper Yegin
Sent: Wednesday, M= arch 05, 2014 9:04 PM
To: Jouni Korhonen=
Cc: dmm@ietf.org;&n= bsp;dmm-chairs@tools.ie= tf.org
Subject: Re: [DMM]= DMM WG next steps

 

Jouni,

 

Thanks for the text.<= /span>

 

   =
;   DMM can be used to realise such a distributed deployment
   =
;   model, by distributing mobility functions more closer to=
 the user.

 

 

This part excludes the approaches that place the mobility= function on or near the CN.

 

I recommend the following revision:

 

 

   =
;   DMM can be used to realise such a distributed deployment
   =
;   model, by distributing mobility functions more closer to=
 the user
   =
;   and/or its corresponding nodes.=

 

Alper

 

 

 

 

 

 

On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote:=




Folks,

DMM WG has done some progress lately. The requirements document has
already left the building and the gap analysis is heading to WGLC as
we speak. It is about the time to think what we should do next now
that we have grown out of the infancy. 

A smaller group of mobility enthusiasts have been discussing about
possible next steps and how the possible new charter would look like. 
The current very draft text template can be found here:
     https://github.com/jounikor/dmm-re-ch= arter

As you can see, we are still in early stages and all input it welcome.
Obviously, possible re-chartering depends on many things. For example,
things like getting the gap analysis out of the WG and what the IESG
says. Nothing has been fixed or decided yet. Anyhow, we will start the
discussion on re-chartering with the expectation that the DMM WG will
re-charter and continue developing new solutions and/or enhancements
in the IP mobility space.

- Jouni & Dapeng

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

 

 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_C5C3BB522B1DDF478AA09545169155B46D7FA0EBnkgeml507mbxchi_-- From nobody Wed Mar 19 01:31:39 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A675A1A065C for ; Wed, 19 Mar 2014 01:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0018hvf2gY0z for ; Wed, 19 Mar 2014 01:31:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B28661A0344 for ; Wed, 19 Mar 2014 01:31:28 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 3952222C7BF; Wed, 19 Mar 2014 09:31:19 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 16F5D238074; Wed, 19 Mar 2014 09:31:19 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 19 Mar 2014 09:31:18 +0100 From: To: Weixinpeng , Alper Yegin , Charlie P. Thread-Topic: [DMM] Where to place mobility functions Thread-Index: AQHPQotVVMDTcyItw0eSPoFwjfFE35rmQ/WAgAFfZXCAAG9JcA== Date: Wed, 19 Mar 2014 08:31:18 +0000 Message-ID: <11579_1395217879_532955D7_11579_7368_1_81C77F07008CA24F9783A98CFD706F711420F5EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <4657461.1395126539884.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> <7998EFA2-0203-4961-B290-F44E5814E3C6@yegin.org> <15533_1395140647_53282826_15533_3650_1_81C77F07008CA24F9783A98CFD706F711420EC3F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <6979_1395146603_53283F6B_6979_768_1_8da19a47-f4d0-4410-bd96-0b54e482333a@PEXCVZYH01.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.197.38.6] Content-Type: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F711420F5ECPEXCVZYM12corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.18.134216 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/sqlK9QsVBK33e16iDuPv5gHCUU8 Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] Where to place mobility functions X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 08:31:36 -0000 --_000_81C77F07008CA24F9783A98CFD706F711420F5ECPEXCVZYM12corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable De : Weixinpeng [mailto:weixinpeng@huawei.com] Envoy=E9 : mercredi 19 mars 2014 03:13 =C0 : SEITE Pierrick IMT/OLN; Alper Yegin; Charlie P. Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org; Xiongchunshan (Sam) Objet : RE: [DMM] Where to place mobility functions Hi Pirrick, I agree with you that the anchoring location considerations should be more = generic. But for your suggested NEW TEXT, I think it's a bit of ambiguous to say "closer to the optimal data path", and as my understanding what DMM = is trying to do is to eliminate sub-optimal routing path between MN and CN, so if the anchor is just close to optimal data path, but not on the optimal= data path, it's not what DMM wants. So what's your opinion? [PS] it depends on what does "optimal path" mean; actually the ambiguity ma= y come from that term. If "optimal path" does not mean the shortest path b= ut "the best we can do", I can agree with you. Here is my suggested TEXT: by distributing forwarding functions at optimal location; for example, clos= er either to the mobile user or the corresponding node. [PS] better :) BR, Xinpeng De : dmm [mailto:dmm-bounces@ietf.org] De la part de pierrick.seite@orange.= com Envoy=E9 : mardi 18 mars 2014 12:04 =C0 : Alper Yegin; Charlie P.; Weixinpeng Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org Objet : Re: [DMM] Where to place mobility functions Hello, Distributing mobility anchors closer either to the MN or CN are both valid = scenarios. But, maybe there are other optimal anchor location; actually, he= re, we are seeking to reach optimal routing by placing the anchor closer to= the optimal data path. Also, we may also want to keep a centralized anchor= , for example, reachability purpose; in this case, we could say that data p= ath going via the central anchor is the "most" optimal, because of the reac= hability constraint. In CP/DP distributions scenarios, we may want to distr= ibute DP function and keep centralized some CP functions (e.g. billing... y= es, operators like this function :)). So, I think that anchoring location considerations should be more generic a= nd should focus on datapath management. I'd suggest the following rewording: ------- OLD TEXT ------------ by distributing mobility functions more closer to the user and/or its corre= sponding nodes. ---------- NEW TEXT --------- by distributing forwarding functions more closer to the optimal data path; = for example, closer either to the mobile user or the corresponding node. Pirrick De : dmm [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin Envoy=E9 : mardi 18 mars 2014 10:19 =C0 : Charlie P.; Weixinpeng Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org Objet : Re: [DMM] Where to place mobility functions Hello Xinpeng, In the legacy thinking, the mobility anchor is in the core network (central= ly-located HA). That's the basic Mobile IP design. Now people are also considering placing anchors in the access network. And then there's one more possibility, which is to place an anchor near/on = the corresponding node. Please see the Cnet-homing presentation for more: http://www.ietf.org/proce= edings/87/slides/slides-87-dmm-2.pdf Questions/comments welcome. Charlie: Yes, we cannot assume there'll be an anchor on/near every CN. Our proposal = takes that into account. In fact, today there's no anchor in every access network either. There's ba= sically none in any WiFi network today. Both situation is subject to change based on DMM developments. Alper On Mar 18, 2014, at 9:08 AM, Charlie P. wrote: Hello folks, One difference is that a mobile node is likely to be located in a network t= hat supports mobility, whereas the network hosting a general CN may not hav= e any mobility support features. Regards, Charlie P. -----Original Message----- From: Weixinpeng Sent: Mar 17, 2014 11:59 PM To: Alper Yegin , Jouni Korhonen Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps Hi Alper, Is there any essential difference between placing the mobility function clo= ser to the user and placing the mobility function closer to the CN? I think in some sense the user ho= st and it's corresponding node are the same for mobility management protoco= l. So what's the reason to distinguish between them? BR, xinpeng From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin Sent: Wednesday, March 05, 2014 9:04 PM To: Jouni Korhonen Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org Subject: Re: [DMM] DMM WG next steps Jouni, Thanks for the text. DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user. This part excludes the approaches that place the mobility function on or ne= ar the CN. I recommend the following revision: DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user and/or its corresponding nodes. Alper On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote: Folks, DMM WG has done some progress lately. The requirements document has already left the building and the gap analysis is heading to WGLC as we speak. It is about the time to think what we should do next now that we have grown out of the infancy. A smaller group of mobility enthusiasts have been discussing about possible next steps and how the possible new charter would look like. The current very draft text template can be found here: https://github.com/jounikor/dmm-re-charter As you can see, we are still in early stages and all input it welcome. Obviously, possible re-chartering depends on many things. For example, things like getting the gap analysis out of the WG and what the IESG says. Nothing has been fixed or decided yet. Anyhow, we will start the discussion on re-chartering with the expectation that the DMM WG will re-charter and continue developing new solutions and/or enhancements in the IP mobility space. - Jouni & Dapeng _______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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_81C77F07008CA24F9783A98CFD706F711420F5ECPEXCVZYM12corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 <= /p>

 <= /p>

De : Weix= inpeng [mailto:weixinpeng@huawei.com]
Envoy=E9 : mercredi 19 mars 2014 03:13
=C0 : SEITE Pierrick IMT/OLN; Alper Yegin; Charlie P.
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org; Xiongchunshan (Sa= m)
Objet : RE: [DMM] Where to place mobility functions <was, Re= : DMM WG next steps>

 

Hi Pirrick,

I agree with you that the anchoring location consideration= s should be more generic. But for your suggested NEW TEXT, I think it’s a bit of ambiguous

to say “closer to the optimal data path”, and = as my understanding what DMM is trying to do is to eliminate sub-optimal routing path between MN and CN,

so if the anchor is just close to optimal data path, but n= ot on the optimal data path, it’s not what DMM wants. So what’s your opinion?

 

[PS] it depends on what does “optimal path” me= an; actually the ambiguity may come from that term.  If “optimal= path” does not mean the shortest path but “the best we can do”, I ca= n agree with you.

 

 

Here is my suggested TEXT:

by distributing forwarding functions at optimal location; = for example, closer either to the mobile user or the corresponding node.

 

[PS] better J

 

BR,

Xinpeng

 

 

De :<= /span> dmm [mailto:dmm-bounces@ietf.org] De la part de pierrick.= seite@orange.com
Envoy=E9 : mardi 18 mars 2014 12:04
=C0 : Alper Yegin; Charlie P.; Weixinpeng
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions <was, Re= : DMM WG next steps>

 

Hello,

 

Distributing mob= ility anchors closer either to the MN or CN are both valid scenarios. But, = maybe there are other optimal anchor location; actually, here, we are seeking to reach optimal routing by placing the anchor closer= to the optimal data path. Also, we may also want to keep a centralized anc= hor, for example, reachability purpose; in this case, we could say that dat= a path going via the central anchor is the “most” optimal, because of the reachability constraint.= In CP/DP distributions scenarios, we may want to distribute DP function an= d keep centralized some CP functions (e.g. billing… yes, operators li= ke this function J).=

 

So, I think that= anchoring location considerations should be more generic and should focus = on datapath management. I’d suggest the following rewording:

 

------- OLD TEXT= ------------<= /span>

 

by distributing = mobility functions more closer to the user and/or its corresponding no= des.

 

 

---------- NEW T= EXT ---------<= /span>

 

by distributing = forwarding functions more closer to the optimal data path; for example, clo= ser either to the mobile user or the corresponding node. =

 

Pirrick

 

 

De :<= /span> dmm [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin
Envoy=E9 : mardi 18 mars 2014 10:19
=C0 : Charlie P.; Weixinpeng
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions <was, Re= : DMM WG next steps>

 

Hello Xin= peng,

 

In the le= gacy thinking, the mobility anchor is in the core network (centrally-locate= d HA). That's the basic Mobile IP design.

Now peopl= e are also considering placing anchors in the access network.

And then = there's one more possibility, which is to place an anchor near/on the corre= sponding node. 

 

Please se= e the Cnet-homing presentation for more: http://www.ietf.org/proceeding= s/87/slides/slides-87-dmm-2.pdf

 

Questions= /comments welcome.

 

Charlie:&= nbsp;

 

Yes, we c= annot assume there'll be an anchor on/near every CN. Our proposal takes tha= t into account.

 

In fact, = today there's no anchor in every access network either. There's basically n= one in any WiFi network today.

 

Both situ= ation is subject to change based on DMM developments.

 

Alper

 

 

 

 

 

 

 

 

On Mar 18= , 2014, at 9:08 AM, Charlie P. wrote:

 

Hello folks,

One difference is that a mobile node is likely to be located in a network t= hat supports mobility, whereas the network hosting a general CN may not hav= e any mobility support features.

Regards,
Charlie P.

-----Original Message----- 
From: Weixinpeng 
Sent: Mar 17, 2014 11:59 PM 
To: Alper Yegin , Jouni K= orhonen 
Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" 
Subject: Re: [DMM] DMM WG next steps&= nbsp;

Hi Alper,

Is there any essential differen= ce between placing the mobility function closer to the user  and placing

the mobility function closer to= the CN?   I think in some sense the user host and it’s cor= responding node are the same for mobility management protocol.

So what’s the reason to d= istinguish between them?<= o:p>

 

BR,

xinpeng

From: dmm [mailto:dmm-bounces@ietf.org]<= span class=3D"apple-converted-space"> On Behalf Of Alper Yegin
Sent: Wednesday, M= arch 05, 2014 9:04 PM
To: Jouni Korhonen=
Cc: dmm@ietf.org;&n= bsp;dmm-chairs@tools.ie= tf.org
Subject: Re: [DMM]= DMM WG next steps

 

Jouni,

 

Thanks for the text.

 

      DMM can be used to realise such a =
distributed deployment
      model, by distributing mobili=
ty functions more closer to the user.

 

 

This part excludes the approac= hes that place the mobility function on or near the CN.

 

I recommend the following revi= sion:

 

 

      DMM can be used to realise such a =
distributed deployment
      model, by distributing mobili=
ty functions more closer to the user=

      and/or its corresponding nodes.

 

Alper

 

 

 

 

 

 

On Mar 5, 2014, at 12:09 PM, J= ouni Korhonen wrote:=



Folks,

DMM WG has done some progress lately. The requirements document has
already left the building and the gap analysis is heading to WGLC as
we speak. It is about the time to think what we should do next now
that we have grown out of the infancy. 

A smaller group of mobility enthusiasts have been discussing about
possible next steps and how the possible new charter would look like. 
The current very draft text template can be found here:
     https://github.com/jounikor/dmm-re-ch= arter

As you can see, we are still in early stages and all input it welcome.
Obviously, possible re-chartering depends on many things. For example,
things like getting the gap analysis out of the WG and what the IESG
says. Nothing has been fixed or decided yet. Anyhow, we will start the
discussion on re-chartering with the expectation that the DMM WG will
re-charter and continue developing new solutions and/or enhancements
in the IP mobility space.

- Jouni & Dapeng

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

 

 

_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
______________________________________________________________________=
___________________________________________________

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_81C77F07008CA24F9783A98CFD706F711420F5ECPEXCVZYM12corpo_-- From nobody Wed Mar 19 02:25:37 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE301A0695 for ; Wed, 19 Mar 2014 02:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9hTxnuZkTkx for ; Wed, 19 Mar 2014 02:25:32 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC361A0283 for ; Wed, 19 Mar 2014 02:25:31 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id uo5so8675860pbc.10 for ; Wed, 19 Mar 2014 02:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Bf4gk3WI+7vuwpk8wEMnoB+yRzFGwutLJ+tbf875jhM=; b=FtsKLfQoTdxIawtOK37KN4WyNjSXCMq7EHOxoJOXiZ4NhUe8YHv6ZkqEXR8qvvDC2R p7g8DTsCZfae+Sf4QIz06zo5iMa8FyK53SjjVvE0ukx6e0qj6fFIV73ynLbErOXnYt+P CkTsEkwZgpqfBbTm0XKQlwR6MMO+5cFuXsA5JsmoHPUYV6Ogl92Cq3exTsS/e9/hgLm/ 1NEXxRx01fSe06Va6whJ+7LgCxDql3KC129+rC9palNOe/vcoF0JzgbzXx4yyzxx3trk fTK08Fd2DRefYAkJibjecQzkMrPiIJcjVlLYQzHlEHfos7rvzBzbEUqKn77/105V7yd3 gdBw== X-Received: by 10.66.12.67 with SMTP id w3mr39976922pab.29.1395221123561; Wed, 19 Mar 2014 02:25:23 -0700 (PDT) Received: from dhcp-18-187.meeting.verilan.com ([123.124.234.161]) by mx.google.com with ESMTPSA id jd5sm60380383pbb.18.2014.03.19.02.25.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Mar 2014 02:25:21 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <11579_1395217879_532955D7_11579_7368_1_81C77F07008CA24F9783A98CFD706F711420F5EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Wed, 19 Mar 2014 17:25:14 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8F0B9DDE-6D73-4300-81CA-79FC83F5DB3E@gmail.com> References: <4657461.1395126539884.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> <7998EFA2-0203-4961-B290-F44E5814E3C6@yegin.org> <15533_1395140647_53282826_15533_3650_1_81C77F07008CA24F9783A98CFD706F711420EC3F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <6979_1395146603_53283F6B_6979_768_1_8da19a47-f4d0-4410-bd96-0b54e482333a@PEXCVZYH01.corporate.adroot.infra.ftgroup> <11579_1395217879_532955D7_11579_7368_1_81C77F07008CA24F9783A98CFD706F711420F5EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: pierrick.seite@orange.com X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/lgynyHXmqNvihXM8FG55oBtSen0 Cc: "Charlie P." , "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] Where to place mobility functions X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 09:25:37 -0000 On Mar 19, 2014, at 4:31 PM, pierrick.seite@orange.com wrote: > =20 > =20 > De : Weixinpeng [mailto:weixinpeng@huawei.com]=20 > Envoy=E9 : mercredi 19 mars 2014 03:13 > =C0 : SEITE Pierrick IMT/OLN; Alper Yegin; Charlie P. > Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org; Xiongchunshan (Sam) > Objet : RE: [DMM] Where to place mobility functions > =20 > Hi Pirrick, > I agree with you that the anchoring location considerations should be = more generic. But for your suggested NEW TEXT, I think it=92s a bit of = ambiguous > to say =93closer to the optimal data path=94, and as my understanding = what DMM is trying to do is to eliminate sub-optimal routing path = between MN and CN, > so if the anchor is just close to optimal data path, but not on the = optimal data path, it=92s not what DMM wants. So what=92s your opinion? > =20 > [PS] it depends on what does =93optimal path=94 mean; actually the = ambiguity may come from that term. If =93optimal path=94 does not mean = the shortest path but =93the best we can do=94, I can agree with you. > =20 > =20 > Here is my suggested TEXT: > by distributing forwarding functions at optimal location; for example, = closer either to the mobile user or the corresponding node. > =20 > [PS] better J Updated that to the draft charter text. - Jouni > =20 > BR, > Xinpeng > =20 > =20 > De : dmm [mailto:dmm-bounces@ietf.org] De la part de = pierrick.seite@orange.com > Envoy=E9 : mardi 18 mars 2014 12:04 > =C0 : Alper Yegin; Charlie P.; Weixinpeng > Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org > Objet : Re: [DMM] Where to place mobility functions > =20 > Hello, > =20 > Distributing mobility anchors closer either to the MN or CN are both = valid scenarios. But, maybe there are other optimal anchor location; = actually, here, we are seeking to reach optimal routing by placing the = anchor closer to the optimal data path. Also, we may also want to keep a = centralized anchor, for example, reachability purpose; in this case, we = could say that data path going via the central anchor is the =93most=94 = optimal, because of the reachability constraint. In CP/DP distributions = scenarios, we may want to distribute DP function and keep centralized = some CP functions (e.g. billing=85 yes, operators like this function J). > =20 > So, I think that anchoring location considerations should be more = generic and should focus on datapath management. I=92d suggest the = following rewording: > =20 > ------- OLD TEXT ------------ > =20 > by distributing mobility functions more closer to the user and/or its = corresponding nodes. > =20 > =20 > ---------- NEW TEXT --------- > =20 > by distributing forwarding functions more closer to the optimal data = path; for example, closer either to the mobile user or the corresponding = node. > =20 > Pirrick > =20 > =20 > De : dmm [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin > Envoy=E9 : mardi 18 mars 2014 10:19 > =C0 : Charlie P.; Weixinpeng > Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org > Objet : Re: [DMM] Where to place mobility functions > =20 > Hello Xinpeng, > =20 > In the legacy thinking, the mobility anchor is in the core network = (centrally-located HA). That's the basic Mobile IP design. > Now people are also considering placing anchors in the access network. > And then there's one more possibility, which is to place an anchor = near/on the corresponding node.=20 > =20 > Please see the Cnet-homing presentation for more: = http://www.ietf.org/proceedings/87/slides/slides-87-dmm-2.pdf > =20 > Questions/comments welcome. > =20 > Charlie:=20 > =20 > Yes, we cannot assume there'll be an anchor on/near every CN. Our = proposal takes that into account. > =20 > In fact, today there's no anchor in every access network either. = There's basically none in any WiFi network today. > =20 > Both situation is subject to change based on DMM developments. > =20 > Alper > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > On Mar 18, 2014, at 9:08 AM, Charlie P. wrote: > =20 >=20 > Hello folks, >=20 > One difference is that a mobile node is likely to be located in a = network that supports mobility, whereas the network hosting a general CN = may not have any mobility support features. >=20 > Regards, > Charlie P. >=20 > -----Original Message-----=20 > From: Weixinpeng=20 > Sent: Mar 17, 2014 11:59 PM=20 > To: Alper Yegin , Jouni Korhonen=20 > Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org"=20 > Subject: Re: [DMM] DMM WG next steps=20 >=20 >=20 > Hi Alper, > Is there any essential difference between placing the mobility = function closer to the user and placing > the mobility function closer to the CN? I think in some sense the = user host and it=92s corresponding node are the same for mobility = management protocol. > So what=92s the reason to distinguish between them? > =20 > BR, > xinpeng > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin > Sent: Wednesday, March 05, 2014 9:04 PM > To: Jouni Korhonen > Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org > Subject: Re: [DMM] DMM WG next steps > =20 > Jouni, > =20 > Thanks for the text. > =20 > DMM can be used to realise such a distributed deployment > model, by distributing mobility functions more closer to the = user. > =20 > =20 > This part excludes the approaches that place the mobility function on = or near the CN. > =20 > I recommend the following revision: > =20 > =20 > DMM can be used to realise such a distributed deployment > model, by distributing mobility functions more closer to the = user > and/or its corresponding nodes. > =20 > Alper > =20 > =20 > =20 > =20 > =20 > =20 > On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote: >=20 >=20 >=20 > Folks, >=20 > DMM WG has done some progress lately. The requirements document has > already left the building and the gap analysis is heading to WGLC as > we speak. It is about the time to think what we should do next now > that we have grown out of the infancy.=20 >=20 > A smaller group of mobility enthusiasts have been discussing about > possible next steps and how the possible new charter would look like.=20= > The current very draft text template can be found here: > https://github.com/jounikor/dmm-re-charter >=20 > As you can see, we are still in early stages and all input it welcome. > Obviously, possible re-chartering depends on many things. For example, > things like getting the gap analysis out of the WG and what the IESG > says. Nothing has been fixed or decided yet. Anyhow, we will start the > discussion on re-chartering with the expectation that the DMM WG will > re-charter and continue developing new solutions and/or enhancements > in the IP mobility space. >=20 > - Jouni & Dapeng >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > =20 > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. > =20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. > = __________________________________________________________________________= _______________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. > =20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Mar 19 04:09:39 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887191A03C4 for ; Wed, 19 Mar 2014 04:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXg2hfwLlM2N for ; Wed, 19 Mar 2014 04:09:28 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAB81A0739 for ; Wed, 19 Mar 2014 04:09:27 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi5so4860963wib.17 for ; Wed, 19 Mar 2014 04:09:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=YfBNvAHWry4ZhgIyT3gEcP3LEhIcXEaiLLYNNn0QRpo=; b=asfUrT5MnZXD91BljHl7uaMBGvTQWTr4BZOUnpr5kmxBROmbHrgIzM6CSiJyaA0cZt hTPYbyAoSpBXFtY94n/yrMa2jnWVw1ziVQmEyKlSrUBHk/XSFwhXRv+ncp/RzBnYYNgn lO+OXbszCQ0Om7JAx9VcHSfMeTSgr1Sz2NNhJaPcHT5N0xb5XIOTS2ME1RrvGT4XogZ7 eyLtFlxCvp1W+XDnNtvmmeoKrUosytr8+e0p1QmQ135lyOaBFLPn/rJ4/O/TahBVBnji rEaKKET0T9IWINVfNpOv8VgkRaqgOS6Z2FjsCzLqYsn6EMQAM7N2Rs4W4gBy+DWPPaFo EFJA== X-Gm-Message-State: ALoCoQk8ylsdow8MddeKPBn/ZKSdTfAZwYJ+bYumzVhnjfYqTlG5CwAw3eRnCqurEcp/A64mk9uu X-Received: by 10.180.12.43 with SMTP id v11mr18628881wib.33.1395227358386; Wed, 19 Mar 2014 04:09:18 -0700 (PDT) Received: from [11.0.0.215] (sitivoip.ulusofona.pt. [193.137.75.156]) by mx.google.com with ESMTPSA id fb6sm42605982wib.2.2014.03.19.04.09.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Mar 2014 04:09:17 -0700 (PDT) Message-ID: <53297ADD.9030905@ulusofona.pt> Date: Wed, 19 Mar 2014 11:09:17 +0000 From: Rute Sofia Organization: COPELABS, ULHT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: pierrick.seite@orange.com, Weixinpeng References: <4657461.1395126539884.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> <7998EFA2-0203-4961-B290-F44E5814E3C6@yegin.org> <15533_1395140647_53282826_15533_3650_1_81C77F07008CA24F9783A98CFD706F711420EC3F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <6979_1395146603_53283F6B_6979_768_1_8da19a47-f4d0-4410-bd96-0b54e482333a@PEXCVZYH01.corporate.adroot.infra.ftgroup> <11579_1395217879_532955D7_11579_7368_1_81C77F07008CA24F9783A98CFD706F711420F5EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <11579_1395217879_532955D7_11579_7368_1_81C77F07008CA24F9783A98CFD706F711420F5EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------000908050308040001030802" Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/f3oWf-Rkgqaq_dNYEk1c28oIlrE Cc: "Charlie P." , "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] Where to place mobility functions X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: rute.sofia@ulusofona.pt List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 11:09:35 -0000 This is a multi-part message in MIME format. --------------000908050308040001030802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Again, I think it is risky to mention optimal path or anything that has to do with data path as this implies in-band signaling... Concerning the CN, I believe it would be enough to state "closer to the user". The CN can be a MN or not. I would also like to alert that there are proposals for architectures where indeed the closeness of the MAPs have been explored in the context of "closer to the user". For instance, in the EU project ULOOP (uloop.eu), there is a coordination function (signaling) that takes care of providing the "best" choice for a MAP according with user preferences, roaming habits, as well as with potential network policies. In another project (User-centric Mobility Management, http://copelabs.ulusofona.pt/index.php/research/projects/past-projects/149-umm, for results, papers and software) we have indeed worked solutions which *split* the control functionality and MAPs, and analyzed the possibility and advantages of placing it closer *to the user*. A MN or CN. So, the best solution which seems to suit the proposal by Pierrick as well as solutions that already exist today is: closer to the user. Not necessarily on the optimal *data* path. BR Rute Sofia On 19-03-2014 08:31, pierrick.seite@orange.com wrote: > > *De :*Weixinpeng [mailto:weixinpeng@huawei.com] > *Envoyé :* mercredi 19 mars 2014 03:13 > *À :* SEITE Pierrick IMT/OLN; Alper Yegin; Charlie P. > *Cc :* dmm@ietf.org; dmm-chairs@tools.ietf.org; Xiongchunshan (Sam) > *Objet :* RE: [DMM] Where to place mobility functions next steps> > > HiPirrick, > > I agree with you that the anchoring location considerations should be > more generic. But for your suggested NEW TEXT, I think it's a bit of > ambiguous > > to say "closer to the optimal data path", and as my understanding what > DMM is trying to do is to eliminate sub-optimal routing path between > MN and CN, > > so if the anchor is just close to optimal data path, but not on the > optimal data path, it's not what DMM wants. So what's your opinion? > > [PS] it depends on what does "optimal path" mean; actually the > ambiguity may come from that term. If "optimal path" does not mean > the shortest path but "the best we can do", I can agree with you. > > Here is my suggested TEXT: > > by distributing forwarding functions at optimal location; for example, > closer either to the mobile user or the corresponding node. > > [PS] better J > > BR, > > Xinpeng > > *De :*dmm [mailto:dmm-bounces@ietf.org] *De la part de* > pierrick.seite@orange.com > *Envoyé :* mardi 18 mars 2014 12:04 > *À :* Alper Yegin; Charlie P.; Weixinpeng > *Cc :* dmm@ietf.org ; dmm-chairs@tools.ietf.org > > *Objet :* Re: [DMM] Where to place mobility functions next steps> > > Hello, > > Distributing mobility anchors closer either to the MN or CN are both > valid scenarios. But, maybe there are other optimal anchor location; > actually, here, we are seeking to reach optimal routing by placing the > anchor closer to the optimal data path. Also, we may also want to keep > a centralized anchor, for example, reachability purpose; in this case, > we could say that data path going via the central anchor is the "most" > optimal, because of the reachability constraint. In CP/DP > distributions scenarios, we may want to distribute DP function and > keep centralized some CP functions (e.g. billing... yes, operators > like this function J). > > So, I think that anchoring location considerations should be more > generic and should focus on datapath management. I'd suggest the > following rewording: > > ------- OLD TEXT ------------ > > by distributing mobility functions more closer to the user and/or its > corresponding nodes. > > ---------- NEW TEXT --------- > > by distributing forwarding functions more closer to the optimal data > path; for example, closer either to the mobile user or the > corresponding node. > > Pirrick > > *De :*dmm [mailto:dmm-bounces@ietf.org] *De la part de* Alper Yegin > *Envoyé :* mardi 18 mars 2014 10:19 > *À :* Charlie P.; Weixinpeng > *Cc :* dmm@ietf.org ; dmm-chairs@tools.ietf.org > > *Objet :* Re: [DMM] Where to place mobility functions next steps> > > Hello Xinpeng, > > In the legacy thinking, the mobility anchor is in the core network > (centrally-located HA). That's the basic Mobile IP design. > > Now people are also considering placing anchors in the access network. > > And then there's one more possibility, which is to place an anchor > near/on the corresponding node. > > Please see the Cnet-homing presentation for more: > http://www.ietf.org/proceedings/87/slides/slides-87-dmm-2.pdf > > Questions/comments welcome. > > Charlie: > > Yes, we cannot assume there'll be an anchor on/near every CN. Our > proposal takes that into account. > > In fact, today there's no anchor in every access network either. > There's basically none in any WiFi network today. > > Both situation is subject to change based on DMM developments. > > Alper > > On Mar 18, 2014, at 9:08 AM, Charlie P. wrote: > > Hello folks, > > One difference is that a mobile node is likely to be located in a > network that supports mobility, whereas the network hosting a general > CN may not have any mobility support features. > > Regards, > Charlie P. > > -----Original Message----- > From: Weixinpeng > Sent: Mar 17, 2014 11:59 PM > To: Alper Yegin, Jouni Korhonen > Cc: "dmm@ietf.org ", "dmm-chairs@tools.ietf.org > " > Subject: Re: [DMM] DMM WG next steps > > Hi Alper, > > Is there any essential difference between placing the mobility > function closer to the user and placing > > the mobility function closer to the CN? I think in some sense the > user host and it's corresponding node are the same for mobility > management protocol. > > So what's the reason to distinguish between them? > > BR, > > xinpeng > > *From:*dmm [mailto:dmm-bounces@ietf.org]*On Behalf Of*Alper Yegin > *Sent:*Wednesday, March 05, 2014 9:04 PM > *To:*Jouni Korhonen > *Cc:*dmm@ietf.org ;dmm-chairs@tools.ietf.org > > *Subject:*Re: [DMM] DMM WG next steps > > Jouni, > > Thanks for the text. > > DMM can be used to realise such a distributed deployment > model, by distributing mobility functions more closer to the user. > > This part excludes the approaches that place the mobility function on > or near the CN. > > I recommend the following revision: > > DMM can be used to realise such a distributed deployment > model, by distributing mobility functions more closer to the user > and/or its corresponding nodes. > > Alper > > On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote: > > > > Folks, > > DMM WG has done some progress lately. The requirements document has > already left the building and the gap analysis is heading to WGLC as > we speak. It is about the time to think what we should do next now > that we have grown out of the infancy. > > A smaller group of mobility enthusiasts have been discussing about > possible next steps and how the possible new charter would look like. > The current very draft text template can be found here: > https://github.com/jounikor/dmm-re-charter > > As you can see, we are still in early stages and all input it welcome. > Obviously, possible re-chartering depends on many things. For example, > things like getting the gap analysis out of the WG and what the IESG > says. Nothing has been fixed or decided yet. Anyhow, we will start the > discussion on re-chartering with the expectation that the DMM WG will > re-charter and continue developing new solutions and/or enhancements > in the IP mobility space. > > - Jouni & Dapeng > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm -- Best Regards/Melhores Cumprimentos/mit freundlichen Gruessen, Rute Sofia .............................................. COPELABS - Association for the Research and Development of Cognition and People-centric Computing Direction http://copelabs.ulusofona.pt ......................................... --------------000908050308040001030802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Again, I think it is risky to mention optimal path or anything that has to do with data path as this implies in-band signaling...

Concerning the CN, I believe it would be enough to state "closer to the user".

The CN can be a MN or not.

I would also like to alert that there are proposals for architectures where indeed the closeness of the MAPs have been explored in the context of "closer to the user". For instance, in the EU project ULOOP (uloop.eu), there is a coordination function (signaling) that takes care of providing the "best" choice for a MAP according with user preferences, roaming habits, as well as with potential network policies.

In another project (User-centric Mobility Management, http://copelabs.ulusofona.pt/index.php/research/projects/past-projects/149-umm, for results, papers and software) we have indeed worked solutions which *split* the control functionality and MAPs, and analyzed the possibility and advantages of placing it closer *to the user*. A MN or CN.

So, the best solution which seems to suit the proposal by Pierrick as well as solutions that already exist today is: closer to the user. Not necessarily on the optimal *data* path.

BR
Rute Sofia

On 19-03-2014 08:31, pierrick.seite@orange.com wrote:

 

 

De : Weixinpeng [mailto:weixinpeng@huawei.com]
Envoyé : mercredi 19 mars 2014 03:13
À : SEITE Pierrick IMT/OLN; Alper Yegin; Charlie P.
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org; Xiongchunshan (Sam)
Objet : RE: [DMM] Where to place mobility functions <was, Re: DMM WG next steps>

 

Hi Pirrick,

I agree with you that the anchoring location considerations should be more generic. But for your suggested NEW TEXT, I think it’s a bit of ambiguous

to say “closer to the optimal data path”, and as my understanding what DMM is trying to do is to eliminate sub-optimal routing path between MN and CN,

so if the anchor is just close to optimal data path, but not on the optimal data path, it’s not what DMM wants. So what’s your opinion?

 

[PS] it depends on what does “optimal path” mean; actually the ambiguity may come from that term.  If “optimal path” does not mean the shortest path but “the best we can do”, I can agree with you.

 

 

Here is my suggested TEXT:

by distributing forwarding functions at optimal location; for example, closer either to the mobile user or the corresponding node.

 

[PS] better J

 

BR,

Xinpeng

 

 

De : dmm [mailto:dmm-bounces@ietf.org] De la part de pierrick.seite@orange.com
Envoyé : mardi 18 mars 2014 12:04
À : Alper Yegin; Charlie P.; Weixinpeng
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions <was, Re: DMM WG next steps>

 

Hello,

 

Distributing mobility anchors closer either to the MN or CN are both valid scenarios. But, maybe there are other optimal anchor location; actually, here, we are seeking to reach optimal routing by placing the anchor closer to the optimal data path. Also, we may also want to keep a centralized anchor, for example, reachability purpose; in this case, we could say that data path going via the central anchor is the “most” optimal, because of the reachability constraint. In CP/DP distributions scenarios, we may want to distribute DP function and keep centralized some CP functions (e.g. billing… yes, operators like this function J).

 

So, I think that anchoring location considerations should be more generic and should focus on datapath management. I’d suggest the following rewording:

 

------- OLD TEXT ------------

 

by distributing mobility functions more closer to the user and/or its corresponding nodes.

 

 

---------- NEW TEXT ---------

 

by distributing forwarding functions more closer to the optimal data path; for example, closer either to the mobile user or the corresponding node.

 

Pirrick

 

 

De : dmm [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin
Envoyé : mardi 18 mars 2014 10:19
À : Charlie P.; Weixinpeng
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions <was, Re: DMM WG next steps>

 

Hello Xinpeng,

 

In the legacy thinking, the mobility anchor is in the core network (centrally-located HA). That's the basic Mobile IP design.

Now people are also considering placing anchors in the access network.

And then there's one more possibility, which is to place an anchor near/on the corresponding node. 

 

Please see the Cnet-homing presentation for more: http://www.ietf.org/proceedings/87/slides/slides-87-dmm-2.pdf

 

Questions/comments welcome.

 

Charlie: 

 

Yes, we cannot assume there'll be an anchor on/near every CN. Our proposal takes that into account.

 

In fact, today there's no anchor in every access network either. There's basically none in any WiFi network today.

 

Both situation is subject to change based on DMM developments.

 

Alper

 

 

 

 

 

 

 

 

On Mar 18, 2014, at 9:08 AM, Charlie P. wrote:

 

Hello folks,

One difference is that a mobile node is likely to be located in a network that supports mobility, whereas the network hosting a general CN may not have any mobility support features.

Regards,
Charlie P.

-----Original Message----- 
From: Weixinpeng 
Sent: Mar 17, 2014 11:59 PM 
To: Alper Yegin , Jouni Korhonen 
Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" 
Subject: Re: [DMM] DMM WG next steps 

Hi Alper,

Is there any essential difference between placing the mobility function closer to the user  and placing

the mobility function closer to the CN?   I think in some sense the user host and it’s corresponding node are the same for mobility management protocol.

So what’s the reason to distinguish between them?

 

BR,

xinpeng

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin
Sent: Wednesday, March 05, 2014 9:04 PM
To: Jouni Korhonen
Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org
Subject: Re: [DMM] DMM WG next steps

 

Jouni,

 

Thanks for the text.

 

      DMM can be used to realise such a distributed deployment
      model, by distributing mobility functions more closer to the user.

 

 

This part excludes the approaches that place the mobility function on or near the CN.

 

I recommend the following revision:

 

 

      DMM can be used to realise such a distributed deployment
      model, by distributing mobility functions more closer to the user
      and/or its corresponding nodes.

 

Alper

 

 

 

 

 

 

On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote:



Folks,

DMM WG has done some progress lately. The requirements document has
already left the building and the gap analysis is heading to WGLC as
we speak. It is about the time to think what we should do next now
that we have grown out of the infancy. 

A smaller group of mobility enthusiasts have been discussing about
possible next steps and how the possible new charter would look like. 
The current very draft text template can be found here:
     https://github.com/jounikor/dmm-re-charter

As you can see, we are still in early stages and all input it welcome.
Obviously, possible re-chartering depends on many things. For example,
things like getting the gap analysis out of the WG and what the IESG
says. Nothing has been fixed or decided yet. Anyhow, we will start the
discussion on re-chartering with the expectation that the DMM WG will
re-charter and continue developing new solutions and/or enhancements
in the IP mobility space.

- Jouni & Dapeng

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

 

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________

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

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


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



-- 
Best Regards/Melhores Cumprimentos/mit freundlichen Gruessen,

Rute Sofia
..............................................
COPELABS - Association for the Research and Development of Cognition and People-centric Computing
Direction
http://copelabs.ulusofona.pt
.........................................
--------------000908050308040001030802-- From nobody Wed Mar 19 05:39:45 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35F11A0750 for ; Wed, 19 Mar 2014 05:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_ibpta6tOVk for ; Wed, 19 Mar 2014 05:39:27 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id E07E31A06E0 for ; Wed, 19 Mar 2014 05:39:26 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Lz3f6-1XCdG640Ce-014cgp; Wed, 19 Mar 2014 08:39:11 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_ED1EBE83-1501-4075-BC21-2E5406F1DF79" From: Alper Yegin In-Reply-To: <53297ADD.9030905@ulusofona.pt> Date: Wed, 19 Mar 2014 14:38:56 +0200 Message-Id: <48A6EA4F-543C-4898-9F87-3A49DB5360F8@yegin.org> References: <4657461.1395126539884.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> <7998EFA2-0203-4961-B290-F44E5814E3C6@yegin.org> <15533_1395140647_53282826_15533_3650_1_81C77F07008CA24F9783A98CFD706F711420EC3F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <6979_1395146603_53283F6B_6979_768_1_8da19a47-f4d0-4410-bd96-0b54e482333a@PEXCVZYH01.corporate.adroot.infra.ftgroup> <11579_1395217879_532955D7_11579_7368_1_81C77F07008CA24F9783A98CFD706F711420F5EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> <53297ADD.9030905@ulusofona.pt> To: rute.sofia@ulusofona.pt X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:euCQamrZFFiWelGF456FYE6uTzgH3DI3Db1ff2Ly0e2 4KASx+CiqlF6H6cqu2Sg/hDMYDLrePywc58SlWzVjvUrNKDeAF N4vWRyif3kSL9qT4XuBDa1QAZ2DhrxjMykzeEasKtX0fvotGh2 Kq0nhWlkWDeZgJwvJYeoJd0edDXESr2j80jKZv8wTVMHQpJRzQ rdOc7/qEYK//72MJe0rgbVq0Es9Y0/G/mXxGGdRAGXGs5nry1+ Rzn1UwkIn3mLGf0fU2KDrPEKe94tnWe4UGmS6X0z2/pPhVQjFn cZEkI0rcmM2x4yveWMJUxi+uLEs0FqTkdcJZiepw6nmo5E9kSk apoqH4s+dDpsQqd0lQUWUtk3CPkG6ZejrM9tWBjSlZSvVdFYUz wa0/nGMgKkyQw== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/oXceTTWmWI9sTYs1bwW401hx0WI Cc: "Charlie P." , "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] Where to place mobility functions X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 12:39:35 -0000 --Apple-Mail=_ED1EBE83-1501-4075-BC21-2E5406F1DF79 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello, It's best if we didn't use the term "user", especially if there is an = ambiguity about whether the user sits on the MN or CN or both. Let's use the terms MN and CN instead. Alper On Mar 19, 2014, at 1:09 PM, Rute Sofia wrote: > Again, I think it is risky to mention optimal path or anything that = has to do with data path as this implies in-band signaling... >=20 > Concerning the CN, I believe it would be enough to state "closer to = the user". >=20 > The CN can be a MN or not. >=20 > I would also like to alert that there are proposals for architectures = where indeed the closeness of the MAPs have been explored in the context = of "closer to the user". For instance, in the EU project ULOOP = (uloop.eu), there is a coordination function (signaling) that takes care = of providing the "best" choice for a MAP according with user = preferences, roaming habits, as well as with potential network policies. >=20 > In another project (User-centric Mobility Management, = http://copelabs.ulusofona.pt/index.php/research/projects/past-projects/149= -umm, for results, papers and software) we have indeed worked solutions = which *split* the control functionality and MAPs, and analyzed the = possibility and advantages of placing it closer *to the user*. A MN or = CN. >=20 > So, the best solution which seems to suit the proposal by Pierrick as = well as solutions that already exist today is: closer to the user. Not = necessarily on the optimal *data* path. >=20 > BR > Rute Sofia >=20 > On 19-03-2014 08:31, pierrick.seite@orange.com wrote: >>=20 >> =20 >> =20 >> De : Weixinpeng [mailto:weixinpeng@huawei.com]=20 >> Envoy=E9 : mercredi 19 mars 2014 03:13 >> =C0 : SEITE Pierrick IMT/OLN; Alper Yegin; Charlie P. >> Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org; Xiongchunshan (Sam) >> Objet : RE: [DMM] Where to place mobility functions >> =20 >> Hi Pirrick, >> I agree with you that the anchoring location considerations should be = more generic. But for your suggested NEW TEXT, I think it=92s a bit of = ambiguous >> to say =93closer to the optimal data path=94, and as my understanding = what DMM is trying to do is to eliminate sub-optimal routing path = between MN and CN, >> so if the anchor is just close to optimal data path, but not on the = optimal data path, it=92s not what DMM wants. So what=92s your opinion? >> =20 >> [PS] it depends on what does =93optimal path=94 mean; actually the = ambiguity may come from that term. If =93optimal path=94 does not mean = the shortest path but =93the best we can do=94, I can agree with you. >> =20 >> =20 >> Here is my suggested TEXT: >> by distributing forwarding functions at optimal location; for = example, closer either to the mobile user or the corresponding node. >> =20 >> [PS] better J >> =20 >> BR, >> Xinpeng >> =20 >> =20 >> De : dmm [mailto:dmm-bounces@ietf.org] De la part de = pierrick.seite@orange.com >> Envoy=E9 : mardi 18 mars 2014 12:04 >> =C0 : Alper Yegin; Charlie P.; Weixinpeng >> Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org >> Objet : Re: [DMM] Where to place mobility functions >> =20 >> Hello, >> =20 >> Distributing mobility anchors closer either to the MN or CN are both = valid scenarios. But, maybe there are other optimal anchor location; = actually, here, we are seeking to reach optimal routing by placing the = anchor closer to the optimal data path. Also, we may also want to keep a = centralized anchor, for example, reachability purpose; in this case, we = could say that data path going via the central anchor is the =93most=94 = optimal, because of the reachability constraint. In CP/DP distributions = scenarios, we may want to distribute DP function and keep centralized = some CP functions (e.g. billing=85 yes, operators like this function J). >> =20 >> So, I think that anchoring location considerations should be more = generic and should focus on datapath management. I=92d suggest the = following rewording: >> =20 >> ------- OLD TEXT ------------ >> =20 >> by distributing mobility functions more closer to the user and/or its = corresponding nodes. >> =20 >> =20 >> ---------- NEW TEXT --------- >> =20 >> by distributing forwarding functions more closer to the optimal data = path; for example, closer either to the mobile user or the corresponding = node. >> =20 >> Pirrick >> =20 >> =20 >> De : dmm [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin >> Envoy=E9 : mardi 18 mars 2014 10:19 >> =C0 : Charlie P.; Weixinpeng >> Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org >> Objet : Re: [DMM] Where to place mobility functions >> =20 >> Hello Xinpeng, >> =20 >> In the legacy thinking, the mobility anchor is in the core network = (centrally-located HA). That's the basic Mobile IP design. >> Now people are also considering placing anchors in the access = network. >> And then there's one more possibility, which is to place an anchor = near/on the corresponding node.=20 >> =20 >> Please see the Cnet-homing presentation for more: = http://www.ietf.org/proceedings/87/slides/slides-87-dmm-2.pdf >> =20 >> Questions/comments welcome. >> =20 >> Charlie:=20 >> =20 >> Yes, we cannot assume there'll be an anchor on/near every CN. Our = proposal takes that into account. >> =20 >> In fact, today there's no anchor in every access network either. = There's basically none in any WiFi network today. >> =20 >> Both situation is subject to change based on DMM developments. >> =20 >> Alper >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> On Mar 18, 2014, at 9:08 AM, Charlie P. wrote: >> =20 >>=20 >> Hello folks, >>=20 >> One difference is that a mobile node is likely to be located in a = network that supports mobility, whereas the network hosting a general CN = may not have any mobility support features. >>=20 >> Regards, >> Charlie P. >>=20 >> -----Original Message-----=20 >> From: Weixinpeng=20 >> Sent: Mar 17, 2014 11:59 PM=20 >> To: Alper Yegin , Jouni Korhonen=20 >> Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org"=20 >> Subject: Re: [DMM] DMM WG next steps=20 >>=20 >>=20 >> Hi Alper, >> Is there any essential difference between placing the mobility = function closer to the user and placing >> the mobility function closer to the CN? I think in some sense the = user host and it=92s corresponding node are the same for mobility = management protocol. >> So what=92s the reason to distinguish between them? >> =20 >> BR, >> xinpeng >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin >> Sent: Wednesday, March 05, 2014 9:04 PM >> To: Jouni Korhonen >> Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org >> Subject: Re: [DMM] DMM WG next steps >> =20 >> Jouni, >> =20 >> Thanks for the text. >> =20 >> DMM can be used to realise such a distributed deployment >> model, by distributing mobility functions more closer to the = user. >> =20 >> =20 >> This part excludes the approaches that place the mobility function on = or near the CN. >> =20 >> I recommend the following revision: >> =20 >> =20 >> DMM can be used to realise such a distributed deployment >> model, by distributing mobility functions more closer to the = user >> and/or its corresponding nodes. >> =20 >> Alper >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote: >>=20 >>=20 >>=20 >> Folks, >>=20 >> DMM WG has done some progress lately. The requirements document has >> already left the building and the gap analysis is heading to WGLC as >> we speak. It is about the time to think what we should do next now >> that we have grown out of the infancy.=20 >>=20 >> A smaller group of mobility enthusiasts have been discussing about >> possible next steps and how the possible new charter would look like.=20= >> The current very draft text template can be found here: >> https://github.com/jounikor/dmm-re-charter >>=20 >> As you can see, we are still in early stages and all input it = welcome. >> Obviously, possible re-chartering depends on many things. For = example, >> things like getting the gap analysis out of the WG and what the IESG >> says. Nothing has been fixed or decided yet. Anyhow, we will start = the >> discussion on re-chartering with the expectation that the DMM WG will >> re-charter and continue developing new solutions and/or enhancements >> in the IP mobility space. >>=20 >> - Jouni & Dapeng >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> =20 >> =20 >> = __________________________________________________________________________= _______________________________________________ >> =20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >> =20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >> = __________________________________________________________________________= _______________________________________________ >> =20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >> =20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 > --=20 > Best Regards/Melhores Cumprimentos/mit freundlichen Gruessen, >=20 > Rute Sofia > .............................................. > COPELABS - Association for the Research and Development of Cognition = and People-centric Computing > Direction > http://copelabs.ulusofona.pt > ......................................... --Apple-Mail=_ED1EBE83-1501-4075-BC21-2E5406F1DF79 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Let's use the terms MN and CN = instead.


Alper



On Mar 19, 2014, at 1:09 PM, Rute = Sofia wrote:

=20 =20
Again, I think it is risky to mention optimal path or anything that has to do with data path as this implies in-band signaling...

Concerning the CN, I believe it would be enough to state "closer to the user".

The CN can be a MN or not.

I would also like to alert that there are proposals for architectures where indeed the closeness of the MAPs have been explored in the context of "closer to the user". For instance, in the EU project ULOOP (uloop.eu), = there is a coordination function (signaling) that takes care of providing the "best" choice for a MAP according with user preferences, roaming habits, as well as with potential network policies.

In another project (User-centric Mobility Management, http://copelabs.ulusofona.pt/index.php/research/projects/pas= t-projects/149-umm, for results, papers and software) we have indeed worked solutions which *split* the control functionality and MAPs, and analyzed the possibility and advantages of placing it closer *to the user*. A MN or CN.

So, the best solution which seems to suit the proposal by Pierrick as well as solutions that already exist today is: closer to the user. Not necessarily on the optimal *data* path.

BR
Rute Sofia

On 19-03-2014 08:31, pierrick.seite@orange.com = wrote:

 

 

De : Weixinpeng [mailto:weixinpeng@huawei.com]
Envoy=E9 : mercredi 19 mars 2014 03:13
=C0 : SEITE Pierrick IMT/OLN; Alper Yegin; Charlie P.
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org; Xiongchunshan (Sam)
Objet : RE: [DMM] Where to place mobility functions <was, Re: DMM WG next = steps>

 

Hi Pirrick,

I agree with you that the anchoring location considerations should be more generic. But for your suggested NEW TEXT, I think it=92s a bit of ambiguous

to say =93closer = to the optimal data path=94, and as my understanding what DMM is trying to do is to eliminate sub-optimal routing path between MN and CN,

so if the anchor = is just close to optimal data path, but not on the optimal data path, it=92s not what DMM wants. So what=92s your opinion?

 

[PS] it depends = on what does =93optimal path=94 mean; actually the ambiguity = may come from that term.  If =93optimal path=94 does not = mean the shortest path but =93the best we can do=94, I can agree = with you.

 

 

Here is my suggested TEXT:

by distributing forwarding functions at optimal location; for example, closer either to the mobile user or the corresponding node.

 

[PS] better J

 

BR,

Xinpeng

 

 

De : dmm = [mailto:dmm-bounces@ietf.org] De la part de pierrick.seite@orange.com Envoy=E9 : mardi 18 mars 2014 = 12:04
=C0 : Alper Yegin; Charlie P.; = Weixinpeng
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place = mobility functions <was, Re: DMM WG next = steps>

 

Hello,

 

Distributing mobility anchors closer either to the MN or CN are both valid scenarios. But, maybe there are other optimal anchor location; actually, here, we are seeking to reach optimal routing by placing the anchor closer to the optimal data path. Also, we may also want to keep a centralized anchor, for example, reachability purpose; in this case, we could say that data path going via the central anchor is the =93most=94= optimal, because of the reachability constraint. In CP/DP distributions scenarios, we may want to distribute DP function and keep centralized some CP functions (e.g. billing=85 yes, operators like this function J).

 

So, I think that anchoring location considerations should be more generic and should focus on datapath management. I=92d suggest the following = rewording:

 

------- OLD TEXT ------------

 

by= distributing mobility functions more closer to the user and/or its corresponding nodes.

 

 

---------- NEW TEXT ---------

 

by= distributing forwarding functions more closer to the optimal data path; for example, closer either to the mobile user or the corresponding node.

 

Pirrick

 

 

De : dmm [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin
Envoy=E9 : mardi 18 mars 2014 = 10:19
=C0 : Charlie P.; Weixinpeng
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place = mobility functions <was, Re: DMM WG next = steps>

 

Hello = Xinpeng,

 

In the = legacy thinking, the mobility anchor is in the core network (centrally-located HA). That's the basic Mobile IP design.

Now people = are also considering placing anchors in the access network.

And then = there's one more possibility, which is to place an anchor near/on the corresponding = node. 

 

Please see = the Cnet-homing presentation for more: htt= p://www.ietf.org/proceedings/87/slides/slides-87-dmm-2.pdf<= /span>

 

Questions/comments welcome.

 

Charlie: 

 

Yes, we = cannot assume there'll be an anchor on/near every CN. Our proposal takes that into = account.

 

In fact, = today there's no anchor in every access network either. There's basically none in any WiFi network = today.

 

Both = situation is subject to change based on DMM = developments.

 

Alper

 

 

 

 

 

 

 

 

On Mar = 18, 2014, at 9:08 AM, Charlie P. = wrote:

 

Hello folks,

One difference is that a mobile node is likely to be located in a network that supports mobility, whereas the network hosting a general CN may not have any mobility support = features.

Regards,
Charlie P.

-----Original Message----- 
From: Weixinpeng 
Sent: Mar 17, 2014 11:59 PM 
To: Alper Yegin , Jouni Korhonen 
Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" 
Subject: Re: [DMM] DMM WG next steps 

Hi Alper,

Is there any essential difference between placing the mobility function closer to the user =  and placing

the mobility function closer to the CN? =   I think in some sense the user host and it=92s corresponding node are the same for mobility management protocol.

So what=92s the reason to distinguish between = them?

 

BR,

xinpeng

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin
Sent: Wednesday, March 05, 2014 9:04 PM
To: Jouni Korhonen
Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org Subject: Re: [DMM] DMM WG next steps

 

Jouni,

 

Thanks for the text.

 

      DMM can be used to realise =
such a distributed deployment
      model, by =
distributing mobility functions more closer to the user.

 

 

This part excludes the approaches that place the mobility function on or near the = CN.

 

I recommend the following = revision:

 

 

      DMM can be used to realise =
such a distributed deployment
      model, by =
distributing mobility functions more closer to the user
      and/or its corresponding =
nodes.

 

Alper

 

 

 

 

 

 

On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote:



Folks,

DMM WG has done some progress lately. The requirements document has
already left the building and the gap analysis is heading to WGLC as
we speak. It is about the time to think what we should do next now
that we have grown out of the = infancy. 

A smaller group of mobility enthusiasts have been discussing = about
possible next steps and how the possible new charter would look = like. 
The current very draft text template can be found here:
     https://github.com/jounikor/dmm-re-charter

As you can see, we are still in early stages and all input it welcome.
Obviously, possible re-chartering depends on many things. For = example,
things like getting the gap analysis out of the WG and what the IESG
says. Nothing has been fixed or decided yet. Anyhow, we will start = the
discussion on re-chartering with the expectation that the DMM WG will
re-charter and continue developing new solutions and/or enhancements
in the IP mobility space.

- Jouni & Dapeng

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

 

 

______________________________________________________________=
___________________________________________________________
 
Ce message et ses pieces jointes peuvent =
contenir des informations confidentielles ou privilegiees et ne doivent =
donc
pas etre diffuses, exploites ou copies sans =
autorisation. Si vous avez recu ce message par erreur, veuillez le =
signaler
a l'expediteur et le detruire ainsi que les =
pieces jointes. Les messages electroniques etant susceptibles =
d'alteration,
Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. =
Merci.
 
This message and its attachments may contain =
confidential or privileged information that may be protected by =
law;
they should not be distributed, used or copied =
without authorisation.
If you have received this email in error, =
please notify the sender and delete this message and its =
attachments.
As emails may be altered, Orange is not liable =
for messages that have been modified, changed or =
falsified.
Thank you.
______________________________________________________________=
___________________________________________________________
 
Ce message et ses pieces jointes peuvent =
contenir des informations confidentielles ou privilegiees et ne doivent =
donc
pas etre diffuses, exploites ou copies sans =
autorisation. Si vous avez recu ce message par erreur, veuillez le =
signaler
a l'expediteur et le detruire ainsi que les =
pieces jointes. Les messages electroniques etant susceptibles =
d'alteration,
Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. =
Merci.
 
This message and its attachments may contain =
confidential or privileged information that may be protected by =
law;
they should not be distributed, used or copied =
without authorisation.
If you have received this email in error, =
please notify the sender and delete this message and its =
attachments.
As emails may be altered, Orange is not liable =
for messages that have been modified, changed or =
falsified.
Thank you.
= 
_____________________________________________________________________=
____________________________________________________

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

This message and its attachments may contain confidential or privileged =
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and =
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.


_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/dmm



--=20
Best Regards/Melhores Cumprimentos/mit freundlichen Gruessen,

Rute Sofia
..............................................
COPELABS - Association for the Research and Development of Cognition and =
People-centric Computing
Direction
http://copelabs.ulusofona.pt
.........................................

= --Apple-Mail=_ED1EBE83-1501-4075-BC21-2E5406F1DF79-- From nobody Wed Mar 19 06:00:23 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E191A0738 for ; Wed, 19 Mar 2014 06:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KB8b2yb7BuMg for ; Wed, 19 Mar 2014 06:00:12 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 769641A0048 for ; Wed, 19 Mar 2014 06:00:11 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 2397322C5F1; Wed, 19 Mar 2014 14:00:02 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id E74ED4C074; Wed, 19 Mar 2014 14:00:01 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 19 Mar 2014 14:00:01 +0100 From: To: Alper Yegin , "rute.sofia@ulusofona.pt" Thread-Topic: [DMM] Where to place mobility functions Thread-Index: AQHPQotVVMDTcyItw0eSPoFwjfFE35rmQ/WAgAFfZXCAAG9JcIAAHtmAgAAZDACAABafYA== Date: Wed, 19 Mar 2014 13:00:00 +0000 Message-ID: <2481_1395234002_532994D1_2481_69_1_81C77F07008CA24F9783A98CFD706F711420F85C@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <4657461.1395126539884.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> <7998EFA2-0203-4961-B290-F44E5814E3C6@yegin.org> <15533_1395140647_53282826_15533_3650_1_81C77F07008CA24F9783A98CFD706F711420EC3F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <6979_1395146603_53283F6B_6979_768_1_8da19a47-f4d0-4410-bd96-0b54e482333a@PEXCVZYH01.corporate.adroot.infra.ftgroup> <11579_1395217879_532955D7_11579_7368_1_81C77F07008CA24F9783A98CFD706F711420F5EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> <53297ADD.9030905@ulusofona.pt> <48A6EA4F-543C-4898-9F87-3A49DB5360F8@yegin.org> In-Reply-To: <48A6EA4F-543C-4898-9F87-3A49DB5360F8@yegin.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F711420F85CPEXCVZYM12corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/fdZdUpXZ_AYVdoxO70NuunJmkk4 Cc: "Charlie P." , "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] Where to place mobility functions X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 13:00:20 -0000 --_000_81C77F07008CA24F9783A98CFD706F711420F85CPEXCVZYM12corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree De : Alper Yegin [mailto:alper.yegin@yegin.org] Envoy=E9 : mercredi 19 mars 2014 13:39 =C0 : rute.sofia@ulusofona.pt Cc : SEITE Pierrick IMT/OLN; Weixinpeng; Charlie P.; dmm@ietf.org; dmm-chai= rs@tools.ietf.org Objet : Re: [DMM] Where to place mobility functions Hello, It's best if we didn't use the term "user", especially if there is an ambig= uity about whether the user sits on the MN or CN or both. Let's use the terms MN and CN instead. Alper On Mar 19, 2014, at 1:09 PM, Rute Sofia wrote: Again, I think it is risky to mention optimal path or anything that has to = do with data path as this implies in-band signaling... Concerning the CN, I believe it would be enough to state "closer to the use= r". The CN can be a MN or not. I would also like to alert that there are proposals for architectures where= indeed the closeness of the MAPs have been explored in the context of "clo= ser to the user". For instance, in the EU project ULOOP (uloop.eu), there is a coordination function (signaling) that takes care of p= roviding the "best" choice for a MAP according with user preferences, roami= ng habits, as well as with potential network policies. In another project (User-centric Mobility Management, http://copelabs.uluso= fona.pt/index.php/research/projects/past-projects/149-umm, for results, pap= ers and software) we have indeed worked solutions which *split* the control= functionality and MAPs, and analyzed the possibility and advantages of pla= cing it closer *to the user*. A MN or CN. So, the best solution which seems to suit the proposal by Pierrick as well = as solutions that already exist today is: closer to the user. Not necessari= ly on the optimal *data* path. BR Rute Sofia On 19-03-2014 08:31, pierrick.seite@orange.com wrote: De : Weixinpeng [mailto:weixinpeng@huawei.com] Envoy=E9 : mercredi 19 mars 2014 03:13 =C0 : SEITE Pierrick IMT/OLN; Alper Yegin; Charlie P. Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org; Xiongchunshan (Sam) Objet : RE: [DMM] Where to place mobility functions Hi Pirrick, I agree with you that the anchoring location considerations should be more = generic. But for your suggested NEW TEXT, I think it's a bit of ambiguous to say "closer to the optimal data path", and as my understanding what DMM = is trying to do is to eliminate sub-optimal routing path between MN and CN, so if the anchor is just close to optimal data path, but not on the optimal= data path, it's not what DMM wants. So what's your opinion? [PS] it depends on what does "optimal path" mean; actually the ambiguity ma= y come from that term. If "optimal path" does not mean the shortest path b= ut "the best we can do", I can agree with you. Here is my suggested TEXT: by distributing forwarding functions at optimal location; for example, clos= er either to the mobile user or the corresponding node. [PS] better :) BR, Xinpeng De : dmm [mailto:dmm-bounces@ietf.org] De la part de pierrick.seite@orange.= com Envoy=E9 : mardi 18 mars 2014 12:04 =C0 : Alper Yegin; Charlie P.; Weixinpeng Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org Objet : Re: [DMM] Where to place mobility functions Hello, Distributing mobility anchors closer either to the MN or CN are both valid = scenarios. But, maybe there are other optimal anchor location; actually, he= re, we are seeking to reach optimal routing by placing the anchor closer to= the optimal data path. Also, we may also want to keep a centralized anchor= , for example, reachability purpose; in this case, we could say that data p= ath going via the central anchor is the "most" optimal, because of the reac= hability constraint. In CP/DP distributions scenarios, we may want to distr= ibute DP function and keep centralized some CP functions (e.g. billing... y= es, operators like this function :)). So, I think that anchoring location considerations should be more generic a= nd should focus on datapath management. I'd suggest the following rewording: ------- OLD TEXT ------------ by distributing mobility functions more closer to the user and/or its corre= sponding nodes. ---------- NEW TEXT --------- by distributing forwarding functions more closer to the optimal data path; = for example, closer either to the mobile user or the corresponding node. Pirrick De : dmm [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin Envoy=E9 : mardi 18 mars 2014 10:19 =C0 : Charlie P.; Weixinpeng Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org Objet : Re: [DMM] Where to place mobility functions Hello Xinpeng, In the legacy thinking, the mobility anchor is in the core network (central= ly-located HA). That's the basic Mobile IP design. Now people are also considering placing anchors in the access network. And then there's one more possibility, which is to place an anchor near/on = the corresponding node. Please see the Cnet-homing presentation for more: http://www.ietf.org/proce= edings/87/slides/slides-87-dmm-2.pdf Questions/comments welcome. Charlie: Yes, we cannot assume there'll be an anchor on/near every CN. Our proposal = takes that into account. In fact, today there's no anchor in every access network either. There's ba= sically none in any WiFi network today. Both situation is subject to change based on DMM developments. Alper On Mar 18, 2014, at 9:08 AM, Charlie P. wrote: Hello folks, One difference is that a mobile node is likely to be located in a network t= hat supports mobility, whereas the network hosting a general CN may not hav= e any mobility support features. Regards, Charlie P. -----Original Message----- From: Weixinpeng Sent: Mar 17, 2014 11:59 PM To: Alper Yegin , Jouni Korhonen Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps Hi Alper, Is there any essential difference between placing the mobility function clo= ser to the user and placing the mobility function closer to the CN? I think in some sense the user ho= st and it's corresponding node are the same for mobility management protoco= l. So what's the reason to distinguish between them? BR, xinpeng From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin Sent: Wednesday, March 05, 2014 9:04 PM To: Jouni Korhonen Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org Subject: Re: [DMM] DMM WG next steps Jouni, Thanks for the text. DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user. This part excludes the approaches that place the mobility function on or ne= ar the CN. I recommend the following revision: DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user and/or its corresponding nodes. Alper On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote: Folks, DMM WG has done some progress lately. The requirements document has already left the building and the gap analysis is heading to WGLC as we speak. It is about the time to think what we should do next now that we have grown out of the infancy. A smaller group of mobility enthusiasts have been discussing about possible next steps and how the possible new charter would look like. The current very draft text template can be found here: https://github.com/jounikor/dmm-re-charter As you can see, we are still in early stages and all input it welcome. Obviously, possible re-chartering depends on many things. For example, things like getting the gap analysis out of the WG and what the IESG says. Nothing has been fixed or decided yet. Anyhow, we will start the discussion on re-chartering with the expectation that the DMM WG will re-charter and continue developing new solutions and/or enhancements in the IP mobility space. - Jouni & Dapeng _______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm -- Best Regards/Melhores Cumprimentos/mit freundlichen Gruessen, Rute Sofia .............................................. COPELABS - Association for the Research and Development of Cognition and Pe= ople-centric Computing Direction http://copelabs.ulusofona.pt ......................................... ___________________________________________________________________________= ______________________________________________ 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_81C77F07008CA24F9783A98CFD706F711420F85CPEXCVZYM12corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I agree=

 <= /p>

De : Alpe= r Yegin [mailto:alper.yegin@yegin.org]
Envoy=E9 : mercredi 19 mars 2014 13:39
=C0 : rute.sofia@ulusofona.pt
Cc : SEITE Pierrick IMT/OLN; Weixinpeng; Charlie P.; dmm@ietf.o= rg; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions <was, Re= : DMM WG next steps>

 

Hello,

 

It's best if we didn't use the term "user"= , especially if there is an ambiguity about whether the user sits on the MN= or CN or both.

Let's use the terms MN and CN instead.

 

 

Alper

 

 

 

On Mar 19, 2014, at 1:09 PM, Rute Sofia wrote:<= /o:p>



Again, I think it is risky to mention optimal path o= r anything that has to do with data path as this implies in-band signaling.= ..

Concerning the CN, I believe it would be enough to state "closer to th= e user".

The CN can be a MN or not.

I would also like to alert that there are proposals for architectures where= indeed the closeness of the MAPs have been explored in the context of &quo= t;closer to the user". For instance, in the EU project ULOOP (uloop.eu), there is a coordination function (signaling) that takes care of providing the "= ;best" choice for a MAP according with user preferences, roaming habit= s, as well as with potential network policies.

In another project (User-centric Mobility Management, http://copelabs.ulusofona.pt/index.php/research/projects/past-projects/149-= umm, for results, papers and software) we have indeed worked solutions = which *split* the control functionality and MAPs, and analyzed the possibil= ity and advantages of placing it closer *to the user*. A MN or CN.

So, the best solution which seems to suit the proposal by Pierrick as well = as solutions that already exist today is: closer to the user. Not necessari= ly on the optimal *data* path.

BR
Rute Sofia

On 19-03-2014 08:31, pierrick.= seite@orange.com wrote:

 

 

De : Weix= inpeng [mailto:weixinpeng@huawei.c= om]
Envoy=E9 : mercredi 19 mars 2014 03:13
=C0 : SEITE Pierrick IMT/OLN; Alper Yegin; Charlie P.
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org; Xiongchunshan (Sam)
Objet : RE: [DMM] Where to place mobility functions <was, Re= : DMM WG next steps>

 

Hi<= span lang=3D"EN-US"> Pirrick,

I agree wi= th you that the anchoring location considerations should be more generic. B= ut for your suggested NEW TEXT, I think it’s a bit of ambiguous

to say = 220;closer to the optimal data path”, and as my understanding what DM= M is trying to do is to eliminate sub-optimal routing path between MN and CN,

so if the = anchor is just close to optimal data path, but not on the optimal data path= , it’s not what DMM wants. So what’s your opinion?<= /o:p>

 

[PS] it de= pends on what does “optimal path” mean; actually the ambiguity = may come from that term.  If “optimal path” does not mean = the shortest path but “the best we can do”, I can agree with you.

 

 

Here is my= suggested TEXT:

by distrib= uting forwarding functions at optimal location; for example, closer either = to the mobile user or the corresponding node.

 

[PS] better J

 

BR,=

Xinpeng

 

 

De : dmm = [mailto:dmm-bounces@ietf.org] De la part de pierrick.= seite@orange.com
Envoy=E9 : mardi 18 mars 2014 12:04
=C0 : Alper Yegin; Charlie P.; Weixinpeng
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions <was, Re= : DMM WG next steps>

 

Hello,

 

Distributing mobility anchors closer either= to the MN or CN are both valid scenarios. But, maybe there are other optim= al anchor location; actually, here, we are seeking to reach optimal routing by placing the anchor closer to the optimal data = path. Also, we may also want to keep a centralized anchor, for example, rea= chability purpose; in this case, we could say that data path going via the = central anchor is the “most” optimal, because of the reachability constraint. In CP/DP distributions scenarios, = we may want to distribute DP function and keep centralized some CP function= s (e.g. billing… yes, operators like this function J).

 

So, I think that anchoring location conside= rations should be more generic and should focus on datapath management. I&#= 8217;d suggest the following rewording:

 

------- OLD TEXT ------------

 

by distributing mobility functions more clo= ser to the user and/or its corresponding nodes.

 

 

---------- NEW TEXT ---------

 

by distributing forwarding functions more c= loser to the optimal data path; for example, closer either to the mobile us= er or the corresponding node.

 

Pirrick

 

 

De : dmm = [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin
Envoy=E9 : mardi 18 mars 2014 10:19
=C0 : Charlie P.; Weixinpeng
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions <was, Re= : DMM WG next steps>

 

Hello Xinpeng,

 

In the legacy thinking, the mobility anchor is in th= e core network (centrally-located HA). That's the basic Mobile IP design.

Now people are also considering placing anchors in t= he access network.

And then there's one more possibility, which is to p= lace an anchor near/on the corresponding node. 

 

Please see the Cnet-homing presentation for more:&nb= sp;http://www.ietf.org/proceedings/87/slides/slides-87-dmm-2.pdf

 

Questions/comments welcome.

 

Charlie: 

 

Yes, we cannot assume there'll be an anchor on/near = every CN. Our proposal takes that into account.

 

In fact, today there's no anchor in every access net= work either. There's basically none in any WiFi network today.

 

Both situation is subject to change based on DMM dev= elopments.

 

Alper

 

 

 

 

 

 

 

 

On Mar 18, 2014, at 9:08 AM, Charlie P. wrote:<= /o:p>

 

Hello folks,

One difference is that a mobile node is likely to be located in a network t= hat supports mobility, whereas the network hosting a general CN may not hav= e any mobility support features.

Regards,
Charlie P.

-----Original Message----- 
From: Weixinpeng 
Sent: Mar 17, 2014 11:59 PM 
To: Alper Yegin , Jouni K= orhonen 
Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" 
Subject: Re: [DMM] DMM WG next steps&= nbsp;


Hi Alper,

Is there any essential difference= between placing the mobility function closer to the user  and placing=

the mobility function closer to t= he CN?   I think in some sense the user host and it’s corre= sponding node are the same for mobility management protocol.

So what’s the reason to dis= tinguish between them?

 

BR,

xinpeng

From: dmm [mailto:dmm-bounces@ietf.org]<= span class=3D"apple-converted-space"> On Behalf Of Alper Yegin
Sent: Wednesday, M= arch 05, 2014 9:04 PM
To: Jouni Korhonen=
Cc: dmm@ietf.org;&n= bsp;dmm-chairs@tools.ie= tf.org
Subject: Re: [DMM]= DMM WG next steps

 

Jouni,

 

Thanks for the text.=

 

   =
;   DMM can be used to realise such a distributed deployment
   =
;   model, by distributing mobility functions more closer to=
 the user.

 

 

This part excludes the approache= s that place the mobility function on or near the CN.

 

I recommend the following revisi= on:

 

 

   =
;   DMM can be used to realise such a distributed deployment
   =
;   model, by distributing mobility functions more closer to=
 the user
   =
;   and/or its corresponding nodes.

 

Alper

 

 

 

 

 

 

On Mar 5, 2014, at 12:09 PM, Jou= ni Korhonen wrote:




Folks,

DMM WG has done some progress lately. The requirements document has
already left the building and the gap analysis is heading to WGLC as
we speak. It is about the time to think what we should do next now
that we have grown out of the infancy. 

A smaller group of mobility enthusiasts have been discussing about
possible next steps and how the possible new charter would look like. 
The current very draft text template can be found here:
     https://github.com/jounikor/dmm-re-ch= arter

As you can see, we are still in early stages and all input it welcome.
Obviously, possible re-chartering depends on many things. For example,
things like getting the gap analysis out of the WG and what the IESG
says. Nothing has been fixed or decided yet. Anyhow, we will start the
discussion on re-chartering with the expectation that the DMM WG will
re-charter and continue developing new solutions and/or enhancements
in the IP mobility space.

- Jouni & Dapeng

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

 

 

_=
___________________________________________________________________________=
_____________________________________________
&=
nbsp;
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
p=
as 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 ele=
ctroniques etant susceptibles d'alteration,
O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.
&=
nbsp;
T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
t=
hey should not be distributed, used or copied without authorisation.=

I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.
A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.
T=
hank you.
_=
___________________________________________________________________________=
_____________________________________________
&=
nbsp;
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
p=
as 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 ele=
ctroniques etant susceptibles d'alteration,
O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.
&=
nbsp;
T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
t=
hey should not be distributed, used or copied without authorisation.=

I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.
A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.
T=
hank you.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
 
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf=
.org/mailman/listinfo/dmm




-- 
Best Regards/Melhores Cumprimentos/mit freundlichen Gruessen,
 
Rute Sofia
..............................................
COPELABS - Association for the Research and Development of Cognition a=
nd People-centric Computing
Direction
http://copelabs.ulusofona.pt=

.........................................

 

______________________________________________________________________=
___________________________________________________

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_81C77F07008CA24F9783A98CFD706F711420F85CPEXCVZYM12corpo_-- From nobody Wed Mar 19 18:00:01 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9811A085E for ; Wed, 19 Mar 2014 17:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8sCx5HkFlFi for ; Wed, 19 Mar 2014 17:59:55 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id E3B7B1A085D for ; Wed, 19 Mar 2014 17:59:54 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id s7so90176lbd.9 for ; Wed, 19 Mar 2014 17:59:45 -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-type; bh=PuSVO1KB5mAAcvSisuS5pITx4ZfEosCOtF/qnTf2IM8=; b=QOHS1fSYYzoRMpH/bvIxe+HbXRv7t5SHy4JN9+mOmmE3nWj4K3rVBOonaYW1TJXv5R 7QQzZJ3+2Cq5nMTI7kaiRnRoxH9TNDgTA93fn5+ulAo1I0GFqW4+zcKjhN/PCunqeOAE 4AwgVJnrqiHNNRlWcIib14n75tRr7Vc5L018iTCfDBFpFXs2wEksgxC/cr/5uNSTbI7s pIT7HVjwx3EB91iGs1x6G8c6MebZxghDJoLwLu0jcobwzP9Yv3h3MfVJeY0WI3geh3Oa LaPm1VBBL280Kx7p/98WqSk2y1Kq62npF5WjXI5AtD1r/nziz1k0DCfP020F3H3wsfO4 Yfqw== MIME-Version: 1.0 X-Received: by 10.112.173.6 with SMTP id bg6mr26238355lbc.17.1395277185459; Wed, 19 Mar 2014 17:59:45 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Wed, 19 Mar 2014 17:59:45 -0700 (PDT) In-Reply-To: <2134F8430051B64F815C691A62D983182022DA@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181EC042@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831820153C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983182022DA@XCH-BLV-504.nw.nos.boeing.com> Date: Wed, 19 Mar 2014 19:59:45 -0500 Message-ID: From: Behcet Sarikaya To: "Templin, Fred L" Content-Type: multipart/alternative; boundary=001a11c239be00ab8b04f4ff492e Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/hg6srWrrGluaChuWQTCfnZX4S2s Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 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, 20 Mar 2014 00:59:58 -0000 --001a11c239be00ab8b04f4ff492e Content-Type: text/plain; charset=ISO-8859-1 I could not see any link to AERO draft? Behcet On Tue, Mar 18, 2014 at 10:03 AM, Templin, Fred L wrote: > Hi Behcet, > > > > How do you mean to submit it as a solution draft to dmm? That is > essentially > > what I am already proposing. > > > > Thanks - Fred > > > > *From:* Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > *Sent:* Monday, March 17, 2014 5:37 PM > *To:* Templin, Fred L > *Cc:* Jouni Korhonen; dmm@ietf.org; dmm-chairs@tools.ietf.org > > *Subject:* Re: [DMM] DMM WG next steps > > > > Hi Fred, > > Why don't you submit it as a solution draft to dmm? > > Then you can push for your draft instead of arguing for something that we > don't know what. > > Regards, > > Behcet > > > > On Mon, Mar 17, 2014 at 1:31 PM, Templin, Fred L < > Fred.L.Templin@boeing.com> wrote: > > Hi Jouni, > > > > -----Original Message----- > > From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] > > Sent: Saturday, March 15, 2014 9:04 PM > > To: Templin, Fred L > > Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org > > Subject: Re: [DMM] DMM WG next steps > > > > Fred, > > > > On Mar 11, 2014, at 11:48 PM, "Templin, Fred L" < > Fred.L.Templin@boeing.com> wrote: > > > > > Hi Jouni, > > > > > > I think AERO fits paragraph 3 of the proposed new charter. AERO is a > > > mobility solution for IPv6, where each node gets at least a /64. It > > > has in-built route optimization, and can run over either IPv6 or IPv4 > > > networks as a "link layer" for mobility. AERO expects a distributed > > > mobility management environment, where a network of servers and > > > relays keeps track of mobile node locations without single point > > > of failure concerns. > > > > > > AERO is somewhat like MIPv6, but differs in that it treats the > > > underlying network as a link-layer for IPv6 using a non-broadcast > > > multiple access (NBMA) interface model. AERO uses IPv6 ND messaging > > > and the IPv6 neighbor cache on the AERO "link" instead of MIPv6 > > > mechanisms, and uses DHCPv6 PD exchanges instead of RS/RA for mobile > > > node coordinations. The mobile nodes can therefore act as mobile > > > routers and can provide stable network access for their connected > > > networks (where each mobile node and its connected networks is > > > a "site"). > > > > > > Here is a pointer to the spec. Please have a look and let me know > > > what you think, > > > > There has been zero prior discussion or activity on this > > topic in DMM that I recall. Furthermore, the current draft > > seems to be a bis of RFC6707, driven by a single individual > > and quite far in the preparation so I do not see a reason > > involving this into the WG work. > > AERO is about mobility in general and distributed mobility management > in particular. It also provides a solution to the route optimization > problem cited in RFC5522 (which came from MEXT). > > AERO should be of interest to anyone interested in network mobilitiy, > route optimization and distributed mobility management. IMHO, it is > a better way of doing things than prior methods and this group would > do well to consider it. > > Thanks - Fred > fred.l.templin@boeing.com > > > > - JOuni > > > > > > > > > > https://datatracker.ietf.org/doc/draft-templin-aerolink/ > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > >> -----Original Message----- > > >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen > > >> Sent: Wednesday, March 05, 2014 2:10 AM > > >> To: dmm@ietf.org > > >> Cc: dmm-chairs@tools.ietf.org > > >> Subject: [DMM] DMM WG next steps > > >> > > >> Folks, > > >> > > >> DMM WG has done some progress lately. The requirements document has > > >> already left the building and the gap analysis is heading to WGLC as > > >> we speak. It is about the time to think what we should do next now > > >> that we have grown out of the infancy. > > >> > > >> A smaller group of mobility enthusiasts have been discussing about > > >> possible next steps and how the possible new charter would look like. > > >> The current very draft text template can be found here: > > >> https://github.com/jounikor/dmm-re-charter > > >> > > >> As you can see, we are still in early stages and all input it welcome. > > >> Obviously, possible re-chartering depends on many things. For example, > > >> things like getting the gap analysis out of the WG and what the IESG > > >> says. Nothing has been fixed or decided yet. Anyhow, we will start the > > >> discussion on re-chartering with the expectation that the DMM WG will > > >> re-charter and continue developing new solutions and/or enhancements > > >> in the IP mobility space. > > >> > > >> - 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 > > > --001a11c239be00ab8b04f4ff492e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I could not see any link to AERO draft?

= Behcet


On Tue, Mar 18, 2014 at 10:03 AM, Templin, Fred L <= Fred.L.Templ= in@boeing.com> wrote:

Hi Behcet,<= /span>

=A0<= /p>

How do you mean to submit= it as a solution draft to dmm? That is essentially

what I am already proposi= ng.

=A0<= /p>

Thanks - Fred

=A0<= /p>

From: Behcet S= arikaya [mailto:sarikaya2012@gmail.com]
Sent: Monday, March 17, 2014 5:37 PM
To: Templin, Fred L
Cc: Jouni Korhonen; dmm@ietf.org; dmm-chairs@tools.ietf.org


Subject: Re: [DMM] DMM WG next steps

=A0

Hi Fred,

Why don't you sub= mit it as a solution draft to dmm?

Then you can push for= your draft instead of arguing for something that we don't know what.

Regards,

Behcet

=A0

On Mon, Mar 17, 2014 at 1:31 PM, Templin, Fred L <= ;Fred.L.Temp= lin@boeing.com> wrote:

Hi Jouni,


> -----Original Message-----
> From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]
> Sent: Saturday, March 15, 2014 9:04 PM
> To: Templin, Fred L
> Cc: dmm@ietf.org= ; dmm-chairs@tools.ietf.org
> Subject: Re: [DMM] DMM WG next steps
>
> Fred,
>
> On Mar 11, 2014, at 11:48 PM, "Templin, Fred L" <Fred.L.Templin@boei= ng.com> wrote:
>
> > Hi Jouni,
> >
> > I think AERO fits paragraph 3 of the proposed new charter. AERO i= s a
> > mobility solution for IPv6, where each node gets at least a /64. = It
> > has in-built route optimization, and can run over either IPv6 or = IPv4
> > networks as a "link layer" for mobility. AERO expects a= distributed
> > mobility management environment, where a network of servers and > > relays keeps track of mobile node locations without single point<= br> > > of failure concerns.
> >
> > AERO is somewhat like MIPv6, but differs in that it treats the > > underlying network as a link-layer for IPv6 using a non-broadcast=
> > multiple access (NBMA) interface model. AERO uses IPv6 ND messagi= ng
> > and the IPv6 neighbor cache on the AERO "link" instead = of MIPv6
> > mechanisms, and uses DHCPv6 PD exchanges instead of RS/RA for mob= ile
> > node coordinations. The mobile nodes can therefore act as mobile<= br> > > routers and can provide stable network access for their connected=
> > networks (where each mobile node and its connected networks is > > a "site").
> >
> > Here is a pointer to the spec. Please have a look and let me know=
> > what you think,
>
> There has been zero prior discussion or activity on this
> topic in DMM that I recall. Furthermore, the current draft
> seems to be a bis of RFC6707, driven by a single individual
> and quite far in the preparation so I do not see a reason
> involving this into the WG work.

AERO is about mobility in general and distributed mo= bility management
in particular. It also provides a solution to the route optimization
problem cited in RFC5522 (which came from MEXT).

AERO should be of interest to anyone interested in network mobilitiy,
route optimization and distributed mobility management. IMHO, it is
a better way of doing things than prior methods and this group would
do well to consider it.

Thanks - Fred
fred.l.templ= in@boeing.com


> - JOuni
>
>
> >
> > https://datatracker.ietf.org/doc/draft-templin-aerolink/
> >
> > Thanks - Fred
> > fr= ed.l.templin@boeing.com
> >
> >> -----Original Message-----
> >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen
> >> Sent: Wednesday, March 05, 2014 2:10 AM
> >> To: dmm@iet= f.org
> >> Cc: dmm-chairs@tools.ietf.org
> >> Subject: [DMM] DMM WG next steps
> >>
> >> Folks,
> >>
> >> DMM WG has done some progress lately. The requirements docume= nt has
> >> already left the building and the gap analysis is heading to = WGLC as
> >> we speak. It is about the time to think what we should do nex= t now
> >> that we have grown out of the infancy.
> >>
> >> A smaller group of mobility enthusiasts have been discussing = about
> >> possible next steps and how the possible new charter would lo= ok like.
> >> The current very draft text template can be found here:
> >> =A0 =A0https://github.com/jounikor/dmm-re-charter
> >>
> >> As you can see, we are still in early stages and all input it= welcome.
> >> Obviously, possible re-chartering depends on many things. For= example,
> >> things like getting the gap analysis out of the WG and what t= he IESG
> >> says. Nothing has been fixed or decided yet. Anyhow, we will = start the
> >> discussion on re-chartering with the expectation that the DMM= WG will
> >> re-charter and continue developing new solutions and/or enhan= cements
> >> in the IP mobility space.
> >>
> >> - Jouni & Dapeng
> >>
> >> _______________________________________________
> >> dmm mailing list
> >> dmm@ietf.or= g
> >> https://www.ietf.org/mailman/listinfo/dmm

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

=A0


--001a11c239be00ab8b04f4ff492e-- From nobody Wed Mar 19 18:27:06 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131761A0870 for ; Wed, 19 Mar 2014 18:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVZzs5i0V_tr for ; Wed, 19 Mar 2014 18:26:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAF11A087A for ; Wed, 19 Mar 2014 18:26:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCG01731; Thu, 20 Mar 2014 01:26:36 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 20 Mar 2014 01:26:28 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 20 Mar 2014 01:26:35 +0000 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.24]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 20 Mar 2014 09:26:32 +0800 From: Weixinpeng To: Alper Yegin , "rute.sofia@ulusofona.pt" Thread-Topic: [DMM] Where to place mobility functions Thread-Index: AQHPQpnSZ8BM0UGYekarrZLnkSmZL5rmQ/WAgAFfZXD//+yIAIAALCSAgAAZDACAAVu5cA== Date: Thu, 20 Mar 2014 01:26:32 +0000 Message-ID: References: <4657461.1395126539884.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> <7998EFA2-0203-4961-B290-F44E5814E3C6@yegin.org> <15533_1395140647_53282826_15533_3650_1_81C77F07008CA24F9783A98CFD706F711420EC3F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <6979_1395146603_53283F6B_6979_768_1_8da19a47-f4d0-4410-bd96-0b54e482333a@PEXCVZYH01.corporate.adroot.infra.ftgroup> <11579_1395217879_532955D7_11579_7368_1_81C77F07008CA24F9783A98CFD706F711420F5EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> <53297ADD.9030905@ulusofona.pt> <48A6EA4F-543C-4898-9F87-3A49DB5360F8@yegin.org> In-Reply-To: <48A6EA4F-543C-4898-9F87-3A49DB5360F8@yegin.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.176] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46D7FA4B7nkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/VQclja_LJKRxsAcvRqnaZ_7eFio Cc: "Charlie P." , "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] Where to place mobility functions X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 01:27:04 -0000 --_000_C5C3BB522B1DDF478AA09545169155B46D7FA4B7nkgeml507mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Agree, the mobility management specific terminology "MN" "CN" would be more= explicit than "user". From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, March 19, 2014 8:39 PM To: rute.sofia@ulusofona.pt Cc: pierrick.seite@orange.com; Weixinpeng; Charlie P.; dmm@ietf.org; dmm-ch= airs@tools.ietf.org Subject: Re: [DMM] Where to place mobility functions Hello, It's best if we didn't use the term "user", especially if there is an ambig= uity about whether the user sits on the MN or CN or both. Let's use the terms MN and CN instead. Alper On Mar 19, 2014, at 1:09 PM, Rute Sofia wrote: Again, I think it is risky to mention optimal path or anything that has to = do with data path as this implies in-band signaling... Concerning the CN, I believe it would be enough to state "closer to the use= r". The CN can be a MN or not. I would also like to alert that there are proposals for architectures where= indeed the closeness of the MAPs have been explored in the context of "clo= ser to the user". For instance, in the EU project ULOOP (uloop.eu), there is a coordination function (signaling) that takes care of p= roviding the "best" choice for a MAP according with user preferences, roami= ng habits, as well as with potential network policies. In another project (User-centric Mobility Management, http://copelabs.uluso= fona.pt/index.php/research/projects/past-projects/149-umm, for results, pap= ers and software) we have indeed worked solutions which *split* the control= functionality and MAPs, and analyzed the possibility and advantages of pla= cing it closer *to the user*. A MN or CN. So, the best solution which seems to suit the proposal by Pierrick as well = as solutions that already exist today is: closer to the user. Not necessari= ly on the optimal *data* path. BR Rute Sofia On 19-03-2014 08:31, pierrick.seite@orange.com wrote: De : Weixinpeng [mailto:weixinpeng@huawei.com] Envoy=E9 : mercredi 19 mars 2014 03:13 =C0 : SEITE Pierrick IMT/OLN; Alper Yegin; Charlie P. Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org; Xiongchunshan (Sam) Objet : RE: [DMM] Where to place mobility functions Hi Pirrick, I agree with you that the anchoring location considerations should be more = generic. But for your suggested NEW TEXT, I think it's a bit of ambiguous to say "closer to the optimal data path", and as my understanding what DMM = is trying to do is to eliminate sub-optimal routing path between MN and CN, so if the anchor is just close to optimal data path, but not on the optimal= data path, it's not what DMM wants. So what's your opinion? [PS] it depends on what does "optimal path" mean; actually the ambiguity ma= y come from that term. If "optimal path" does not mean the shortest path b= ut "the best we can do", I can agree with you. Here is my suggested TEXT: by distributing forwarding functions at optimal location; for example, clos= er either to the mobile user or the corresponding node. [PS] better :) BR, Xinpeng De : dmm [mailto:dmm-bounces@ietf.org] De la part de pierrick.seite@orange.= com Envoy=E9 : mardi 18 mars 2014 12:04 =C0 : Alper Yegin; Charlie P.; Weixinpeng Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org Objet : Re: [DMM] Where to place mobility functions Hello, Distributing mobility anchors closer either to the MN or CN are both valid = scenarios. But, maybe there are other optimal anchor location; actually, he= re, we are seeking to reach optimal routing by placing the anchor closer to= the optimal data path. Also, we may also want to keep a centralized anchor= , for example, reachability purpose; in this case, we could say that data p= ath going via the central anchor is the "most" optimal, because of the reac= hability constraint. In CP/DP distributions scenarios, we may want to distr= ibute DP function and keep centralized some CP functions (e.g. billing... y= es, operators like this function :)). So, I think that anchoring location considerations should be more generic a= nd should focus on datapath management. I'd suggest the following rewording= : ------- OLD TEXT ------------ by distributing mobility functions more closer to the user and/or its corre= sponding nodes. ---------- NEW TEXT --------- by distributing forwarding functions more closer to the optimal data path; = for example, closer either to the mobile user or the corresponding node. Pirrick De : dmm [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin Envoy=E9 : mardi 18 mars 2014 10:19 =C0 : Charlie P.; Weixinpeng Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org Objet : Re: [DMM] Where to place mobility functions Hello Xinpeng, In the legacy thinking, the mobility anchor is in the core network (central= ly-located HA). That's the basic Mobile IP design. Now people are also considering placing anchors in the access network. And then there's one more possibility, which is to place an anchor near/on = the corresponding node. Please see the Cnet-homing presentation for more: http://www.ietf.org/proce= edings/87/slides/slides-87-dmm-2.pdf Questions/comments welcome. Charlie: Yes, we cannot assume there'll be an anchor on/near every CN. Our proposal = takes that into account. In fact, today there's no anchor in every access network either. There's ba= sically none in any WiFi network today. Both situation is subject to change based on DMM developments. Alper On Mar 18, 2014, at 9:08 AM, Charlie P. wrote: Hello folks, One difference is that a mobile node is likely to be located in a network t= hat supports mobility, whereas the network hosting a general CN may not hav= e any mobility support features. Regards, Charlie P. -----Original Message----- From: Weixinpeng Sent: Mar 17, 2014 11:59 PM To: Alper Yegin , Jouni Korhonen Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] DMM WG next steps Hi Alper, Is there any essential difference between placing the mobility function clo= ser to the user and placing the mobility function closer to the CN? I think in some sense the user ho= st and it's corresponding node are the same for mobility management protoco= l. So what's the reason to distinguish between them? BR, xinpeng From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin Sent: Wednesday, March 05, 2014 9:04 PM To: Jouni Korhonen Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org Subject: Re: [DMM] DMM WG next steps Jouni, Thanks for the text. DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user. This part excludes the approaches that place the mobility function on or ne= ar the CN. I recommend the following revision: DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user and/or its corresponding nodes. Alper On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote: Folks, DMM WG has done some progress lately. The requirements document has already left the building and the gap analysis is heading to WGLC as we speak. It is about the time to think what we should do next now that we have grown out of the infancy. A smaller group of mobility enthusiasts have been discussing about possible next steps and how the possible new charter would look like. The current very draft text template can be found here: https://github.com/jounikor/dmm-re-charter As you can see, we are still in early stages and all input it welcome. Obviously, possible re-chartering depends on many things. For example, things like getting the gap analysis out of the WG and what the IESG says. Nothing has been fixed or decided yet. Anyhow, we will start the discussion on re-chartering with the expectation that the DMM WG will re-charter and continue developing new solutions and/or enhancements in the IP mobility space. - Jouni & Dapeng _______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm -- Best Regards/Melhores Cumprimentos/mit freundlichen Gruessen, Rute Sofia .............................................. COPELABS - Association for the Research and Development of Cognition and Pe= ople-centric Computing Direction http://copelabs.ulusofona.pt ......................................... --_000_C5C3BB522B1DDF478AA09545169155B46D7FA4B7nkgeml507mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Agree, the= mobility management specific terminology “MN” “CN”= would be more explicit than “user”.

 = ;

From: Alper Yegin [mailto:alper.yegin@yegin.org]
Sent: Wednesday, March 19, 2014 8:39 PM
To: rute.sofia@ulusofona.pt
Cc: pierrick.seite@orange.com; Weixinpeng; Charlie P.; dmm@ietf.org;= dmm-chairs@tools.ietf.org
Subject: Re: [DMM] Where to place mobility functions <was, Re: DM= M WG next steps>

 

Hello,

 

It's best if we didn't use the = term "user", especially if there is an ambiguity about whether th= e user sits on the MN or CN or both.

Let's use the terms MN and CN i= nstead.

 

 

Alper

 

 

 

On Mar 19, 2014, at 1:09 PM, Ru= te Sofia wrote:



Again, I think it is risky to m= ention optimal path or anything that has to do with data path as this impli= es in-band signaling...

Concerning the CN, I believe it would be enough to state "closer to th= e user".

The CN can be a MN or not.

I would also like to alert that there are proposals for architectures where= indeed the closeness of the MAPs have been explored in the context of &quo= t;closer to the user". For instance, in the EU project ULOOP (uloop.eu), there is a coordination function (signaling) that takes care of providing the "= ;best" choice for a MAP according with user preferences, roaming habit= s, as well as with potential network policies.

In another project (User-centric Mobility Management, http://copelabs.ulusofona.pt/index.php/research/projects/past-projects/149-= umm, for results, papers and software) we have indeed worked solutions = which *split* the control functionality and MAPs, and analyzed the possibil= ity and advantages of placing it closer *to the user*. A MN or CN.

So, the best solution which seems to suit the proposal by Pierrick as well = as solutions that already exist today is: closer to the user. Not necessari= ly on the optimal *data* path.

BR
Rute Sofia

On 19-03-2014 08:31, pierrick.= seite@orange.com wrote:

 

 

De : Weixinpeng [mailto:weixinpeng@huawei.com]
Envoy=E9 : mercredi 19 mars 2014 03:13
=C0 : SEITE Pierrick IMT/OLN; Alper Yegin; Charlie P.
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org; Xiongchunshan (Sam)
Objet : RE: [DMM] Where to place mobility functions <was, Re= : DMM WG next steps>

 

Hi<= span lang=3D"EN-US"> Pirrick,

I agree wi= th you that the anchoring location considerations should be more generic. B= ut for your suggested NEW TEXT, I think it’s a bit of ambiguous

to say = 220;closer to the optimal data path”, and as my understanding what DM= M is trying to do is to eliminate sub-optimal routing path between MN and CN,

so if the = anchor is just close to optimal data path, but not on the optimal data path= , it’s not what DMM wants. So what’s your opinion?

 

[PS] it de= pends on what does “optimal path” mean; actually the ambiguity = may come from that term.  If “optimal path” does not mean = the shortest path but “the best we can do”, I can agree with you.

 

 

Here is my= suggested TEXT:

by distrib= uting forwarding functions at optimal location; for example, closer either = to the mobile user or the corresponding node.

 

[PS] bette= r J

 

BR,=

Xinpeng

 

 

De : dmm [mail= to:dmm-bounces@ietf.org] De la part de pierrick.= seite@orange.com
Envoy=E9 : mardi 18 mars 2014 12:04
=C0 : Alper Yegin; Charlie P.; Weixinpeng
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions <was, Re= : DMM WG next steps>

 

Hello,

 

Distributing mobility anchors closer either= to the MN or CN are both valid scenarios. But, maybe there are other optim= al anchor location; actually, here, we are seeking to reach optimal routing by placing the anchor closer to the optimal data = path. Also, we may also want to keep a centralized anchor, for example, rea= chability purpose; in this case, we could say that data path going via the = central anchor is the “most” optimal, because of the reachability constraint. In CP/DP distributions scenarios, = we may want to distribute DP function and keep centralized some CP function= s (e.g. billing… yes, operators like this function J).<= /o:p>

 

So, I think that anchoring location conside= rations should be more generic and should focus on datapath management. I&#= 8217;d suggest the following rewording:

 

------- OLD TEXT ------------

 

by distributing mobility functions more clo= ser to the user and/or its corresponding nodes.

 

 

---------- NEW TEXT ---------

 

by distributing forwarding functions more c= loser to the optimal data path; for example, closer either to the mobile us= er or the corresponding node.

 

Pirrick

 

 

De : dmm [mail= to:dmm-bounces@ietf.org] De la part de Alper Yegin
Envoy=E9 : mardi 18 mars 2014 10:19
=C0 : Charlie P.; Weixinpeng
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions <was, Re= : DMM WG next steps>

 

Hello Xinpeng,

 

In the legacy thinking, the mob= ility anchor is in the core network (centrally-located HA). That's the basi= c Mobile IP design.

Now people are also considering= placing anchors in the access network.

And then there's one more possi= bility, which is to place an anchor near/on the corresponding node. 

 

Please see the Cnet-homing pres= entation for more: http://www.ietf.org/proceedings/87/slides/slides-87-= dmm-2.pdf

 

Questions/comments welcome.

 

Charlie: 

 

Yes, we cannot assume there'll = be an anchor on/near every CN. Our proposal takes that into account.

 

In fact, today there's no ancho= r in every access network either. There's basically none in any WiFi networ= k today.

 

Both situation is subject to ch= ange based on DMM developments.

 

Alper

 

 

 

 

 

 

 

 

On Mar 18, 2014, at 9:08 AM, Ch= arlie P. wrote:

=  

Hello folks,

One difference is that a mobile node is likely to be located in a network t= hat supports mobility, whereas the network hosting a general CN may not hav= e any mobility support features.

Regards,
Charlie P.

-----Original Message----- 
From: Weixinpeng 
Sent: Mar 17, 2014 11:59 PM 
To: Alper Yegin , Jouni K= orhonen 
Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" 
Subject: Re: [DMM] DMM WG next steps&= nbsp;


Hi Alper,

Is there any essential difference= between placing the mobility function closer to the user  and placing=

the mobility function closer to t= he CN?   I think in some sense the user host and it’s corre= sponding node are the same for mobility management protocol.

So what’s the reason to dis= tinguish between them?

 

BR,

xinpeng

From: dmm [mailto:dmm-bounces@ietf.org]<= span class=3D"apple-converted-space"> On Behalf Of Alper Yegin
Sent: Wednesday, M= arch 05, 2014 9:04 PM
To: Jouni Korhonen=
Cc: dmm@ietf.org;&n= bsp;dmm-chairs@tools.ie= tf.org
Subject: Re: [DMM]= DMM WG next steps

 

Jouni,

 

Thanks for the text.

 

   =
;   DMM can be used to realise such a distributed deployment
   =
;   model, by distributing mobility functions more closer to=
 the user.

 

 

This part excludes the approache= s that place the mobility function on or near the CN.

 

I recommend the following revisi= on:

 

 

   =
;   DMM can be used to realise such a distributed deployment
   =
;   model, by distributing mobility functions more closer to=
 the user
   =
;   and/or its corresponding nodes.

 

Alper

 

 

 

 

 

 

On Mar 5, 2014, at 12:09 PM, Jou= ni Korhonen wrote:




Folks,

DMM WG has done some progress lately. The requirements document has
already left the building and the gap analysis is heading to WGLC as
we speak. It is about the time to think what we should do next now
that we have grown out of the infancy. 

A smaller group of mobility enthusiasts have been discussing about
possible next steps and how the possible new charter would look like. 
The current very draft text template can be found here:
     https://github.com/jounikor/dmm-re-ch= arter

As you can see, we are still in early stages and all input it welcome.
Obviously, possible re-chartering depends on many things. For example,
things like getting the gap analysis out of the WG and what the IESG
says. Nothing has been fixed or decided yet. Anyhow, we will start the
discussion on re-chartering with the expectation that the DMM WG will
re-charter and continue developing new solutions and/or enhancements
in the IP mobility space.

- Jouni & Dapeng

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

 

 

_____________________________________________________________=
____________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si =
vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. L=
es messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete alter=
e, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or =
privileged information that may be protected by law;
they should not be distributed, used or copied without author=
isation.
If you have received this email in error, please notify the s=
ender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.
Thank you.

_____________________________________________________________=
____________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si =
vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. L=
es messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete alter=
e, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or =
privileged information that may be protected by law;
they should not be distributed, used or copied without author=
isation.
If you have received this email in error, please notify the s=
ender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.
Thank you.

_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
 
_______________________________________________
dmm mailing list
dmm@ietf.org<=
o:p>
https://www.ietf.org/mailman/listinfo/dmm




-- 
Best Regards/Melhores Cumprimentos/mit freundlich=
en Gruessen,
 
Rute Sofia
..............................................
COPELABS - Association for the Research and Devel=
opment of Cognition and People-centric Computing
Direction
http://=
copelabs.ulusofona.pt
.........................................

 

--_000_C5C3BB522B1DDF478AA09545169155B46D7FA4B7nkgeml507mbxchi_-- From nobody Wed Mar 19 19:48:36 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447DD1A07FE for ; Wed, 19 Mar 2014 19:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QJqDHefRvjB for ; Wed, 19 Mar 2014 19:48:30 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3619A1A063F for ; Wed, 19 Mar 2014 19:48:29 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id s7so146195lbd.1 for ; Wed, 19 Mar 2014 19:48:20 -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-type; bh=QTYieJgSxe9aB1a1oAakg5ScDxfp8iG52G9eJCabKHA=; b=Z/UULYhFvPKxgeq7di1la3j8t4+jqlPB1kqOafqY7KmYSgrAeGC3HRaxsAZKX0tsfA ld8Bck+jgs8VmyAc6fiVs+sN3XsdKbm+8fLptOR7HbIonXf4QuZSQYnMWHFEEWTWTCK6 EA9jBK0tgdpMmU1yPdVSYl9RJacW0yoaQD1bQavP7w4s29C7H7nOfzpvUiL5MAuRHdbh WXm6jKrfdxC/vijo5TwHNbBTYprPfay7oEtMuP21XjAvE+WUi2/S+k2uCoSdV+qgOD9A KbeOYt7UlabE3Q3MP93C0xpIqnnzzirGcrYlnuaTnO7agnbwhpBiDg4Uf+fTKVlcvicU lrOg== MIME-Version: 1.0 X-Received: by 10.112.28.82 with SMTP id z18mr26644356lbg.18.1395283700771; Wed, 19 Mar 2014 19:48:20 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Wed, 19 Mar 2014 19:48:20 -0700 (PDT) In-Reply-To: <1502BDF5-6189-4297-8479-05B3345AC96A@gmail.com> References: <47C1CC71-67F1-4AC7-96AA-48BF37040C29@gmail.com> <1502BDF5-6189-4297-8479-05B3345AC96A@gmail.com> Date: Wed, 19 Mar 2014 21:48:20 -0500 Message-ID: From: Behcet Sarikaya To: Jouni Korhonen Content-Type: multipart/alternative; boundary=001a1133e8ec58714f04f500cd53 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/ILR4spLtynJ2dqawiNiuaPPLsQQ Cc: "dmm@ietf.org" Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 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, 20 Mar 2014 02:48:32 -0000 --001a1133e8ec58714f04f500cd53 Content-Type: text/plain; charset=ISO-8859-1 My suggestion is that we should be to the point. We should discuss specific solution drafts first. This could be the first charter item. Then we should go to the solution selection phase. This could be another charter item. Solution drafts can be classified easily as Client mobility based, network mobility based and Routing based We already have drafts on each of these. new revisions can be submitted in due course. WG can take some time (~6 months) to consider each. Terminology and sub-solutions should be considered parts of each category. Once we have all those, then we can go to the solution selection phase. In this phase WG makes a decision and those selected become WG documents. Regards, Behcet On Mon, Mar 17, 2014 at 9:20 PM, Jouni Korhonen wrote: > Folks, > > Triggered by the question from Behcet, we should come up with the > milestones. Few proposals: > > o The deployment models and scenarios I-D is obvious. > o Anchor selection I-D is obvious. Could we also bundle > the re-anchoring solution into this one or should it be > a different I-D? > o Mobility state exposing I-D. This would communication > between the end host and the network. Maybe also covering > the missing parts within the end host.. Are we OK with one > I-D or how people want to see this? > o .. > > - Jouni > > > On Mar 17, 2014, at 2:41 PM, Jouni Korhonen > wrote: > > > Folks, > > > > I have updated the charter draft text slightly: > > > https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt > > > > Basically: > > > > Added Sri's comment on PMIPv6 maintenance. > > Added Alper's comment of location of mobility functions. > > Added links to other IETF WGs on possible mobility enabling technologies. > > Added a comment that virtualised network functions are in scope. > > > > - Jouni > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --001a1133e8ec58714f04f500cd53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My suggestion is that we should be to the point.
We sh= ould discuss specific solution drafts first. This could be the first charte= r item.

Then we should go to the solution selection phase.
This = could be another charter item.

Solution drafts can be classifi= ed easily as
Client mobility based,
network mobility bas= ed and
Routing based

We already have drafts on each of these. n= ew revisions can be submitted in due course.

WG can take some = time (~6 months) to consider each.

Terminology and sub-solutio= ns should be considered parts of each category.

Once we have all those, then we can go to the solution selection = phase.
In this phase WG makes a decision and those selected become= WG documents.

Regards,

Behcet


On Mon, Mar 17, 2014 at 9:20 PM, Jouni K= orhonen <jouni.nospam@gmail.com> wrote:
Folks,

Triggered by the question from Behcet, we should come up with the
milestones. Few proposals:

o The deployment models and scenarios I-D is obvious.
o Anchor selection I-D is obvious. Could we also bundle
=A0 the re-anchoring solution into this one or should it be
=A0 a different I-D?
o Mobility state exposing I-D. This would communication
=A0 between the end host and the network. Maybe also covering
=A0 the missing parts within the end host.. Are we OK with one
=A0 I-D or how people want to see this?
o ..

- Jouni


On Mar 17, 2014, at 2:41 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:

> Folks,
>
> I have updated the charter draft text slightly:
> https://github.com/jounikor/dmm-re-chart= er/blob/master/recharter_draft.txt
>
> Basically:
>
> Added Sri's comment on PMIPv6 maintenance.
> Added Alper's comment of location of mobility functions.
> Added links to other IETF WGs on possible mobility enabling technologi= es.
> Added a comment that virtualised network functions are in scope.
>
> - Jouni

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

--001a1133e8ec58714f04f500cd53-- From nobody Wed Mar 19 20:01:52 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D62F1A0648 for ; Wed, 19 Mar 2014 20:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR5Ze5eya1ux for ; Wed, 19 Mar 2014 20:01:47 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8631A045D for ; Wed, 19 Mar 2014 20:01:47 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id y13so263795pdi.33 for ; Wed, 19 Mar 2014 20:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0WrGeYNczitmXRyGYr1QMOqwlMha77SoUk7D3W5O+oQ=; b=gl/LJMVYQTV3UHi0x3p3ucNCOnxY1wDY4ypJvp2gQCr2MarjW6oEY6LJN4AdveQk8R BGVw6rgYcG9GKNOrBsYxQ1FZ78AsbqxSZxXVqkOY+nv9RAOu18/4S+kB3a6gORF33kAX IpoeKGPR57u9yAwOp6z4+Ha5Itk8JtVKJW49bW2OoS/pACTNgVjuk9tAA/ATVT6HZZzc UOTzl2RIDyCJygleNeo0iklI7gBBor8r5dWkbDyMgTuna3lSv9qR597NpM1RS0ZAOBpl +ZVYNyhQwWkkNhfJVfegoWDRbxmyPtdlbDh9OT5K3WAnc0uNxpdyYOi9ijjqOyxdh+EB oEqQ== X-Received: by 10.68.110.165 with SMTP id ib5mr43558489pbb.61.1395284498611; Wed, 19 Mar 2014 20:01:38 -0700 (PDT) Received: from dhcp-18-187.meeting.verilan.com ([123.124.234.161]) by mx.google.com with ESMTPSA id pv4sm722799pbb.55.2014.03.19.20.01.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Mar 2014 20:01:33 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <0A1920BD-67A7-4ECF-9EF7-7789891CF3D3@yegin.org> Date: Thu, 20 Mar 2014 11:01:27 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <47C1CC71-67F1-4AC7-96AA-48BF37040C29@gmail.com> <1502BDF5-6189-4297-8479-05B3345AC96A@gmail.com> <0A1920BD-67A7-4ECF-9EF7-7789891CF3D3@yegin.org> To: "dmm@ietf.org" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/DmCyrn90GoD0XSjV8lzVOQaOxzg Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 03:01:49 -0000 I split the gateway selection & re-anchoring. Goals and Milestones: aaa 2014 - Submit 'The deployment models and scenarios' as a working group document. To be Informational RFC. bbb 2014 - Submit 'Enhanced gateway and mobility anchor selection' as a working group document. To be Proposed Standard. ccc 2014 - Submit 'Gateway and mobility anchor re-selection' as a working group document. To be Proposed Standard. - JOuni On Mar 18, 2014, at 5:07 PM, Alper Yegin wrote: >=20 > On Mar 18, 2014, at 4:20 AM, Jouni Korhonen wrote: >=20 >> Folks, >>=20 >> Triggered by the question from Behcet, we should come up with the=20 >> milestones. Few proposals: >>=20 >> o The deployment models and scenarios I-D is obvious. >> o Anchor selection I-D is obvious. Could we also bundle >> the re-anchoring solution into this one or should it be >> a different I-D? >=20 > I'd say re-anchoring is a separate I-D. >=20 > Btw, I take "anchor selection" as the process/algorithm for selecting = the type of anchor (e.g., one in access or core or corresponding = network), and selecting a specific anchor node of that type (e.g., = determining its IP address). >=20 > If so, that can be an I-D. >=20 > But then, how the data-path is setup and maintained between the MN and = the anchor across handovers is another I-D.=20 > And in fact, that's where more than one solutions is likely=85. So, = limiting this as "one I-D" may not work. >=20 >=20 >=20 >> o Mobility state exposing I-D. This would communication=20 >> between the end host and the network. Maybe also covering=20 >> the missing parts within the end host.. Are we OK with one >> I-D or how people want to see this? >> o .. >>=20 >=20 > There's the API aspect on the terminal (one I-D), > and there is the MN-network interface ones (e.g., extending RA, DHCP, = etc.) >=20 > Alper >=20 >=20 >=20 >=20 >=20 >> - Jouni >>=20 >>=20 >> On Mar 17, 2014, at 2:41 PM, Jouni Korhonen = wrote: >>=20 >>> Folks, >>>=20 >>> I have updated the charter draft text slightly: >>> = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >>>=20 >>> Basically: >>>=20 >>> Added Sri's comment on PMIPv6 maintenance. >>> Added Alper's comment of location of mobility functions. >>> Added links to other IETF WGs on possible mobility enabling = technologies. >>> Added a comment that virtualised network functions are in scope. >>>=20 >>> - Jouni >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 From nobody Wed Mar 19 21:04:08 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BD21A033E for ; Wed, 19 Mar 2014 21:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pa6D1Mox7t1j for ; Wed, 19 Mar 2014 21:04:03 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7661A0473 for ; Wed, 19 Mar 2014 21:04:02 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id rp16so331339pbb.17 for ; Wed, 19 Mar 2014 21:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ip7fzaYCj4uZbbLrMRB3dQDf/jvoN/GOXh1MYLM3SFY=; b=RyJ+kkbUgFFjvq6Gxt5u8bYvgRgMLNhxffqHHCBo3n+PPdW3nZ25sIvad3QCZwbU7W TaVXvMhIMugTkNAeOw4tjlkFuWGaaf9NadP8nsMWW2aHDsHZdS1FyHoIkpxPJ5/hoCdz 7LWWxyBOVP1Dy+izvBTReSmASfTe9mQA1ibXb3WK6Y23Ubwj0BaykPlDX7Y2zdE2f9JM olA8BtDj2lyHOjmKzxDZu+z3wIrPg4UGPM2O2OeOH7vMz+NRp7UB5oGp76H3noa4JiDc Rf8brJnI6MI5eBx1M+gLbzoB6uGW/iIM7w2eWNOE2p8BBVPyrcS0grH85Aggoiq4/qDN EI7g== X-Received: by 10.66.150.69 with SMTP id ug5mr44648405pab.55.1395288233367; Wed, 19 Mar 2014 21:03:53 -0700 (PDT) Received: from dhcp-18-187.meeting.verilan.com ([123.124.234.161]) by mx.google.com with ESMTPSA id fk4sm3003839pab.23.2014.03.19.21.03.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Mar 2014 21:03:52 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <0A1920BD-67A7-4ECF-9EF7-7789891CF3D3@yegin.org> Date: Thu, 20 Mar 2014 12:03:45 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9044B3AD-E734-4483-B8D1-F0DA29455EBE@gmail.com> References: <47C1CC71-67F1-4AC7-96AA-48BF37040C29@gmail.com> <1502BDF5-6189-4297-8479-05B3345AC96A@gmail.com> <0A1920BD-67A7-4ECF-9EF7-7789891CF3D3@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/rxS4jMeAsgj27FWFjZDtDaSpVIc Cc: "dmm@ietf.org" Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 04:04:06 -0000 Alper, On Mar 18, 2014, at 5:07 PM, Alper Yegin wrote: >=20 > On Mar 18, 2014, at 4:20 AM, Jouni Korhonen wrote: >=20 >> Folks, >>=20 >> Triggered by the question from Behcet, we should come up with the=20 >> milestones. Few proposals: >>=20 >> o The deployment models and scenarios I-D is obvious. >> o Anchor selection I-D is obvious. Could we also bundle >> the re-anchoring solution into this one or should it be >> a different I-D? >=20 > I'd say re-anchoring is a separate I-D. >=20 > Btw, I take "anchor selection" as the process/algorithm for selecting = the type of anchor (e.g., one in access or core or corresponding = network), and selecting a specific anchor node of that type (e.g., = determining its IP address). >=20 > If so, that can be an I-D. >=20 > But then, how the data-path is setup and maintained between the MN and = the anchor across handovers is another I-D.=20 > And in fact, that's where more than one solutions is likely=85. So, = limiting this as "one I-D" may not work. >=20 >=20 >=20 >> o Mobility state exposing I-D. This would communication=20 >> between the end host and the network. Maybe also covering=20 >> the missing parts within the end host.. Are we OK with one >> I-D or how people want to see this? >> o .. >>=20 >=20 > There's the API aspect on the terminal (one I-D), > and there is the MN-network interface ones (e.g., extending RA, DHCP, = etc.) So you want an API document? I have some reservations documenting an APIs as-is. Could this be an extension to RFC5014? I'd see this approach feasible since there are even (partial) implementations of the RFC5014 in popular operating systems. Then the subsequent thing. Each MN-NW interface would be one document, if I understand the above comment correctly? Which one(s) to do first? ND or/and DHCP? - JOuni >=20 > Alper >=20 >=20 >=20 >=20 >=20 >> - Jouni >>=20 >>=20 >> On Mar 17, 2014, at 2:41 PM, Jouni Korhonen = wrote: >>=20 >>> Folks, >>>=20 >>> I have updated the charter draft text slightly: >>> = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >>>=20 >>> Basically: >>>=20 >>> Added Sri's comment on PMIPv6 maintenance. >>> Added Alper's comment of location of mobility functions. >>> Added links to other IETF WGs on possible mobility enabling = technologies. >>> Added a comment that virtualised network functions are in scope. >>>=20 >>> - Jouni >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 From nobody Wed Mar 19 23:58:58 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55631A0584 for ; Wed, 19 Mar 2014 23:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HIunM5t8cum for ; Wed, 19 Mar 2014 23:58:52 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id E8EBF1A04E8 for ; Wed, 19 Mar 2014 23:58:51 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MWCQ5-1Wbtki3NsX-00XuMr; Thu, 20 Mar 2014 02:58:42 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_5D660E99-93F7-4FA6-8EB4-E59C847E4879" From: Alper Yegin In-Reply-To: <9044B3AD-E734-4483-B8D1-F0DA29455EBE@gmail.com> Date: Thu, 20 Mar 2014 08:58:36 +0200 Message-Id: <67B1A3D6-A8BE-4D1E-BF2D-184487E9DBD2@yegin.org> References: <47C1CC71-67F1-4AC7-96AA-48BF37040C29@gmail.com> <1502BDF5-6189-4297-8479-05B3345AC96A@gmail.com> <0A1920BD-67A7-4ECF-9EF7-7789891CF3D3@yegin.org> <9044B3AD-E734-4483-B8D1-F0DA29455EBE@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:0hT0o/yyEyjfNL7MlL71MNljpqFegKbobC/SZcO3v2S hCpD1s0y3qzMUB2/qL0QC3HKL72Z2GfdgNISymeFfrAG7OpCIR N2fxCzwU0htbx76ZtUa3V014lJ5UZgbdMUZv0qg+IFq1ziULs1 MMTwIWifizjdCh8jgQ0sqHt/J/Ir+f29sbrwT8y/09pPy4Z/ZM VtzR8um9903/0V2Ew3ViYTuOoAI2aCWt31UvnTvbvOppsy1oum zkadz5QVIF0rCvY4k8oJh8j2FihV77LwVTLyI8gJSzEwWtEj5b Q3F5lqFJXTmbxHmRrwH9HRtER2hLEY5uJ2ymILL1x830GTEIaO nGoC8L6I6ufEV1D5sYAE3XzIlppK54Lr0K1lTdwpD1/1VgfnU6 FgSFBPipZMgxg== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/sYKkqIS--jCp6g9sIQBDdWK0y48 Cc: "dmm@ietf.org" Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 06:58:55 -0000 --Apple-Mail=_5D660E99-93F7-4FA6-8EB4-E59C847E4879 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Jouni, On Mar 20, 2014, at 6:03 AM, Jouni Korhonen wrote: >>=20 >>> o Mobility state exposing I-D. This would communication=20 >>> between the end host and the network. Maybe also covering=20 >>> the missing parts within the end host.. Are we OK with one >>> I-D or how people want to see this? >>> o .. >>>=20 >>=20 >> There's the API aspect on the terminal (one I-D), >> and there is the MN-network interface ones (e.g., extending RA, DHCP, = etc.) >=20 >=20 > So you want an API document? I have some reservations documenting > an APIs as-is. Could this be an extension to RFC5014? I'd see this > approach feasible since there are even (partial) implementations of > the RFC5014 in popular operating systems. >=20 Yes, we are talking about extensions to source address selection (RFC = 5014). > Then the subsequent thing. Each MN-NW interface would be one document, > if I understand the above comment correctly? Which one(s) to do first? > ND or/and DHCP? >=20 Yes. Both. Alper > - JOuni >=20 >=20 >=20 >=20 >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>=20 >>> - Jouni >>>=20 >>>=20 >>> On Mar 17, 2014, at 2:41 PM, Jouni Korhonen = wrote: >>>=20 >>>> Folks, >>>>=20 >>>> I have updated the charter draft text slightly: >>>> = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >>>>=20 >>>> Basically: >>>>=20 >>>> Added Sri's comment on PMIPv6 maintenance. >>>> Added Alper's comment of location of mobility functions. >>>> Added links to other IETF WGs on possible mobility enabling = technologies. >>>> Added a comment that virtualised network functions are in scope. >>>>=20 >>>> - Jouni >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>=20 >=20 --Apple-Mail=_5D660E99-93F7-4FA6-8EB4-E59C847E4879 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Jouni,
= --Apple-Mail=_5D660E99-93F7-4FA6-8EB4-E59C847E4879-- From nobody Thu Mar 20 01:30:59 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EDE1A0654 for ; Thu, 20 Mar 2014 01:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U66dhUT6yncj for ; Thu, 20 Mar 2014 01:30:56 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C04691A077F for ; Thu, 20 Mar 2014 01:30:56 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id kl14so606572pab.32 for ; Thu, 20 Mar 2014 01:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DHv+ApPgLvqsZ4NSltgQFiRElmJFfZA5RpScbiwwH8U=; b=v8DmB9QxBPpFbTW5sukrOch9eGlJFXCMDOKPSWfXN3jcVSPspTzB1OvvS1M8ZUFFdj mLsNTkPYb843tD/O0FX9RPjNQx91GjlHDadgmrc/SVQTVEm/NiHa2BOgX6JeTb6xEnbP TmoE3lRpjMclxzsLWqfLLNRJckoKI+qe+DDujvE/XOVwleIpWkR1GMaighsg049YBd6D iLTQ5jNnTKxoqF8rLF9ORQvKECVFodyLVfNtg8rE9TCuRtKiy5xq9eoX6kEsyXREV9uE Rl1ZgvKOWHC6+LfIuKLTwchH2g5INKDsCrhK+/ix/Xy/eT715NhwzExPZg2a/qFv1PLE N4IA== X-Received: by 10.66.149.231 with SMTP id ud7mr45533518pab.8.1395304247931; Thu, 20 Mar 2014 01:30:47 -0700 (PDT) Received: from dhcp-18-187.meeting.verilan.com ([123.124.234.161]) by mx.google.com with ESMTPSA id g6sm6516303pat.2.2014.03.20.01.30.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Mar 2014 01:30:46 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <67B1A3D6-A8BE-4D1E-BF2D-184487E9DBD2@yegin.org> Date: Thu, 20 Mar 2014 16:30:25 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <47C1CC71-67F1-4AC7-96AA-48BF37040C29@gmail.com> <1502BDF5-6189-4297-8479-05B3345AC96A@gmail.com> <0A1920BD-67A7-4ECF-9EF7-7789891CF3D3@yegin.org> <9044B3AD-E734-4483-B8D1-F0DA29455EBE@gmail.com> <67B1A3D6-A8BE-4D1E-BF2D-184487E9DBD2@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/okSzsSlfLIaL5mcr1WXHRMErUCg Cc: "dmm@ietf.org" Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 08:30:58 -0000 On Mar 20, 2014, at 2:58 PM, Alper Yegin wrote: > Hi Jouni, >=20 > On Mar 20, 2014, at 6:03 AM, Jouni Korhonen wrote: >>>=20 >>>> o Mobility state exposing I-D. This would communication=20 >>>> between the end host and the network. Maybe also covering=20 >>>> the missing parts within the end host.. Are we OK with one >>>> I-D or how people want to see this? >>>> o .. >>>>=20 >>>=20 >>> There's the API aspect on the terminal (one I-D), >>> and there is the MN-network interface ones (e.g., extending RA, = DHCP, etc.) >>=20 >>=20 >> So you want an API document? I have some reservations documenting >> an APIs as-is. Could this be an extension to RFC5014? I'd see this >> approach feasible since there are even (partial) implementations of >> the RFC5014 in popular operating systems. >>=20 >=20 > Yes, we are talking about extensions to source address selection (RFC = 5014). Ack. >=20 >=20 >> Then the subsequent thing. Each MN-NW interface would be one = document, >> if I understand the above comment correctly? Which one(s) to do = first? >> ND or/and DHCP? >>=20 >=20 > Yes. Both. Ack. Since we are coming up with I-D numbers, any preference on the protocols that we patch..? - Jouni >=20 > Alper >=20 >=20 >=20 >> - JOuni >>=20 >>=20 >>=20 >>=20 >>>=20 >>> Alper >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> - Jouni >>>>=20 >>>>=20 >>>> On Mar 17, 2014, at 2:41 PM, Jouni Korhonen = wrote: >>>>=20 >>>>> Folks, >>>>>=20 >>>>> I have updated the charter draft text slightly: >>>>> = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >>>>>=20 >>>>> Basically: >>>>>=20 >>>>> Added Sri's comment on PMIPv6 maintenance. >>>>> Added Alper's comment of location of mobility functions. >>>>> Added links to other IETF WGs on possible mobility enabling = technologies. >>>>> Added a comment that virtualised network functions are in scope. >>>>>=20 >>>>> - Jouni >>>>=20 >>>> _______________________________________________ >>>> dmm mailing list >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >>>=20 >>=20 >=20 From nobody Thu Mar 20 01:42:01 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028211A08B0 for ; Thu, 20 Mar 2014 01:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9FAFzq03qO9 for ; Thu, 20 Mar 2014 01:41:57 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 200511A034A for ; Thu, 20 Mar 2014 01:41:57 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MUpVc-1Wchca3tue-00YkBF; Thu, 20 Mar 2014 04:41:47 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: Date: Thu, 20 Mar 2014 10:41:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <47C1CC71-67F1-4AC7-96AA-48BF37040C29@gmail.com> <1502BDF5-6189-4297-8479-05B3345AC96A@gmail.com> <0A1920BD-67A7-4ECF-9EF7-7789891CF3D3@yegin.org> <9044B3AD-E734-4483-B8D1-F0DA29455EBE@gmail.com> <67B1A3D6-A8BE-4D1E-BF2D-184487E9DBD2@yegin.org> To: Jouni Korhonen X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:I3fOSxenXueszNGXP7sH3J+x6GJ3WKmWFm01V9ZYQGd 5p+JBRHUKEMP/vq2pdTQuqlqCyBv91iv9HpX51GoQqruoXYIR4 xIGvjAnIg73BTNGVvEDHwHMCYMDesI0RxlcXYCnCX8/6GxHsMX S4aVfod3vUZB86meNvEXksKd7aHER/CVPLKwNRI7wnhRMkOH5r MzYrxh2m4G5US55zs4n17e2bbba9z8E4T+cHIJB7g6nYeYIk+G 3UzxO07dmHfiRNEegmgeuzarrqfH5TAa2coEOQyIHUniSKV/J2 N0Cb66yxMYW5yqtkxI/Si90Z8PMnVUOEm9H5OlfBuL9rQkqON/ qpyzUsygJuXRDnrjdxaEOMhc1SRKguBo/WZem1JG+NB5PIJqwx mFumfowNCI4Fw== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/zroFPZJmDRWA11Wfb27q2PpS15I Cc: "dmm@ietf.org" Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 08:41:59 -0000 On Mar 20, 2014, at 10:30 AM, Jouni Korhonen wrote: >=20 > On Mar 20, 2014, at 2:58 PM, Alper Yegin = wrote: >=20 >> Hi Jouni, >>=20 >> On Mar 20, 2014, at 6:03 AM, Jouni Korhonen wrote: >>>>=20 >>>>> o Mobility state exposing I-D. This would communication=20 >>>>> between the end host and the network. Maybe also covering=20 >>>>> the missing parts within the end host.. Are we OK with one >>>>> I-D or how people want to see this? >>>>> o .. >>>>>=20 >>>>=20 >>>> There's the API aspect on the terminal (one I-D), >>>> and there is the MN-network interface ones (e.g., extending RA, = DHCP, etc.) >>>=20 >>>=20 >>> So you want an API document? I have some reservations documenting >>> an APIs as-is. Could this be an extension to RFC5014? I'd see this >>> approach feasible since there are even (partial) implementations of >>> the RFC5014 in popular operating systems. >>>=20 >>=20 >> Yes, we are talking about extensions to source address selection (RFC = 5014). >=20 > Ack. >=20 >>=20 >>=20 >>> Then the subsequent thing. Each MN-NW interface would be one = document, >>> if I understand the above comment correctly? Which one(s) to do = first? >>> ND or/and DHCP? >>>=20 >>=20 >> Yes. Both. >=20 > Ack. Since we are coming up with I-D numbers, any preference > on the protocols that we patch..? >=20 between ND and DHCP? DHCP=85. Alper > - Jouni >=20 >=20 >>=20 >> Alper >>=20 >>=20 >>=20 >>> - JOuni >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Alper >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> - Jouni >>>>>=20 >>>>>=20 >>>>> On Mar 17, 2014, at 2:41 PM, Jouni Korhonen = wrote: >>>>>=20 >>>>>> Folks, >>>>>>=20 >>>>>> I have updated the charter draft text slightly: >>>>>> = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >>>>>>=20 >>>>>> Basically: >>>>>>=20 >>>>>> Added Sri's comment on PMIPv6 maintenance. >>>>>> Added Alper's comment of location of mobility functions. >>>>>> Added links to other IETF WGs on possible mobility enabling = technologies. >>>>>> Added a comment that virtualised network functions are in scope. >>>>>>=20 >>>>>> - Jouni >>>>>=20 >>>>> _______________________________________________ >>>>> dmm mailing list >>>>> dmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>=20 >>>=20 >>=20 >=20 From nobody Thu Mar 20 01:45:05 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D21A1A08B0 for ; Thu, 20 Mar 2014 01:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KP6_rFXTLnqs for ; Thu, 20 Mar 2014 01:45:02 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 027E31A08B9 for ; Thu, 20 Mar 2014 01:45:01 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 43CEA22C393; Thu, 20 Mar 2014 09:44:52 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 23C7735C061; Thu, 20 Mar 2014 09:44:52 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Thu, 20 Mar 2014 09:44:51 +0100 From: To: Alper Yegin , Jouni Korhonen Thread-Topic: [DMM] re-charter text updated Thread-Index: AQHPQav8IqXuPPIWy06iKl9XwXGj+5rmDRGAgANSdVWAAB//AIAAGaeAgAADKICAABDkkA== Date: Thu, 20 Mar 2014 08:44:51 +0000 Message-ID: <21621_1395305092_532AAA84_21621_3808_1_81C77F07008CA24F9783A98CFD706F711420FCF1@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <47C1CC71-67F1-4AC7-96AA-48BF37040C29@gmail.com> <1502BDF5-6189-4297-8479-05B3345AC96A@gmail.com> <0A1920BD-67A7-4ECF-9EF7-7789891CF3D3@yegin.org> <9044B3AD-E734-4483-B8D1-F0DA29455EBE@gmail.com> <67B1A3D6-A8BE-4D1E-BF2D-184487E9DBD2@yegin.org> 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.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.20.50015 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/rYiX9X72zD8-y4LmoiZXu20LBSI Cc: "dmm@ietf.org" Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 08:45:04 -0000 >-----Message d'origine----- >De=A0: dmm [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin >Envoy=E9=A0: jeudi 20 mars 2014 09:42 >=C0=A0: Jouni Korhonen >Cc=A0: dmm@ietf.org >Objet=A0: Re: [DMM] re-charter text updated > > >On Mar 20, 2014, at 10:30 AM, Jouni Korhonen wrote: > >> >> On Mar 20, 2014, at 2:58 PM, Alper Yegin wrote: >> >>> Hi Jouni, >>> >>> On Mar 20, 2014, at 6:03 AM, Jouni Korhonen wrote: >>>>> >>>>>> o Mobility state exposing I-D. This would communication between >>>>>> the end host and the network. Maybe also covering the missing >>>>>> parts within the end host.. Are we OK with one I-D or how people >>>>>> want to see this? >>>>>> o .. >>>>>> >>>>> >>>>> There's the API aspect on the terminal (one I-D), and there is the >>>>> MN-network interface ones (e.g., extending RA, DHCP, etc.) >>>> >>>> >>>> So you want an API document? I have some reservations documenting an >>>> APIs as-is. Could this be an extension to RFC5014? I'd see this >>>> approach feasible since there are even (partial) implementations of >>>> the RFC5014 in popular operating systems. >>>> >>> >>> Yes, we are talking about extensions to source address selection (RFC >5014). >> >> Ack. >> >>> >>> >>>> Then the subsequent thing. Each MN-NW interface would be one >>>> document, if I understand the above comment correctly? Which one(s) to >do first? >>>> ND or/and DHCP? >>>> >>> >>> Yes. Both. >> >> Ack. Since we are coming up with I-D numbers, any preference on the >> protocols that we patch..? >> > >between ND and DHCP? DHCP.. > I'd say ND first :-)... but, anyway, do we really need two different docum= ents? Although, container differs, I guess extensions will be the same. >Alper > > >> - Jouni >> >> >>> >>> Alper >>> >>> >>> >>>> - JOuni >>>> >>>> >>>> >>>> >>>>> >>>>> Alper >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> - Jouni >>>>>> >>>>>> >>>>>> On Mar 17, 2014, at 2:41 PM, Jouni Korhonen > wrote: >>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> I have updated the charter draft text slightly: >>>>>>> https://github.com/jounikor/dmm-re- >charter/blob/master/recharter_ >>>>>>> draft.txt >>>>>>> >>>>>>> Basically: >>>>>>> >>>>>>> Added Sri's comment on PMIPv6 maintenance. >>>>>>> Added Alper's comment of location of mobility functions. >>>>>>> Added links to other IETF WGs on possible mobility enabling >technologies. >>>>>>> Added a comment that virtualised network functions are in scope. >>>>>>> >>>>>>> - Jouni >>>>>> >>>>>> _______________________________________________ >>>>>> 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 ___________________________________________________________________________= ______________________________________________ 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 Thu Mar 20 01:56:01 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9FE1A044A for ; Thu, 20 Mar 2014 01:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJu6WJNZG8AL for ; Thu, 20 Mar 2014 01:55:59 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AA9C11A034A for ; Thu, 20 Mar 2014 01:55:59 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id x10so629165pdj.20 for ; Thu, 20 Mar 2014 01:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1BmHxN1dDzUNjZR5hKsC8U8LbQLccM3RgmrITdje/Xo=; b=mJoJoejw6bG3QsZdwHVVLacZQcZYX/dSFB2kGQmMx1MxZ5Ye+A92F8gjqzUNJVLTRs MDuLZmZI1X2SdkVzt4EctnNpjffdjiEpyxkeqDz66/g6HdznopGPIJQYMQi8wqNJFgU/ yiRcXDrALKi8Apx4xlIoyZHzrqm35zwjW50rAIP0exHuUW74SBephyeYrL8VTmwvCD9g ozgha9JN6YKkvAikYy93ARUli13ze4+QSBcXnw8Tr2sYK93Zq4SO1co9DixFI9QHTvMO EMtUJn4CDLLDFLAvBhvDB76sbpKnnDKCXj7i7JFKsc8zN1KDex01+K/3SUzr9bfVSRjG I/1Q== X-Received: by 10.66.119.136 with SMTP id ku8mr45514667pab.121.1395305741246; Thu, 20 Mar 2014 01:55:41 -0700 (PDT) Received: from [10.201.84.2] ([202.45.12.142]) by mx.google.com with ESMTPSA id dn1sm2517412pbb.54.2014.03.20.01.55.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Mar 2014 01:55:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ryuji Wakikawa In-Reply-To: <47C1CC71-67F1-4AC7-96AA-48BF37040C29@gmail.com> Date: Thu, 20 Mar 2014 17:55:37 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <47C1CC71-67F1-4AC7-96AA-48BF37040C29@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/x1-ih6_qcKfwGCgaVtZOpHtsqfs Cc: "dmm@ietf.org" Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 08:56:01 -0000 Jouni It=E2=80=99s good to see some room for non-MIP based solution in DMM;-) One clarification, the charter said following "Specifically, when solutions are not based on IP mobility protocols, the DMM workingvgroup shall = cooperate with other IETF working groups working on other technologies that might allow the mobility of an end host. These working groups = include but are not limited to I2rs, Lisp, and Forces." If we need to extend existing non-MIP protocols, it is reasonable to=20 do extension in the working group owning the protocol. I agree on the = charter. However, DMM should work on documenting =E2=80=9Chow to use it=E2=80=9D. = The document should=20 be informational or experimental. Is this scope of DMM?=20 btw, you may add IDR in the listed of working group. thanks ryuji 2014/03/17 =E5=8D=88=E5=BE=8C3:41=E3=80=81Jouni Korhonen = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A > Folks, >=20 > I have updated the charter draft text slightly: > = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >=20 > Basically: >=20 > Added Sri's comment on PMIPv6 maintenance. > Added Alper's comment of location of mobility functions. > Added links to other IETF WGs on possible mobility enabling = technologies. > Added a comment that virtualised network functions are in scope. >=20 > - Jouni >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Mar 20 02:00:31 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E62B1A0691 for ; Thu, 20 Mar 2014 02:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cquNBvfSKjR8 for ; Thu, 20 Mar 2014 02:00:27 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 563391A034A for ; Thu, 20 Mar 2014 02:00:27 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id lj1so635219pab.8 for ; Thu, 20 Mar 2014 02:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+1e1pJKGL48qbTI377ZNa/jY5HySSmXZe0zx0ue62HI=; b=RmUiYDLPV+haHzzS+ZukNT+36uvuQHj7BeoK38/fsqd/PM4NHXzBgX+qB0lBMhFBGN Q0HOjvGyWazu25EKk9FlAxBiQFUg3o/wDEyXbqHpnqCb2yRpYww8HprhuPaLmWou6Vpx XJ66z63jkWaqLhfL4pVrbmzmit1F3PItvGIjNluyPvX82cLlp12tUD0cQXB16aJZ5uh1 Hp3wRnTmdxQHIgfJWuZ5niDFXWjKyw13Bpb/PJC0U7svGqDWfrnjTEQdqlMt5bHjcAsH GDXb5R7JzcstUWGv0FhCGgoQEibWNIpWTRoMTd02eTuoKDPrhjDAm1c4n19ZLj2tI+P4 AGbA== X-Received: by 10.66.228.37 with SMTP id sf5mr44784650pac.19.1395306018558; Thu, 20 Mar 2014 02:00:18 -0700 (PDT) Received: from dhcp-18-187.meeting.verilan.com ([123.124.234.161]) by mx.google.com with ESMTPSA id bc4sm2568264pbb.2.2014.03.20.02.00.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Mar 2014 02:00:17 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <21621_1395305092_532AAA84_21621_3808_1_81C77F07008CA24F9783A98CFD706F711420FCF1@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Thu, 20 Mar 2014 17:00:03 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <47C1CC71-67F1-4AC7-96AA-48BF37040C29@gmail.com> <1502BDF5-6189-4297-8479-05B3345AC96A@gmail.com> <0A1920BD-67A7-4ECF-9EF7-7789891CF3D3@yegin.org> <9044B3AD-E734-4483-B8D1-F0DA29455EBE@gmail.com> <67B1A3D6-A8BE-4D1E-BF2D-184487E9DBD2@yegin.org> <21621_1395305092_532AAA84_21621_3808_1_81C77F07008CA24F9783A98CFD706F711420FCF1@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: pierrick.seite@orange.com X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/HDOvjliqEdZMZhSL1X6_DiXehdk Cc: "dmm@ietf.org" Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 09:00:29 -0000 On Mar 20, 2014, at 4:44 PM, pierrick.seite@orange.com wrote: >=20 >=20 >> -----Message d'origine----- >> De : dmm [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin >> Envoy=E9 : jeudi 20 mars 2014 09:42 >> =C0 : Jouni Korhonen >> Cc : dmm@ietf.org >> Objet : Re: [DMM] re-charter text updated >>=20 >>=20 >> On Mar 20, 2014, at 10:30 AM, Jouni Korhonen wrote: >>=20 >>>=20 >>> On Mar 20, 2014, at 2:58 PM, Alper Yegin = wrote: >>>=20 >>>> Hi Jouni, >>>>=20 >>>> On Mar 20, 2014, at 6:03 AM, Jouni Korhonen wrote: >>>>>>=20 >>>>>>> o Mobility state exposing I-D. This would communication between >>>>>>> the end host and the network. Maybe also covering the missing >>>>>>> parts within the end host.. Are we OK with one I-D or how people >>>>>>> want to see this? >>>>>>> o .. >>>>>>>=20 >>>>>>=20 >>>>>> There's the API aspect on the terminal (one I-D), and there is = the >>>>>> MN-network interface ones (e.g., extending RA, DHCP, etc.) >>>>>=20 >>>>>=20 >>>>> So you want an API document? I have some reservations documenting = an >>>>> APIs as-is. Could this be an extension to RFC5014? I'd see this >>>>> approach feasible since there are even (partial) implementations = of >>>>> the RFC5014 in popular operating systems. >>>>>=20 >>>>=20 >>>> Yes, we are talking about extensions to source address selection = (RFC >> 5014). >>>=20 >>> Ack. >>>=20 >>>>=20 >>>>=20 >>>>> Then the subsequent thing. Each MN-NW interface would be one >>>>> document, if I understand the above comment correctly? Which = one(s) to >> do first? >>>>> ND or/and DHCP? >>>>>=20 >>>>=20 >>>> Yes. Both. >>>=20 >>> Ack. Since we are coming up with I-D numbers, any preference on the >>> protocols that we patch..? >>>=20 >>=20 >> between ND and DHCP? DHCP.. >>=20 >=20 > I'd say ND first :-)... but, anyway, do we really need two different = documents? Although, container differs, I guess extensions will be the = same. Second the ND thing ;) Why two docs.. DHCP is usually easy going as you can practically shove a = flock of pigeons into it and people are just fine. ND is always a = different story ;)=20 - JOuni >=20 >> Alper >>=20 >>=20 >>> - Jouni >>>=20 >>>=20 >>>>=20 >>>> Alper >>>>=20 >>>>=20 >>>>=20 >>>>> - JOuni >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Alper >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> - Jouni >>>>>>>=20 >>>>>>>=20 >>>>>>> On Mar 17, 2014, at 2:41 PM, Jouni Korhonen >> wrote: >>>>>>>=20 >>>>>>>> Folks, >>>>>>>>=20 >>>>>>>> I have updated the charter draft text slightly: >>>>>>>> https://github.com/jounikor/dmm-re- >> charter/blob/master/recharter_ >>>>>>>> draft.txt >>>>>>>>=20 >>>>>>>> Basically: >>>>>>>>=20 >>>>>>>> Added Sri's comment on PMIPv6 maintenance. >>>>>>>> Added Alper's comment of location of mobility functions. >>>>>>>> Added links to other IETF WGs on possible mobility enabling >> technologies. >>>>>>>> Added a comment that virtualised network functions are in = scope. >>>>>>>>=20 >>>>>>>> - Jouni >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> dmm mailing list >>>>>>> dmm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> 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, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 From nobody Thu Mar 20 02:22:45 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C4D1A08A0 for ; Thu, 20 Mar 2014 02:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsDnJnL_5axq for ; Thu, 20 Mar 2014 02:22:42 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E25F41A04F1 for ; Thu, 20 Mar 2014 02:22:41 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id w7so387539lbi.30 for ; Thu, 20 Mar 2014 02:22:32 -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-type; bh=zrXYZ47q9CmqBQL2lyHuzdAYafrmQelaHdanPNlHER0=; b=yxCRI+fa42X/d4jRkgnvmCy0fqFO8+PLX+JK1dMMI4Gb3/0Rs6wdz0PLCNsoDIvwWs sc+HVBASzxbIQOdlkSWrTmSYI0eM0dQzLVJbcKosJRUkGUx6QQp6g3hnumNx3gJbdepW mPvkTAmdJRgp++CZqX7SI2ljLv6wGHMwTT5JSSHk8lHpldoMp4v9RfvOascmN7wKBwit cUMn+9nKt00SP26w1840kLE+vID97Pm/jKd8zlkSgb2Ce4t02jsEhhDGW/2XHY8tgmUY 1f9TZw0fTBpsgcHISfLPephfRQni5XdvqRxYIh7MS6opld8L44kX0KrMypFkeiuUanle ITLw== MIME-Version: 1.0 X-Received: by 10.153.7.69 with SMTP id da5mr1021776lad.38.1395307352164; Thu, 20 Mar 2014 02:22:32 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Thu, 20 Mar 2014 02:22:32 -0700 (PDT) In-Reply-To: References: <47C1CC71-67F1-4AC7-96AA-48BF37040C29@gmail.com> Date: Thu, 20 Mar 2014 04:22:32 -0500 Message-ID: From: Behcet Sarikaya To: Ryuji Wakikawa Content-Type: multipart/alternative; boundary=001a11345630140dd104f5064fdf Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/-6RtSiSttkjBMLMlZ_c8Y5K0qWI Cc: "dmm@ietf.org" Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 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, 20 Mar 2014 09:22:44 -0000 --001a11345630140dd104f5064fdf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 Regards, Behcet On Thu, Mar 20, 2014 at 3:55 AM, Ryuji Wakikawa w= rote: > Jouni > > It=E2=80=99s good to see some room for non-MIP based solution in DMM;-) > > One clarification, the charter said following > > "Specifically, when solutions are not > based on IP mobility protocols, the DMM workingvgroup shall coopera= te > with other IETF working groups working on other technologies that > might allow the mobility of an end host. These working groups inclu= de > but are not limited to I2rs, Lisp, and Forces." > > If we need to extend existing non-MIP protocols, it is reasonable to > do extension in the working group owning the protocol. I agree on the > charter. > > However, DMM should work on documenting =E2=80=9Chow to use it=E2=80=9D. = The document > should > be informational or experimental. Is this scope of DMM? > > btw, you may add IDR in the listed of working group. > > thanks > ryuji > > > 2014/03/17 =E5=8D=88=E5=BE=8C3:41=E3=80=81Jouni Korhonen =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A > > > Folks, > > > > I have updated the charter draft text slightly: > > > https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.tx= t > > > > Basically: > > > > Added Sri's comment on PMIPv6 maintenance. > > Added Alper's comment of location of mobility functions. > > Added links to other IETF WGs on possible mobility enabling technologie= s. > > Added a comment that virtualised network functions are in scope. > > > > - Jouni > > > > _______________________________________________ > > 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 > --001a11345630140dd104f5064fdf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

Regards,

Behcet
=


On = Thu, Mar 20, 2014 at 3:55 AM, Ryuji Wakikawa <ryuji.wakikawa@gmail= .com> wrote:
Jouni

It=E2=80=99s good to see some room for non-MIP based solution in DMM;-)

One clarification, the charter said following

=C2=A0 =C2=A0 =C2=A0 "Specifically, when solutions are not
=C2=A0 =C2=A0 =C2=A0 based on IP mobility protocols, the DMM workingvgroup = shall cooperate
=C2=A0 =C2=A0 =C2=A0 with other IETF working groups working on other techno= logies that
=C2=A0 =C2=A0 =C2=A0 might allow the mobility of an end host. These working= groups include
=C2=A0 =C2=A0 =C2=A0 but are not limited to I2rs, Lisp, and Forces."
If we need to extend existing non-MIP protocols, it is reasonable to
do extension in the working group owning the protocol. I agree on the chart= er.

However, DMM should work on documenting =E2=80=9Chow to use it=E2=80=9D. = =C2=A0The document should
be informational or experimental. =C2=A0Is this scope of DMM?

btw, you may add IDR in the listed of working group.

thanks
ryuji


2014/03/17 =E5=8D=88=E5=BE=8C3:41=E3=80=81Jouni Korhonen <jouni.nospam@gmail.com> =E3=81=AE=E3=83= =A1=E3=83=BC=E3=83=AB=EF=BC=9A

> Folks,
>
> I have updated the charter draft text slightly:
> https://github.com/jounikor/dmm-re-chart= er/blob/master/recharter_draft.txt
>
> Basically:
>
> Added Sri's comment on PMIPv6 maintenance.
> Added Alper's comment of location of mobility functions.
> Added links to other IETF WGs on possible mobility enabling technologi= es.
> Added a comment that virtualised network functions are in scope.
>
> - Jouni
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

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

--001a11345630140dd104f5064fdf-- From nobody Thu Mar 20 02:25:59 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F211A0691 for ; Thu, 20 Mar 2014 02:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3s_2-QxCWNVd for ; Thu, 20 Mar 2014 02:25:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 53C0C1A03A7 for ; Thu, 20 Mar 2014 02:25:56 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 37F9C22C3BE; Thu, 20 Mar 2014 10:25:47 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 18FD227C06A; Thu, 20 Mar 2014 10:25:47 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Thu, 20 Mar 2014 10:25:46 +0100 From: To: Jouni Korhonen Thread-Topic: [DMM] re-charter text updated Thread-Index: AQHPQav8IqXuPPIWy06iKl9XwXGj+5rmDRGAgANSdVWAAB//AIAAGaeAgAADKICAABDkkP//9DyAgAAW2gA= Date: Thu, 20 Mar 2014 09:25:46 +0000 Message-ID: <24746_1395307547_532AB41B_24746_6394_1_81C77F07008CA24F9783A98CFD706F711420FD4F@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <47C1CC71-67F1-4AC7-96AA-48BF37040C29@gmail.com> <1502BDF5-6189-4297-8479-05B3345AC96A@gmail.com> <0A1920BD-67A7-4ECF-9EF7-7789891CF3D3@yegin.org> <9044B3AD-E734-4483-B8D1-F0DA29455EBE@gmail.com> <67B1A3D6-A8BE-4D1E-BF2D-184487E9DBD2@yegin.org> <21621_1395305092_532AAA84_21621_3808_1_81C77F07008CA24F9783A98CFD706F711420FCF1@PEXCVZYM12.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.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.20.50015 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/J_Mf8xiw9cYgLG9XpFNBiJDqY9c Cc: "dmm@ietf.org" Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 09:25:58 -0000 >-----Message d'origine----- >De=A0: Jouni Korhonen [mailto:jouni.nospam@gmail.com] >Envoy=E9=A0: jeudi 20 mars 2014 10:00 >=C0=A0: SEITE Pierrick IMT/OLN >Cc=A0: Alper Yegin; dmm@ietf.org >Objet=A0: Re: [DMM] re-charter text updated > > >On Mar 20, 2014, at 4:44 PM, pierrick.seite@orange.com wrote: > >> >> >>> -----Message d'origine----- >>> De : dmm [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin >>> Envoy=E9 : jeudi 20 mars 2014 09:42 =C0 : Jouni Korhonen Cc : >>> dmm@ietf.org Objet : Re: [DMM] re-charter text updated >>> >>> >>> On Mar 20, 2014, at 10:30 AM, Jouni Korhonen wrote: >>> >>>> >>>> On Mar 20, 2014, at 2:58 PM, Alper Yegin wrote: >>>> >>>>> Hi Jouni, >>>>> >>>>> On Mar 20, 2014, at 6:03 AM, Jouni Korhonen wrote: >>>>>>> >>>>>>>> o Mobility state exposing I-D. This would communication between >>>>>>>> the end host and the network. Maybe also covering the missing >>>>>>>> parts within the end host.. Are we OK with one I-D or how people >>>>>>>> want to see this? >>>>>>>> o .. >>>>>>>> >>>>>>> >>>>>>> There's the API aspect on the terminal (one I-D), and there is the >>>>>>> MN-network interface ones (e.g., extending RA, DHCP, etc.) >>>>>> >>>>>> >>>>>> So you want an API document? I have some reservations documenting >an >>>>>> APIs as-is. Could this be an extension to RFC5014? I'd see this >>>>>> approach feasible since there are even (partial) implementations of >>>>>> the RFC5014 in popular operating systems. >>>>>> >>>>> >>>>> Yes, we are talking about extensions to source address selection (RFC >>> 5014). >>>> >>>> Ack. >>>> >>>>> >>>>> >>>>>> Then the subsequent thing. Each MN-NW interface would be one >>>>>> document, if I understand the above comment correctly? Which one(s) >to >>> do first? >>>>>> ND or/and DHCP? >>>>>> >>>>> >>>>> Yes. Both. >>>> >>>> Ack. Since we are coming up with I-D numbers, any preference on the >>>> protocols that we patch..? >>>> >>> >>> between ND and DHCP? DHCP.. >>> >> >> I'd say ND first :-)... but, anyway, do we really need two different >documents? Although, container differs, I guess extensions will be the sam= e. > >Second the ND thing ;) > >Why two docs.. DHCP is usually easy going as you can practically shove a f= lock >of pigeons into it and people are just fine. ND is always a different stor= y ;) Ok, I got it... > >- JOuni > > > > >> >>> Alper >>> >>> >>>> - Jouni >>>> >>>> >>>>> >>>>> Alper >>>>> >>>>> >>>>> >>>>>> - JOuni >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Alper >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> - Jouni >>>>>>>> >>>>>>>> >>>>>>>> On Mar 17, 2014, at 2:41 PM, Jouni Korhonen >>> wrote: >>>>>>>> >>>>>>>>> Folks, >>>>>>>>> >>>>>>>>> I have updated the charter draft text slightly: >>>>>>>>> https://github.com/jounikor/dmm-re- >>> charter/blob/master/recharter_ >>>>>>>>> draft.txt >>>>>>>>> >>>>>>>>> Basically: >>>>>>>>> >>>>>>>>> Added Sri's comment on PMIPv6 maintenance. >>>>>>>>> Added Alper's comment of location of mobility functions. >>>>>>>>> Added links to other IETF WGs on possible mobility enabling >>> technologies. >>>>>>>>> Added a comment that virtualised network functions are in scope. >>>>>>>>> >>>>>>>>> - Jouni >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >> >> >___________________________________________________________ >___________________________________________________________ >___ >> >> Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu ce >message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme = ou >falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete >this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en >modified, changed or falsified. >> Thank you. >> ___________________________________________________________________________= ______________________________________________ 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 Thu Mar 20 03:29:17 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD941A08B3 for ; Thu, 20 Mar 2014 03:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDXb96wIvSAC for ; Thu, 20 Mar 2014 03:29:08 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id AFBA61A08AF for ; Thu, 20 Mar 2014 03:29:06 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id l18so433123wgh.19 for ; Thu, 20 Mar 2014 03:28:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=a+swIxsgAnZH4Wmr/F1/iS33qA4UZpCxB6bLRfuM0dM=; b=O01Asp5tW6OGl6NpEVcq1H/zfgDEzjd44uL5kfabaKsaRLrYZnExG/uB4sSLSglhgG 5DOsNWvu6WtUCGcnnLHZiRv3SknNv93rob9NfdHECy1phSxAMtuCJCNBULXbJn8l2r60 LTFBtYl6soUf6RiYiJSzScPePPH/QRy/fiKUNzVUAOHwWxgmWX6vYndZJ1GaRVIY3ZEI JejSfbDgVymtAKwSXk5By0/ShkkAtUj1ofBza8U3OmW3k+3BvY86XT7gE/vO5wuFlxaV CRqQpkiXT5pWOBWIeSJyMP8dIME5daibw9aRK/CovJI+0z54LnAjwsz1HrxNn/UVsc1i YRyQ== X-Gm-Message-State: ALoCoQmgzaB4/pK9l1WP45l+Mrp6GoQheB1ry7UouQGVgrYrVOTtuvveTflnLMnsiEjGr9/RvVzR X-Received: by 10.194.201.73 with SMTP id jy9mr6840958wjc.51.1395311337247; Thu, 20 Mar 2014 03:28:57 -0700 (PDT) Received: from [11.0.0.215] (sitivoip.ulusofona.pt. [193.137.75.156]) by mx.google.com with ESMTPSA id uq2sm3867452wjc.5.2014.03.20.03.28.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Mar 2014 03:28:56 -0700 (PDT) Message-ID: <532AC2E8.6010207@ulusofona.pt> Date: Thu, 20 Mar 2014 10:28:56 +0000 From: Rute Sofia Organization: COPELABS, ULHT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Weixinpeng References: <4657461.1395126539884.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> <7998EFA2-0203-4961-B290-F44E5814E3C6@yegin.org> <15533_1395140647_53282826_15533_3650_1_81C77F07008CA24F9783A98CFD706F711420EC3F@PEXCVZYM12.corporate.adroot.infra.ftgroup> <6979_1395146603_53283F6B_6979_768_1_8da19a47-f4d0-4410-bd96-0b54e482333a@PEXCVZYH01.corporate.adroot.infra.ftgroup> <11579_1395217879_532955D7_11579_7368_1_81C77F07008CA24F9783A98CFD706F711420F5EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> <53297ADD.9030905@ulusofona.pt> <48A6EA4F-543C-4898-9F87-3A49DB5360F8@yegin.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050400010605010908050204" Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/uBeN7Mg_xbm6B1EtD77YehaGNHc Cc: "Charlie P." , "dmm-chairs@tools.ietf.org" , "dmm@ietf.org" Subject: Re: [DMM] Where to place mobility functions X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: rute.sofia@ulusofona.pt List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 10:29:16 -0000 This is a multi-part message in MIME format. --------------050400010605010908050204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit agree also On 20-03-2014 01:26, Weixinpeng wrote: > > Agree, the mobility management specific terminology "MN" "CN" would be > more explicit than "user". > > *From:*Alper Yegin [mailto:alper.yegin@yegin.org] > *Sent:* Wednesday, March 19, 2014 8:39 PM > *To:* rute.sofia@ulusofona.pt > *Cc:* pierrick.seite@orange.com; Weixinpeng; Charlie P.; dmm@ietf.org; > dmm-chairs@tools.ietf.org > *Subject:* Re: [DMM] Where to place mobility functions WG next steps> > > Hello, > > It's best if we didn't use the term "user", especially if there is an > ambiguity about whether the user sits on the MN or CN or both. > > Let's use the terms MN and CN instead. > > Alper > > On Mar 19, 2014, at 1:09 PM, Rute Sofia wrote: > > > > Again, I think it is risky to mention optimal path or anything that > has to do with data path as this implies in-band signaling... > > Concerning the CN, I believe it would be enough to state "closer to > the user". > > The CN can be a MN or not. > > I would also like to alert that there are proposals for architectures > where indeed the closeness of the MAPs have been explored in the > context of "closer to the user". For instance, in the EU project ULOOP > (uloop.eu ), there is a coordination function > (signaling) that takes care of providing the "best" choice for a MAP > according with user preferences, roaming habits, as well as with > potential network policies. > > In another project (User-centric Mobility Management, > http://copelabs.ulusofona.pt/index.php/research/projects/past-projects/149-umm, > for results, papers and software) we have indeed worked solutions > which *split* the control functionality and MAPs, and analyzed the > possibility and advantages of placing it closer *to the user*. A MN or CN. > > So, the best solution which seems to suit the proposal by Pierrick as > well as solutions that already exist today is: closer to the user. Not > necessarily on the optimal *data* path. > > BR > Rute Sofia > > On 19-03-2014 08:31, pierrick.seite@orange.com > wrote: > > *De :*Weixinpeng [mailto:weixinpeng@huawei.com] > *Envoyé :* mercredi 19 mars 2014 03:13 > *À :* SEITE Pierrick IMT/OLN; Alper Yegin; Charlie P. > *Cc :* dmm@ietf.org ; dmm-chairs@tools.ietf.org > ; Xiongchunshan (Sam) > *Objet :* RE: [DMM] Where to place mobility functions next steps> > > HiPirrick, > > I agree with you that the anchoring location considerations should be > more generic. But for your suggested NEW TEXT, I think it's a bit of > ambiguous > > to say "closer to the optimal data path", and as my understanding what > DMM is trying to do is to eliminate sub-optimal routing path between > MN and CN, > > so if the anchor is just close to optimal data path, but not on the > optimal data path, it's not what DMM wants. So what's your opinion? > > [PS] it depends on what does "optimal path" mean; actually the > ambiguity may come from that term. If "optimal path" does not mean > the shortest path but "the best we can do", I can agree with you. > > Here is my suggested TEXT: > > by distributing forwarding functions at optimal location; for example, > closer either to the mobile user or the corresponding node. > > [PS] better J > > BR, > > Xinpeng > > *De :*dmm [mailto:dmm-bounces@ietf.org] *De la part de* > pierrick.seite@orange.com > *Envoyé :* mardi 18 mars 2014 12:04 > *À :* Alper Yegin; Charlie P.; Weixinpeng > *Cc :* dmm@ietf.org ; dmm-chairs@tools.ietf.org > > *Objet :* Re: [DMM] Where to place mobility functions next steps> > > Hello, > > Distributing mobility anchors closer either to the MN or CN are both > valid scenarios. But, maybe there are other optimal anchor location; > actually, here, we are seeking to reach optimal routing by placing the > anchor closer to the optimal data path. Also, we may also want to keep > a centralized anchor, for example, reachability purpose; in this case, > we could say that data path going via the central anchor is the "most" > optimal, because of the reachability constraint. In CP/DP > distributions scenarios, we may want to distribute DP function and > keep centralized some CP functions (e.g. billing... yes, operators > like this function J). > > So, I think that anchoring location considerations should be more > generic and should focus on datapath management. I'd suggest the > following rewording: > > ------- OLD TEXT ------------ > > by distributing mobility functions more closer to the user and/or its > corresponding nodes. > > ---------- NEW TEXT --------- > > by distributing forwarding functions more closer to the optimal data > path; for example, closer either to the mobile user or the > corresponding node. > > Pirrick > > *De :*dmm [mailto:dmm-bounces@ietf.org] *De la part de* Alper Yegin > *Envoyé :* mardi 18 mars 2014 10:19 > *À :* Charlie P.; Weixinpeng > *Cc :* dmm@ietf.org ; dmm-chairs@tools.ietf.org > > *Objet :* Re: [DMM] Where to place mobility functions next steps> > > Hello Xinpeng, > > In the legacy thinking, the mobility anchor is in the core network > (centrally-located HA). That's the basic Mobile IP design. > > Now people are also considering placing anchors in the access network. > > And then there's one more possibility, which is to place an anchor > near/on the corresponding node. > > Please see the Cnet-homing presentation for more: > http://www.ietf.org/proceedings/87/slides/slides-87-dmm-2.pdf > > Questions/comments welcome. > > Charlie: > > Yes, we cannot assume there'll be an anchor on/near every CN. Our > proposal takes that into account. > > In fact, today there's no anchor in every access network either. > There's basically none in any WiFi network today. > > Both situation is subject to change based on DMM developments. > > Alper > > On Mar 18, 2014, at 9:08 AM, Charlie P. wrote: > > Hello folks, > > One difference is that a mobile node is likely to be located in a > network that supports mobility, whereas the network hosting a general > CN may not have any mobility support features. > > Regards, > Charlie P. > > -----Original Message----- > From: Weixinpeng > Sent: Mar 17, 2014 11:59 PM > To: Alper Yegin, Jouni Korhonen > Cc: "dmm@ietf.org ", "dmm-chairs@tools.ietf.org > " > Subject: Re: [DMM] DMM WG next steps > > > Hi Alper, > > Is there any essential difference between placing the mobility > function closer to the user and placing > > the mobility function closer to the CN? I think in some sense the > user host and it's corresponding node are the same for mobility > management protocol. > > So what's the reason to distinguish between them? > > BR, > > xinpeng > > *From:*dmm [mailto:dmm-bounces@ietf.org]*On Behalf Of*Alper Yegin > *Sent:*Wednesday, March 05, 2014 9:04 PM > *To:*Jouni Korhonen > *Cc:*dmm@ietf.org ;dmm-chairs@tools.ietf.org > > *Subject:*Re: [DMM] DMM WG next steps > > Jouni, > > Thanks for the text. > > DMM can be used to realise such a distributed deployment > model, by distributing mobility functions more closer to the user. > > This part excludes the approaches that place the mobility function on > or near the CN. > > I recommend the following revision: > > DMM can be used to realise such a distributed deployment > model, by distributing mobility functions more closer to the user > and/or its corresponding nodes. > > Alper > > On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote: > > > > > Folks, > > DMM WG has done some progress lately. The requirements document has > already left the building and the gap analysis is heading to WGLC as > we speak. It is about the time to think what we should do next now > that we have grown out of the infancy. > > A smaller group of mobility enthusiasts have been discussing about > possible next steps and how the possible new charter would look like. > The current very draft text template can be found here: > https://github.com/jounikor/dmm-re-charter > > As you can see, we are still in early stages and all input it welcome. > Obviously, possible re-chartering depends on many things. For example, > things like getting the gap analysis out of the WG and what the IESG > says. Nothing has been fixed or decided yet. Anyhow, we will start the > discussion on re-chartering with the expectation that the DMM WG will > re-charter and continue developing new solutions and/or enhancements > in the IP mobility space. > > - Jouni & Dapeng > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > > > > -- > Best Regards/Melhores Cumprimentos/mit freundlichen Gruessen, > > Rute Sofia > .............................................. > COPELABS - Association for the Research and Development of Cognition and People-centric Computing > Direction > http://copelabs.ulusofona.pt > ......................................... > -- Best Regards/Melhores Cumprimentos/mit freundlichen Gruessen, Rute Sofia .............................................. COPELABS - Association for the Research and Development of Cognition and People-centric Computing Direction http://copelabs.ulusofona.pt ......................................... --------------050400010605010908050204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit agree also

On 20-03-2014 01:26, Weixinpeng wrote:

Agree, the mobility management specific terminology “MN” “CN” would be more explicit than “user”.

 

From: Alper Yegin [mailto:alper.yegin@yegin.org]
Sent: Wednesday, March 19, 2014 8:39 PM
To: rute.sofia@ulusofona.pt
Cc: pierrick.seite@orange.com; Weixinpeng; Charlie P.; dmm@ietf.org; dmm-chairs@tools.ietf.org
Subject: Re: [DMM] Where to place mobility functions <was, Re: DMM WG next steps>

 

Hello,

 

It's best if we didn't use the term "user", especially if there is an ambiguity about whether the user sits on the MN or CN or both.

Let's use the terms MN and CN instead.

 

 

Alper

 

 

 

On Mar 19, 2014, at 1:09 PM, Rute Sofia wrote:



Again, I think it is risky to mention optimal path or anything that has to do with data path as this implies in-band signaling...

Concerning the CN, I believe it would be enough to state "closer to the user".

The CN can be a MN or not.

I would also like to alert that there are proposals for architectures where indeed the closeness of the MAPs have been explored in the context of "closer to the user". For instance, in the EU project ULOOP (uloop.eu), there is a coordination function (signaling) that takes care of providing the "best" choice for a MAP according with user preferences, roaming habits, as well as with potential network policies.

In another project (User-centric Mobility Management, http://copelabs.ulusofona.pt/index.php/research/projects/past-projects/149-umm, for results, papers and software) we have indeed worked solutions which *split* the control functionality and MAPs, and analyzed the possibility and advantages of placing it closer *to the user*. A MN or CN.

So, the best solution which seems to suit the proposal by Pierrick as well as solutions that already exist today is: closer to the user. Not necessarily on the optimal *data* path.

BR
Rute Sofia

On 19-03-2014 08:31, pierrick.seite@orange.com wrote:

 

 

De : Weixinpeng [mailto:weixinpeng@huawei.com]
Envoyé : mercredi 19 mars 2014 03:13
À : SEITE Pierrick IMT/OLN; Alper Yegin; Charlie P.
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org; Xiongchunshan (Sam)
Objet : RE: [DMM] Where to place mobility functions <was, Re: DMM WG next steps>

 

Hi Pirrick,

I agree with you that the anchoring location considerations should be more generic. But for your suggested NEW TEXT, I think it’s a bit of ambiguous

to say “closer to the optimal data path”, and as my understanding what DMM is trying to do is to eliminate sub-optimal routing path between MN and CN,

so if the anchor is just close to optimal data path, but not on the optimal data path, it’s not what DMM wants. So what’s your opinion?

 

[PS] it depends on what does “optimal path” mean; actually the ambiguity may come from that term.  If “optimal path” does not mean the shortest path but “the best we can do”, I can agree with you.

 

 

Here is my suggested TEXT:

by distributing forwarding functions at optimal location; for example, closer either to the mobile user or the corresponding node.

 

[PS] better J

 

BR,

Xinpeng

 

 

De : dmm [mailto:dmm-bounces@ietf.org] De la part de pierrick.seite@orange.com
Envoyé : mardi 18 mars 2014 12:04
À : Alper Yegin; Charlie P.; Weixinpeng
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions <was, Re: DMM WG next steps>

 

Hello,

 

Distributing mobility anchors closer either to the MN or CN are both valid scenarios. But, maybe there are other optimal anchor location; actually, here, we are seeking to reach optimal routing by placing the anchor closer to the optimal data path. Also, we may also want to keep a centralized anchor, for example, reachability purpose; in this case, we could say that data path going via the central anchor is the “most” optimal, because of the reachability constraint. In CP/DP distributions scenarios, we may want to distribute DP function and keep centralized some CP functions (e.g. billing… yes, operators like this function J).

 

So, I think that anchoring location considerations should be more generic and should focus on datapath management. I’d suggest the following rewording:

 

------- OLD TEXT ------------

 

by distributing mobility functions more closer to the user and/or its corresponding nodes.

 

 

---------- NEW TEXT ---------

 

by distributing forwarding functions more closer to the optimal data path; for example, closer either to the mobile user or the corresponding node.

 

Pirrick

 

 

De : dmm [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin
Envoyé : mardi 18 mars 2014 10:19
À : Charlie P.; Weixinpeng
Cc : dmm@ietf.org; dmm-chairs@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions <was, Re: DMM WG next steps>

 

Hello Xinpeng,

 

In the legacy thinking, the mobility anchor is in the core network (centrally-located HA). That's the basic Mobile IP design.

Now people are also considering placing anchors in the access network.

And then there's one more possibility, which is to place an anchor near/on the corresponding node. 

 

Please see the Cnet-homing presentation for more: http://www.ietf.org/proceedings/87/slides/slides-87-dmm-2.pdf

 

Questions/comments welcome.

 

Charlie: 

 

Yes, we cannot assume there'll be an anchor on/near every CN. Our proposal takes that into account.

 

In fact, today there's no anchor in every access network either. There's basically none in any WiFi network today.

 

Both situation is subject to change based on DMM developments.

 

Alper

 

 

 

 

 

 

 

 

On Mar 18, 2014, at 9:08 AM, Charlie P. wrote:

 

Hello folks,

One difference is that a mobile node is likely to be located in a network that supports mobility, whereas the network hosting a general CN may not have any mobility support features.

Regards,
Charlie P.

-----Original Message----- 
From: Weixinpeng 
Sent: Mar 17, 2014 11:59 PM 
To: Alper Yegin , Jouni Korhonen 
Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" 
Subject: Re: [DMM] DMM WG next steps 


Hi Alper,

Is there any essential difference between placing the mobility function closer to the user  and placing

the mobility function closer to the CN?   I think in some sense the user host and it’s corresponding node are the same for mobility management protocol.

So what’s the reason to distinguish between them?

 

BR,

xinpeng

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin
Sent: Wednesday, March 05, 2014 9:04 PM
To: Jouni Korhonen
Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org
Subject: Re: [DMM] DMM WG next steps

 

Jouni,

 

Thanks for the text.

 

      DMM can be used to realise such a distributed deployment
      model, by distributing mobility functions more closer to the user.

 

 

This part excludes the approaches that place the mobility function on or near the CN.

 

I recommend the following revision:

 

 

      DMM can be used to realise such a distributed deployment
      model, by distributing mobility functions more closer to the user
      and/or its corresponding nodes.

 

Alper

 

 

 

 

 

 

On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote:




Folks,

DMM WG has done some progress lately. The requirements document has
already left the building and the gap analysis is heading to WGLC as
we speak. It is about the time to think what we should do next now
that we have grown out of the infancy. 

A smaller group of mobility enthusiasts have been discussing about
possible next steps and how the possible new charter would look like. 
The current very draft text template can be found here:
     https://github.com/jounikor/dmm-re-charter

As you can see, we are still in early stages and all input it welcome.
Obviously, possible re-chartering depends on many things. For example,
things like getting the gap analysis out of the WG and what the IESG
says. Nothing has been fixed or decided yet. Anyhow, we will start the
discussion on re-chartering with the expectation that the DMM WG will
re-charter and continue developing new solutions and/or enhancements
in the IP mobility space.

- Jouni & Dapeng

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

 

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
 
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm




-- 
Best Regards/Melhores Cumprimentos/mit freundlichen Gruessen,
 
Rute Sofia
..............................................
COPELABS - Association for the Research and Development of Cognition and People-centric Computing
Direction
http://copelabs.ulusofona.pt
.........................................

 



-- 
Best Regards/Melhores Cumprimentos/mit freundlichen Gruessen,

Rute Sofia
..............................................
COPELABS - Association for the Research and Development of Cognition and People-centric Computing
Direction
http://copelabs.ulusofona.pt
.........................................
--------------050400010605010908050204-- From nobody Thu Mar 20 05:54:44 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAA11A08C0 for ; Thu, 20 Mar 2014 05:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvmxTyWw6b04 for ; Thu, 20 Mar 2014 05:54:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E7BC21A072D for ; Thu, 20 Mar 2014 05:54:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BET66459; Thu, 20 Mar 2014 12:54:29 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 20 Mar 2014 12:54:11 +0000 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 20 Mar 2014 12:54:19 +0000 Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.182]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.03.0158.001; Thu, 20 Mar 2014 20:54:14 +0800 From: Peter McCann To: "pierrick.seite@orange.com" , Jouni Korhonen Thread-Topic: [DMM] re-charter text updated Thread-Index: AQHPQav8IqXuPPIWy06iKl9XwXGj+5rmDRGAgANSdVWAAB//AIAAGaeAgAADKICAABDkkP//9DyAgAAW2gCAADqJAA== Date: Thu, 20 Mar 2014 12:54:13 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE753D9E6C4@szxeml522-mbx.china.huawei.com> References: <47C1CC71-67F1-4AC7-96AA-48BF37040C29@gmail.com> <1502BDF5-6189-4297-8479-05B3345AC96A@gmail.com> <0A1920BD-67A7-4ECF-9EF7-7789891CF3D3@yegin.org> <9044B3AD-E734-4483-B8D1-F0DA29455EBE@gmail.com> <67B1A3D6-A8BE-4D1E-BF2D-184487E9DBD2@yegin.org> <21621_1395305092_532AAA84_21621_3808_1_81C77F07008CA24F9783A98CFD706F711420FCF1@PEXCVZYM12.corporate.adroot.infra.ftgroup> <24746_1395307547_532AB41B_24746_6394_1_81C77F07008CA24F9783A98CFD706F711420FD4F@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <24746_1395307547_532AB41B_24746_6394_1_81C77F07008CA24F9783A98CFD706F711420FD4F@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.140] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/bBMdGArk6qoVPGNaGCiuKCL5oog Cc: "dmm@ietf.org" Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 12:54:42 -0000 I think our extensions should be to the prefix information option and not D= HCP. The properties of an address may change after a handover and we should not = couple the DHCP state machine (which is about lease renewal) to the handover state= machine. -Pete pierrick.seite@orange.com wrote: >=20 >=20 >> -----Message d'origine----- >> De=A0: Jouni Korhonen [mailto:jouni.nospam@gmail.com] Envoy=E9=A0: jeudi= 20 >> mars 2014 10:00 =C0=A0: SEITE Pierrick IMT/OLN Cc=A0: Alper Yegin; >> dmm@ietf.org Objet=A0: Re: [DMM] re-charter text updated >>=20 >>=20 >> On Mar 20, 2014, at 4:44 PM, pierrick.seite@orange.com wrote: >>=20 >>>=20 >>>=20 >>>> -----Message d'origine----- >>>> De : dmm [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin >>>> Envoy=E9 : jeudi 20 mars 2014 09:42 =C0 : Jouni Korhonen Cc : >>>> dmm@ietf.org Objet : Re: [DMM] re-charter text updated >>>>=20 >>>>=20 >>>> On Mar 20, 2014, at 10:30 AM, Jouni Korhonen wrote: >>>>=20 >>>>>=20 >>>>> On Mar 20, 2014, at 2:58 PM, Alper Yegin >>>>> wrote: >>>>>=20 >>>>>> Hi Jouni, >>>>>>=20 >>>>>> On Mar 20, 2014, at 6:03 AM, Jouni Korhonen wrote: >>>>>>>>=20 >>>>>>>>> o Mobility state exposing I-D. This would communication between >>>>>>>>> the end host and the network. Maybe also covering the missing >>>>>>>>> parts within the end host.. Are we OK with one I-D or how people >>>>>>>>> want to see this? o .. >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> There's the API aspect on the terminal (one I-D), and there is >>>>>>>> the MN-network interface ones (e.g., extending RA, DHCP, etc.) >>>>>>>=20 >>>>>>>=20 >>>>>>> So you want an API document? I have some reservations > documenting >> an >>>>>>> APIs as-is. Could this be an extension to RFC5014? I'd see this >>>>>>> approach feasible since there are even (partial) >>>>>>> implementations of the RFC5014 in popular operating systems. >>>>>>>=20 >>>>>>=20 >>>>>> Yes, we are talking about extensions to source address selection >>>>>> (RFC >>>> 5014). >>>>>=20 >>>>> Ack. >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> Then the subsequent thing. Each MN-NW interface would be one >>>>>>> document, if I understand the above comment correctly? Which >>>>>>> one(s) >> to >>>> do first? >>>>>>> ND or/and DHCP? >>>>>>>=20 >>>>>>=20 >>>>>> Yes. Both. >>>>>=20 >>>>> Ack. Since we are coming up with I-D numbers, any preference on the >>>>> protocols that we patch..? >>>>>=20 >>>>=20 >>>> between ND and DHCP? DHCP.. >>>>=20 >>>=20 >>> I'd say ND first :-)... but, anyway, do we really need two > different >> documents? Although, container differs, I guess extensions will be the >> same. >>=20 >> Second the ND thing ;) >>=20 >> Why two docs.. DHCP is usually easy going as you can practically >> shove a flock of pigeons into it and people are just fine. ND is >> always a different story ;) >=20 > Ok, I got it... >=20 >>=20 >> - JOuni >>=20 >>=20 >>=20 >>=20 >>>=20 >>>> Alper >>>>=20 >>>>=20 >>>>> - Jouni >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Alper >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> - JOuni >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Alper >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> - Jouni >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Mar 17, 2014, at 2:41 PM, Jouni Korhonen >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Folks, >>>>>>>>>>=20 >>>>>>>>>> I have updated the charter draft text slightly: >>>>>>>>>> https://github.com/jounikor/dmm-re- >>>>>>>>>> charter/blob/master/recharter_ draft.txt >>>>>>>>>>=20 >>>>>>>>>> Basically: >>>>>>>>>>=20 >>>>>>>>>> Added Sri's comment on PMIPv6 maintenance. Added Alper's >>>>>>>>>> comment of location of mobility functions. Added links to other >>>>>>>>>> IETF WGs on possible mobility enabling technologies. Added a >>>>>>>>>> comment that virtualised network functions are in scope. >>>>>>>>>>=20 >>>>>>>>>> - Jouni >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> dmm mailing list >>>>>>>>> dmm@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> dmm mailing list >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >>>=20 >>>=20 >> ___________________________________________________________ >> ___________________________________________________________ >> ___ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >>> que les pieces jointes. Les messages electroniques etant susceptibles >>> d'alteration, Orange decline toute responsabilite si ce message a ete >>> altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not >>> be distributed, used or copied without authorisation. If you have >>> received this email in error, please notify the sender and delete this >>> message and its attachments. As emails may be altered, Orange is not >>> liable for messages that have been modified, changed or falsified. >>> Thank you. >>>=20 >=20 >=20 > ______________________________________________________________________ _ > __________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > que les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Mar 20 11:55:54 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419D31A074E for ; Thu, 20 Mar 2014 11:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbglKOJPkO7p for ; Thu, 20 Mar 2014 11:55:47 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 247241A08FE for ; Thu, 20 Mar 2014 11:55:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s2KItY74023687; Thu, 20 Mar 2014 13:55:34 -0500 Received: from XCH-PHX-209.sw.nos.boeing.com (xch-phx-209.sw.nos.boeing.com [130.247.25.29]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s2KItN3a022999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 20 Mar 2014 13:55:24 -0500 Received: from XCH-BLV-408.nw.nos.boeing.com (2002:82f7:19a6::82f7:19a6) by XCH-PHX-209.sw.nos.boeing.com (2002:82f7:191d::82f7:191d) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 20 Mar 2014 11:55:22 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.87]) by XCH-BLV-408.nw.nos.boeing.com ([169.254.8.139]) with mapi id 14.03.0174.001; Thu, 20 Mar 2014 11:55:22 -0700 From: "Templin, Fred L" To: "sarikaya@ieee.org" Thread-Topic: AERO draft (was: RE: [DMM] DMM WG next steps) Thread-Index: AQHPRG3ynLa+RH0pcUCk8QHG74t9+Q== Date: Thu, 20 Mar 2014 18:55:22 +0000 Message-ID: <2134F8430051B64F815C691A62D98318206C30@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983181EC042@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831820153C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983182022DA@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D98318206C30XCHBLV504nwnosboe_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/ubw1ohWCyzTbQijcfy7Fd0Vc-Ic Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: [DMM] AERO draft (was: RE: DMM WG next steps) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 18:55:52 -0000 --_000_2134F8430051B64F815C691A62D98318206C30XCHBLV504nwnosboe_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI, Here is a link to the AERO draft, which fits as a non-MIP DMM solution: https://datatracker.ietf.org/doc/draft-templin-aerolink/ Again, anyone with interest in host- and network mobility management as well as DMM should be interested in reading and commenting on this draft. Thanks - Fred fred.l.templin@boeing.com From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] Sent: Wednesday, March 19, 2014 6:00 PM To: Templin, Fred L Cc: Jouni Korhonen; dmm@ietf.org; dmm-chairs@tools.ietf.org Subject: Re: [DMM] DMM WG next steps I could not see any link to AERO draft? Behcet On Tue, Mar 18, 2014 at 10:03 AM, Templin, Fred L > wrote: Hi Behcet, How do you mean to submit it as a solution draft to dmm? That is essentiall= y what I am already proposing. Thanks - Fred From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] Sent: Monday, March 17, 2014 5:37 PM To: Templin, Fred L Cc: Jouni Korhonen; dmm@ietf.org; dmm-chairs@tools.iet= f.org Subject: Re: [DMM] DMM WG next steps Hi Fred, Why don't you submit it as a solution draft to dmm? Then you can push for your draft instead of arguing for something that we d= on't know what. Regards, Behcet On Mon, Mar 17, 2014 at 1:31 PM, Templin, Fred L > wrote: Hi Jouni, > -----Original Message----- > From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] > Sent: Saturday, March 15, 2014 9:04 PM > To: Templin, Fred L > Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org > Subject: Re: [DMM] DMM WG next steps > > Fred, > > On Mar 11, 2014, at 11:48 PM, "Templin, Fred L" > wrote: > > > Hi Jouni, > > > > I think AERO fits paragraph 3 of the proposed new charter. AERO is a > > mobility solution for IPv6, where each node gets at least a /64. It > > has in-built route optimization, and can run over either IPv6 or IPv4 > > networks as a "link layer" for mobility. AERO expects a distributed > > mobility management environment, where a network of servers and > > relays keeps track of mobile node locations without single point > > of failure concerns. > > > > AERO is somewhat like MIPv6, but differs in that it treats the > > underlying network as a link-layer for IPv6 using a non-broadcast > > multiple access (NBMA) interface model. AERO uses IPv6 ND messaging > > and the IPv6 neighbor cache on the AERO "link" instead of MIPv6 > > mechanisms, and uses DHCPv6 PD exchanges instead of RS/RA for mobile > > node coordinations. The mobile nodes can therefore act as mobile > > routers and can provide stable network access for their connected > > networks (where each mobile node and its connected networks is > > a "site"). > > > > Here is a pointer to the spec. Please have a look and let me know > > what you think, > > There has been zero prior discussion or activity on this > topic in DMM that I recall. Furthermore, the current draft > seems to be a bis of RFC6707, driven by a single individual > and quite far in the preparation so I do not see a reason > involving this into the WG work. AERO is about mobility in general and distributed mobility management in particular. It also provides a solution to the route optimization problem cited in RFC5522 (which came from MEXT). AERO should be of interest to anyone interested in network mobilitiy, route optimization and distributed mobility management. IMHO, it is a better way of doing things than prior methods and this group would do well to consider it. Thanks - Fred fred.l.templin@boeing.com > - JOuni > > > > > > https://datatracker.ietf.org/doc/draft-templin-aerolink/ > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: dmm [mailto:dmm-bounces@ietf.org] O= n Behalf Of Jouni Korhonen > >> Sent: Wednesday, March 05, 2014 2:10 AM > >> To: dmm@ietf.org > >> Cc: dmm-chairs@tools.ietf.org > >> Subject: [DMM] DMM WG next steps > >> > >> Folks, > >> > >> DMM WG has done some progress lately. The requirements document has > >> already left the building and the gap analysis is heading to WGLC as > >> we speak. It is about the time to think what we should do next now > >> that we have grown out of the infancy. > >> > >> A smaller group of mobility enthusiasts have been discussing about > >> possible next steps and how the possible new charter would look like. > >> The current very draft text template can be found here: > >> https://github.com/jounikor/dmm-re-charter > >> > >> As you can see, we are still in early stages and all input it welcome. > >> Obviously, possible re-chartering depends on many things. For example, > >> things like getting the gap analysis out of the WG and what the IESG > >> says. Nothing has been fixed or decided yet. Anyhow, we will start the > >> discussion on re-chartering with the expectation that the DMM WG will > >> re-charter and continue developing new solutions and/or enhancements > >> in the IP mobility space. > >> > >> - 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 --_000_2134F8430051B64F815C691A62D98318206C30XCHBLV504nwnosboe_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HI,

 <= /p>

Here is a link to the AER= O draft, which fits as a non-MIP DMM solution:

 <= /p>

https://datatracker.ietf.org/do= c/draft-templin-aerolink/

 <= /p>

Again, anyone with intere= st in host- and network mobility management as

well as DMM should be int= erested in reading and commenting on this draft.

 <= /p>

Thanks – Fred<= /o:p>

fred.l.templin@boeing.com=

 <= /p>

From: Behcet S= arikaya [mailto:sarikaya2012@gmail.com]
Sent: Wednesday, March 19, 2014 6:00 PM
To: Templin, Fred L
Cc: Jouni Korhonen; dmm@ietf.org; dmm-chairs@tools.ietf.org
Subject: Re: [DMM] DMM WG next steps

 

I could not see any l= ink to AERO draft?

Behcet

 

On Tue, Mar 18, 2014 at 10:03 AM, Templin, Fred L &l= t;Fred.L.Tem= plin@boeing.com> wrote:

Hi Behcet,

 

How do you mean to submit it as a solut= ion draft to dmm? That is essentially

what I am already proposing.

 

Thanks - Fred

 

From: Behcet Sarikaya [mailt= o:sarikaya2012@= gmail.com]
Sent: Monday, March 17, 2014 5:37 PM
To: Templin, Fred L
Cc: Jouni Korhonen; dmm@ietf.org; dmm-chairs@t= ools.ietf.org


Subject: Re: [DMM] DMM WG next steps

 

Hi Fred,

Why don't you submit it as a solution draft to dmm?

Then you can push for your draft instead of arguing for something that w= e don't know what.

Regards,

Behcet

 

On Mon, Mar 17, 2014 at 1:31 PM, Templin, Fred L <Fred.L.Templin@boeing.com= > wrote:

Hi Jouni,


> -----Original Message-----
> From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]
> Sent: Saturday, March 15, 2014 9:04 PM
> To: Templin, Fred L
> Cc: dmm@ietf.org= ; dmm-chairs@tools.ietf.org
> Subject: Re: [DMM] DMM WG next steps
>
> Fred,
>
> On Mar 11, 2014, at 11:48 PM, "Templin, Fred L" <Fred.L.Templin@boei= ng.com> wrote:
>
> > Hi Jouni,
> >
> > I think AERO fits paragraph 3 of the proposed new charter. AERO i= s a
> > mobility solution for IPv6, where each node gets at least a /64. = It
> > has in-built route optimization, and can run over either IPv6 or = IPv4
> > networks as a "link layer" for mobility. AERO expects a= distributed
> > mobility management environment, where a network of servers and > > relays keeps track of mobile node locations without single point<= br> > > of failure concerns.
> >
> > AERO is somewhat like MIPv6, but differs in that it treats the > > underlying network as a link-layer for IPv6 using a non-broadcast=
> > multiple access (NBMA) interface model. AERO uses IPv6 ND messagi= ng
> > and the IPv6 neighbor cache on the AERO "link" instead = of MIPv6
> > mechanisms, and uses DHCPv6 PD exchanges instead of RS/RA for mob= ile
> > node coordinations. The mobile nodes can therefore act as mobile<= br> > > routers and can provide stable network access for their connected=
> > networks (where each mobile node and its connected networks is > > a "site").
> >
> > Here is a pointer to the spec. Please have a look and let me know=
> > what you think,
>
> There has been zero prior discussion or activity on this
> topic in DMM that I recall. Furthermore, the current draft
> seems to be a bis of RFC6707, driven by a single individual
> and quite far in the preparation so I do not see a reason
> involving this into the WG work.

AERO is about mobility in general and distributed mobility managem= ent
in particular. It also provides a solution to the route optimization
problem cited in RFC5522 (which came from MEXT).

AERO should be of interest to anyone interested in network mobilitiy,
route optimization and distributed mobility management. IMHO, it is
a better way of doing things than prior methods and this group would
do well to consider it.

Thanks - Fred
fred.l.templ= in@boeing.com


> - JOuni
>
>
> >
> > https://datatracker.ietf.org/doc/draft-templin-aerolink/
> >
> > Thanks - Fred
> > fr= ed.l.templin@boeing.com
> >
> >> -----Original Message-----
> >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen
> >> Sent: Wednesday, March 05, 2014 2:10 AM
> >> To: dmm@iet= f.org
> >> Cc: dmm-chairs@tools.ietf.org
> >> Subject: [DMM] DMM WG next steps
> >>
> >> Folks,
> >>
> >> DMM WG has done some progress lately. The requirements docume= nt has
> >> already left the building and the gap analysis is heading to = WGLC as
> >> we speak. It is about the time to think what we should do nex= t now
> >> that we have grown out of the infancy.
> >>
> >> A smaller group of mobility enthusiasts have been discussing = about
> >> possible next steps and how the possible new charter would lo= ok like.
> >> The current very draft text template can be found here:
> >>    https://github.com/jounikor/dmm-re-charter
> >>
> >> As you can see, we are still in early stages and all input it= welcome.
> >> Obviously, possible re-chartering depends on many things. For= example,
> >> things like getting the gap analysis out of the WG and what t= he IESG
> >> says. Nothing has been fixed or decided yet. Anyhow, we will = start the
> >> discussion on re-chartering with the expectation that the DMM= WG will
> >> re-charter and continue developing new solutions and/or enhan= cements
> >> in the IP mobility space.
> >>
> >> - Jouni & Dapeng
> >>
> >> _______________________________________________
> >> dmm mailing list
> >> dmm@ietf.or= g
> >> https://www.ietf.org/mailman/listinfo/dmm

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

 

 

--_000_2134F8430051B64F815C691A62D98318206C30XCHBLV504nwnosboe_-- From nobody Thu Mar 20 14:30:40 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34EF1A042C for ; Thu, 20 Mar 2014 14:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOSARO9xOxRg for ; Thu, 20 Mar 2014 14:30:36 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 08B0A1A08EB for ; Thu, 20 Mar 2014 14:30:36 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0Ln8PF-1X34to0TwT-00hBpE; Thu, 20 Mar 2014 17:30:26 -0400 From: Alper Yegin Content-Type: multipart/alternative; boundary="Apple-Mail=_C1BAEB1C-D896-4AA9-985D-0FF0A4F4D1FB" Date: Thu, 20 Mar 2014 23:30:23 +0200 Message-Id: <8B650D22-6089-4D1C-B499-C5E8DF6909AD@yegin.org> To: dmm@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:K2v8d3773J6BX3+FNKb1jifn0iTS/zGEiP+TtwN9RDT u8TvZk6hhdKUSja7KrGK4M5H34mp84deevqP4fDqWjmLGG9pRb osLCsjCgNMui8+WK2mKjC0Z2Hd/rpJmqChNAhzM0eP4NKCxdSJ ihHRRTHXJ0S1gRdSX9KEmVC9fzJ41mukqKYSenutmF4+C8sOrM qdRQWDFYkrywlTP5LkufOqBHPYpVsY4aDsGi58jAI/B0cxreTN AMdNFZc6cMap7xSx8n8yJC77APslRWDVO0jXKWcLU0MWSk7QMV xOmo69Xwd0Lp9JacajW3Qix6tomMs/f+qNaOzn4oIg+SvwXkmq /TNGK4mu7q6DiFez0Ne0mIorwFv3tZlqj35Nn98WhvGyhfeO36 CO5ZPK+0cSjqw== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/bdPfrTphvzOzbz40H_TwZZO_DIQ Subject: [DMM] Next-Gen Mobility Protocols and Architectures Webex calls... X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 21:30:38 -0000 --Apple-Mail=_C1BAEB1C-D896-4AA9-985D-0FF0A4F4D1FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello folks, Remember I was proposing to have conference calls for people to present = their proposals and have discussions around them.=20 Having more discussions would help us make better progress, not only = within DMM or other WGs in IETF, but even in larger scale in the = industry. Now I'm taking an initiative to start these calls=85. The objective is to facilitate discussions around next generation = mobility protocols and architectures. The scope is not limited to DMM. In other words, it is OK to discuss = work that falls outside the scope of DMM (NETEXT, MIF, etc=85.) Calls will be open to anyone. Feel free to forward this message to = others=85 These will be only for informational discussions, we'll not be seeking = any decisions=85 The idea is to provide sufficient time for people to explain their ideas = properly, and others to have a chance to fully understand them and give = feedback. =85 We'll start with the presentation of vEPC from Ryuji. We determined 3 dates for this first call. Please go on the Doodle and = register which one(s) work for you. Based on that we'll determine the Webex call date. http://doodle.com/y87dk2kpt8rcbwpz Make sure to enter your selections no later than the end of next Monday. Cheers, Alper --Apple-Mail=_C1BAEB1C-D896-4AA9-985D-0FF0A4F4D1FB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 http://doodle.com/y87dk2kpt8rc= bwpz


Make sure to enter your = selections no later than the end of next = Monday.


Cheers,

Alper


= --Apple-Mail=_C1BAEB1C-D896-4AA9-985D-0FF0A4F4D1FB-- From nobody Thu Mar 20 15:58:44 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F53B1A0930 for ; Thu, 20 Mar 2014 15:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SbWO0aIKBDR for ; Thu, 20 Mar 2014 15:58:42 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id F17791A031B for ; Thu, 20 Mar 2014 15:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=862; q=dns/txt; s=iport; t=1395356313; x=1396565913; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=V5QYgjeUY+6AcR6o5Ue1kZGNk/7JR9aKNTScSbcKqtY=; b=LkA1c+HLudjoGsZpkarS1Gx6n+7zgOhOykm7leTNW6ZTvqTQ4Vai69xQ 1yf8fkHEgtaLtV0OARnJShjrRXbYhRZduUVQU6Zm2sWlr3+x6pwSnugd8 EVFcWOWAngmRjHoddSTAngLLWcWkVSbluw9vBuIyiPJ0ffiDja4H9PsXm o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAIFxK1OtJV2c/2dsb2JhbABZgwaBEsJQgRMWdIIsOj8SAQg2QiUCBAENBYd5z3kXjmUHAoQ2AQOYR5Iwgy2CKw X-IronPort-AV: E=Sophos;i="4.97,698,1389744000"; d="scan'208";a="311784405" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 20 Mar 2014 22:58:32 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2KMwWdn028076 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Mar 2014 22:58:32 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.56]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Thu, 20 Mar 2014 17:58:32 -0500 From: "Sri Gundavelli (sgundave)" To: Peter McCann , "pierrick.seite@orange.com" , Jouni Korhonen Thread-Topic: [DMM] re-charter text updated Thread-Index: AQHPRI/qXTH28/A+L0GK841ydgGA8A== Date: Thu, 20 Mar 2014 22:58:32 +0000 Message-ID: In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE753D9E6C4@szxeml522-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.211] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/S2l0v5wVYvELL7lb4AfvTSJpkYc Cc: "dmm@ietf.org" Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 22:58:43 -0000 On 3/20/14 5:54 AM, "Peter McCann" wrote: >I think our extensions should be to the prefix information option and not >DHCP. > >The properties of an address may change after a handover and we should >not couple >the DHCP state machine (which is about lease renewal) to the handover >state machine. Hi Pete, This is a good comment. If we are making any assumption that even after a handover, the DHCP transactions are still hitting the same DHCP server node, this may be a valid concern. But, if DHCP transactions are locally terminated after handover (Ex: RFC5844/MAG), then the updated properties can be provided as part of the new DHCP transaction. Some parameters such as MTU settings do change after an handover and so we can probably agree that address properties can change as well. Regards Sri From nobody Thu Mar 20 17:37:21 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7A81A0850 for ; Thu, 20 Mar 2014 17:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmRqWZor-LwG for ; Thu, 20 Mar 2014 17:37:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA001A0809 for ; Thu, 20 Mar 2014 17:37:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEU08419; Fri, 21 Mar 2014 00:37:08 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Mar 2014 00:36:50 +0000 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Mar 2014 00:37:07 +0000 Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.182]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.03.0158.001; Fri, 21 Mar 2014 08:37:02 +0800 From: Peter McCann To: "Sri Gundavelli (sgundave)" , "pierrick.seite@orange.com" , Jouni Korhonen Thread-Topic: [DMM] re-charter text updated Thread-Index: AQHPQav8IqXuPPIWy06iKl9XwXGj+5rmDRGAgANSdVWAAB//AIAAGaeAgAADKICAABDkkP//9DyAgAAW2gCAADqJAIAAI4kAgAChH2A= Date: Fri, 21 Mar 2014 00:37:01 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE753D9E9D8@szxeml522-mbx.china.huawei.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE753D9E6C4@szxeml522-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/PJJV5ZwEWUswLyyIjG_wK_tedVU Cc: "dmm@ietf.org" Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 00:37:20 -0000 Hi, Sri, Sri Gundavelli (sgundave) wrote: >=20 >=20 >=20 >=20 > On 3/20/14 5:54 AM, "Peter McCann" wrote: >=20 >> I think our extensions should be to the prefix information option and >> not DHCP. >>=20 >> The properties of an address may change after a handover and we should >> not couple the DHCP state machine (which is about lease renewal) to the >> handover state machine. >=20 > Hi Pete, >=20 > This is a good comment. If we are making any assumption that even > after a handover, the DHCP transactions are still hitting the same > DHCP server node, this may be a valid concern. But, if DHCP > transactions are locally terminated after handover (Ex: RFC5844/MAG), > then the updated properties can be provided as part of the new DHCP > transaction. Some parameters such as MTU settings do change after an > handover and so we can probably agree that address properties can change = as well. >=20 >=20 > Regards > Sri I really don't think we should force DHCP to re-run on every handover. I t= hought one of the motivations for network-based mobility was to minimize the signa= ling to the MN during handover. -Pete From nobody Thu Mar 20 23:21:51 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF7E1A092C for ; Thu, 20 Mar 2014 23:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjrGNqo_g7ek for ; Thu, 20 Mar 2014 23:21:46 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1F99F1A088D for ; Thu, 20 Mar 2014 23:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3368; q=dns/txt; s=iport; t=1395382897; x=1396592497; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=TjBxE8+fisCztuVW+y0/8KvIroi6Z3JhkDI5dteQVtY=; b=CxCS5Y1tN9pgwBmz9sOCVcnnT3Y9YeIZ/JxAN0w2lUPpyS5QoeLNHUx9 sJ92dDwnrZwCOR7rrZXtUMwUPMYOWCyh49YWutM5iTxQPk8CgkZG/BbHF HwMFNhX1B3r5LPTMsiiatmLRc7mxMKPxZG53UauohBQ6BENQ7cy0db9s2 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFACDZK1OtJXG//2dsb2JhbABZgwaBEsJQgRIWdIIlAQEBAwE6OAcFDQEIGB5CJQIEAQ0Fh3EIz2kXjmUHAoQ2AQOYSZIxgy2BayQc X-IronPort-AV: E=Sophos;i="4.97,702,1389744000"; d="scan'208";a="311832942" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 21 Mar 2014 06:21:36 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2L6La0x024414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 06:21:36 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.56]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 01:21:35 -0500 From: "Sri Gundavelli (sgundave)" To: Peter McCann , "pierrick.seite@orange.com" , Jouni Korhonen Thread-Topic: [DMM] re-charter text updated Thread-Index: AQHPRM3PA4PmxLrkr0q6czVDxvJopA== Date: Fri, 21 Mar 2014 06:21:35 +0000 Message-ID: In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE753D9E9D8@szxeml522-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.211] Content-Type: text/plain; charset="us-ascii" Content-ID: <317AC426196DC94DA73CC48FDB6D1D03@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/ghz6_x0gsreAK25JtbTZ6wkEvNQ Cc: "dmm@ietf.org" Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 06:21:48 -0000 Hi Pete, > I really don't think we should force DHCP to re-run on every handover. >I thought one of the motivations for network-based mobility was to >minimize the signaling to the MN during handover. In the current mobility models we have two DHCP deployment models. a.) DHCP server in the access. b.) DHCP Relay in the access For #a, it is the dominant model. The DHCP server is collocated on the access gateway; the interworking between the DHCP server and the mobility function in the access gateway allows the network to offer the same IP address to the mobile node. After each handoff and based on DNA considerations, the MN may go into DHCP INIT-REBOOT followed by Request/reply. I don't know if I should call this as complete Re-Run after each handoff, but at least the current data suggests the handoff latency related to this same-link validation is insignificant. Now, from coloring perspective, the DHCP server in the access network can potentially change the properties of the address. MN is on a new world, new access network, new link and hence some changes to the properties. For #b, we continue to route the DHCP lease renewal messages back to the network where the MN obtained its address. Typically its tunneled to the anchor. Here I see your point of not impacting the DHCP state machine by changing properties based on MN's movement. But, if the DHCP server is aware of changes to properties, can it not send the updated properties ? We have to look at properties as meta-data that goes with an IP address/prefix. This meta-data should not have any relation to the DHCP state machine. But, some properties of that address do change, based on MN's movement, mobility state changes ..etc. If the DHCP server is aware of these property change, IMO, it should reflect the updated properties. I'm more interested in #a and not deal with this issue at all. But, if we insert a property element in PIO, we should do that consistently and have that in DHCP as well. Regards Sri =20 =20 On 3/20/14 5:37 PM, "Peter McCann" wrote: >Hi, Sri, > >Sri Gundavelli (sgundave) wrote: >>=20 >>=20 >>=20 >>=20 >> On 3/20/14 5:54 AM, "Peter McCann" wrote: >>=20 >>> I think our extensions should be to the prefix information option and >>> not DHCP. >>>=20 >>> The properties of an address may change after a handover and we should >>> not couple the DHCP state machine (which is about lease renewal) to the >>> handover state machine. >>=20 >> Hi Pete, >>=20 >> This is a good comment. If we are making any assumption that even >> after a handover, the DHCP transactions are still hitting the same >> DHCP server node, this may be a valid concern. But, if DHCP >> transactions are locally terminated after handover (Ex: RFC5844/MAG), >> then the updated properties can be provided as part of the new DHCP >> transaction. Some parameters such as MTU settings do change after an >> handover and so we can probably agree that address properties can >>change as well. >>=20 >>=20 >> Regards >> Sri > >I really don't think we should force DHCP to re-run on every handover. I >thought >one of the motivations for network-based mobility was to minimize the >signaling >to the MN during handover. > >-Pete > > From nobody Fri Mar 21 01:01:08 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F201A0639 for ; Fri, 21 Mar 2014 01:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqiGUT-cVdPM for ; Fri, 21 Mar 2014 01:01:03 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 01E201A0515 for ; Fri, 21 Mar 2014 01:01:02 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id lj1so2080729pab.36 for ; Fri, 21 Mar 2014 01:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j5VrEtMPqpGh9OBRKSRzIOfaM8fdj60dCZvQNXi9xfI=; b=Af1Ne/q/YhWMwSChEmbFE017fxEGf5BBz7CG02nqYysApSNR+5LjoH1CsxdlNFFmo2 Mx5u/ZXANc/ZDgeV7R0+90J7iXTWcDuryRKAK7bO4t8rzjtdAwGTzn1P6eGXnlE7yo04 Y88M0WAlYhXkxJYRxh1liRKTC1VFiOXQrG4e+NRXeFbtz2fMYEeRDq5Zf3zh3FxkmveK Oppry7LtXK5wDa7IAGIjsWyNCJ9bdXWOOqWlxCMIsDjqXUrxoF0ElQ03boG3sK800aBK qgxBrdsXxJDwpTS0Tj9iOnqGk2SG6GkvnXcl3+UNYXiGCgYOIQ9TfYjBBTKCOFWoDT7R JP8A== X-Received: by 10.68.28.69 with SMTP id z5mr52216470pbg.121.1395388534715; Fri, 21 Mar 2014 00:55:34 -0700 (PDT) Received: from [172.23.208.47] ([125.35.60.218]) by mx.google.com with ESMTPSA id yo9sm22272201pab.16.2014.03.21.00.55.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Mar 2014 00:55:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: Date: Fri, 21 Mar 2014 15:54:54 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <64F548F9-8164-4A54-BC11-4D0A02CC0BF1@gmail.com> References: <47C1CC71-67F1-4AC7-96AA-48BF37040C29@gmail.com> To: Ryuji Wakikawa X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/8dsZb0d4TAzsb-HDjVu4wwXyZB4 Cc: "dmm@ietf.org" Subject: Re: [DMM] re-charter text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 08:01:05 -0000 Ryuji, On Mar 20, 2014, at 4:55 PM, Ryuji Wakikawa = wrote: > Jouni >=20 > It=E2=80=99s good to see some room for non-MIP based solution in = DMM;-) >=20 > One clarification, the charter said following >=20 > "Specifically, when solutions are not > based on IP mobility protocols, the DMM workingvgroup shall = cooperate > with other IETF working groups working on other technologies that > might allow the mobility of an end host. These working groups = include > but are not limited to I2rs, Lisp, and Forces." >=20 > If we need to extend existing non-MIP protocols, it is reasonable to=20= > do extension in the working group owning the protocol. I agree on the = charter. >=20 > However, DMM should work on documenting =E2=80=9Chow to use it=E2=80=9D.= The document should=20 > be informational or experimental. Is this scope of DMM?=20 In a case some DMMish feature depends on a work done by other WG and it is used then in a DMM specific way, that should be documented in DMM document. This is specifically the case if the feature or extension done in other WG can be used also for other than DMM purposes. >=20 > btw, you may add IDR in the listed of working group. Ok. - Jouni >=20 > thanks > ryuji >=20 >=20 > 2014/03/17 =E5=8D=88=E5=BE=8C3:41=E3=80=81Jouni Korhonen = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A >=20 >> Folks, >>=20 >> I have updated the charter draft text slightly: >> = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >>=20 >> Basically: >>=20 >> Added Sri's comment on PMIPv6 maintenance. >> Added Alper's comment of location of mobility functions. >> Added links to other IETF WGs on possible mobility enabling = technologies. >> Added a comment that virtualised network functions are in scope. >>=20 >> - Jouni >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 From nobody Mon Mar 24 08:53:28 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64561A0241 for ; Mon, 24 Mar 2014 08:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.951 X-Spam-Level: X-Spam-Status: No, score=0.951 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4wEO4gJElJd for ; Mon, 24 Mar 2014 08:53:22 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2961A022B for ; Mon, 24 Mar 2014 08:53:21 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id p9so3741415lbv.24 for ; Mon, 24 Mar 2014 08:53:20 -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-type; bh=/IfhVplulsxub5HyHdx+fU26RP7lhhVSqJQCWyzAuCc=; b=k0iTj00GCwBwsPqSm4oldOUT4NmVigbmBQG2eqW32xPIk2dM/f9PXhXbsK4NFC23ne 3kiETrOob9bjFjVaWadvL9rzuB6O8wXm9MnZ422ESIAMv1H/XsvicdIwlOU04JxVVazk e0t+GF0aA08tukDpwrFgyr97wG2mh3U61EVjTJVgcvVxkkJn1PBVZVuwdwwZgVP5nYaO qc30Pj7dWzxwDM2uGzNOqmE0nEc5P6MjN9H1SltlEvjIpiB5jiBLDye9/uOiL3WcV+Lv bpRliUX3TlQuEVd9ywcutN5FtzlKjWmbNe9A03QXIyDGiDd4plsOPg2CX3ZA+bn42r7k TPKg== MIME-Version: 1.0 X-Received: by 10.112.97.178 with SMTP id eb18mr43553749lbb.13.1395676400765; Mon, 24 Mar 2014 08:53:20 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Mon, 24 Mar 2014 08:53:20 -0700 (PDT) In-Reply-To: <8B650D22-6089-4D1C-B499-C5E8DF6909AD@yegin.org> References: <8B650D22-6089-4D1C-B499-C5E8DF6909AD@yegin.org> Date: Mon, 24 Mar 2014 10:53:20 -0500 Message-ID: From: Behcet Sarikaya To: Alper Yegin Content-Type: multipart/alternative; boundary=001a1133e30816d16904f55c3c99 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/N-AJW67y2os2J0v_p1D0sdnZqIA Cc: "dmm@ietf.org" Subject: Re: [DMM] Next-Gen Mobility Protocols and Architectures Webex calls... X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 24 Mar 2014 15:53:25 -0000 --001a1133e30816d16904f55c3c99 Content-Type: text/plain; charset=ISO-8859-1 Hi Alper, I went to Doodle and noticed that the times have been arranged according to non-North American audience. Was this deliberate? Regards, Behcet On Thu, Mar 20, 2014 at 4:30 PM, Alper Yegin wrote: > > Hello folks, > > Remember I was proposing to have conference calls for people to present > their proposals and have discussions around them. > Having more discussions would help us make better progress, not only > within DMM or other WGs in IETF, but even in larger scale in the industry. > > Now I'm taking an initiative to start these calls.... > > The objective is to facilitate discussions around next generation mobility > protocols and architectures. > The scope is not limited to DMM. In other words, it is OK to discuss work > that falls outside the scope of DMM (NETEXT, MIF, etc....) > Calls will be open to anyone. Feel free to forward this message to others... > These will be only for informational discussions, we'll not be seeking any > decisions... > > The idea is to provide sufficient time for people to explain their ideas > properly, and others to have a chance to fully understand them and give > feedback. > > ... > > We'll start with the presentation of vEPC from Ryuji. > > We determined 3 dates for this first call. Please go on the Doodle and > register which one(s) work for you. > Based on that we'll determine the Webex call date. > > http://doodle.com/y87dk2kpt8rcbwpz > > > Make sure to enter your selections no later than the end of next Monday. > > > Cheers, > > Alper > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > --001a1133e30816d16904f55c3c99 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alper,

I went to Doodl= e and noticed that the times have been arranged according to non-North Amer= ican audience.

Was this deliberate?

Regards,

Behcet


On Thu, Mar 20, 2014 at 4:30 PM, Alper Yegin <alper.yegin= @yegin.org> wrote:
Hello folks,

Remember I was propo= sing to have conference calls for people to present their proposals and hav= e discussions around them. 
Having more discussions would help us make better progress, not only within= DMM or other WGs in IETF, but even in larger scale in the industry.
Now I'm taking an initiative to start these calls….

The = objective is to facilitate discussions around next generation mobility prot= ocols and architectures.
The scope is not limited to DMM. In other words, it is OK to discuss = work that falls outside the scope of DMM (NETEXT, MIF, etc….)
Cal= ls will be open to anyone. Feel free to forward this message to others&hell= ip;
These will be only for informational discussions, we'll not be s= eeking any decisions…

The idea is to provide sufficient time for people to explain their idea= s properly, and others to have a chance to fully understand them and give f= eedback.

…

We'll start with the presentation of vE= PC from Ryuji.

We determined 3 dates for this first call. Please go on the Doodle and = register which one(s) work for you.
Based on that we'll determine th= e Webex call date.

http://doodle.com/y87dk2kpt8rcbwpz


Make sure to enter your= selections no later than the end of next Monday.


Cheers,
Alper



_________________= ______________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm


--001a1133e30816d16904f55c3c99-- From nobody Mon Mar 24 09:48:01 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D023C1A025C for ; Mon, 24 Mar 2014 09:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4dVfQruze21 for ; Mon, 24 Mar 2014 09:47:55 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 2FACF1A0244 for ; Mon, 24 Mar 2014 09:47:55 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MTBcc-1WcTuU0dJm-00RaB0; Mon, 24 Mar 2014 12:47:52 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_C766DE74-DD69-4E90-AE21-E6D322FC9F8C" From: Alper Yegin In-Reply-To: Date: Mon, 24 Mar 2014 18:47:46 +0200 Message-Id: <40BDB448-EA07-4218-8F13-A4264A91C583@yegin.org> References: <8B650D22-6089-4D1C-B499-C5E8DF6909AD@yegin.org> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:7Hn0APP4UiMIg0tLSpu+FtVPMKZFSsQfiuCcLbzI6Ya m50nJ4xacEfyEaxE6S+rdoSwWnBQHgoknfDwA5gnuf8RT6i8ly SQSOV0vDhvAGtwBSu0bfLDtaPxbFlDyc8XkS6Z5NwPolNmPjzo r6rQBigDWdEjyz5sfL7ScnB8IlhDCZ/edVqrTZCAcbhaqY+USz ripzs4/YIS3A7Is6WWgyd03XZ1zO4+60WuE1er9nM31kiTiG4P PhUUD9PLbmk6NQJXZg65nT2S9KW8hZrUzxNAf0cYsaOPtGZ4ce 6Kd55y9hKyaghXXniGXrU6FFd4fp18FgflQY7+B4q37cFLpby1 H2eTRHESfvF+3fA1StaIq6FxNGqCeSWDOL4iIxR/B1ZmDawk6P GTSVSA2HaNMGQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/DOU_WL6MzQ1t4nsR5anWjt4jjJM Cc: "dmm@ietf.org" Subject: Re: [DMM] Next-Gen Mobility Protocols and Architectures Webex calls... X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 16:47:58 -0000 --Apple-Mail=_C766DE74-DD69-4E90-AE21-E6D322FC9F8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Behcet, The times are arranged according to presenter's availability and trying = to accommodate all time zones as much as possible (which is not = practical given that people will be participating from Japan to = California=85). No matter what you do, some people are going to lose = some sleep=85=20 Alper On Mar 24, 2014, at 5:53 PM, Behcet Sarikaya wrote: > Hi Alper, >=20 > I went to Doodle and noticed that the times have been arranged = according to non-North American audience. >=20 > Was this deliberate? >=20 > Regards, >=20 > Behcet >=20 >=20 > On Thu, Mar 20, 2014 at 4:30 PM, Alper Yegin = wrote: >=20 > Hello folks, >=20 > Remember I was proposing to have conference calls for people to = present their proposals and have discussions around them.=20 > Having more discussions would help us make better progress, not only = within DMM or other WGs in IETF, but even in larger scale in the = industry. >=20 > Now I'm taking an initiative to start these calls=85. >=20 > The objective is to facilitate discussions around next generation = mobility protocols and architectures. > The scope is not limited to DMM. In other words, it is OK to discuss = work that falls outside the scope of DMM (NETEXT, MIF, etc=85.) > Calls will be open to anyone. Feel free to forward this message to = others=85 > These will be only for informational discussions, we'll not be seeking = any decisions=85 >=20 > The idea is to provide sufficient time for people to explain their = ideas properly, and others to have a chance to fully understand them and = give feedback. >=20 > =85 >=20 > We'll start with the presentation of vEPC from Ryuji. >=20 > We determined 3 dates for this first call. Please go on the Doodle and = register which one(s) work for you. > Based on that we'll determine the Webex call date. >=20 > http://doodle.com/y87dk2kpt8rcbwpz >=20 >=20 > Make sure to enter your selections no later than the end of next = Monday. >=20 >=20 > Cheers, >=20 > Alper >=20 >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 --Apple-Mail=_C766DE74-DD69-4E90-AE21-E6D322FC9F8C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Behcet,

The times are arranged according to = presenter's availability and trying to accommodate all time zones as = much as possible (which is not practical given that people will be = participating from Japan to California=85). No matter what you do, some = people are going to lose some = sleep=85 

Alper


On Mar 24, 2014, at 5:53 PM, Behcet Sarikaya = wrote:

Hi = Alper,

I went to Doodle and noticed that the times have = been arranged according to non-North American audience.

Was = this deliberate?

Regards,

Behcet


On Thu, Mar 20, 2014 at 4:30 PM, Alper Yegin <alper.yegin@yegin.org> wrote:

Hello = folks,

Remember I was proposing to = have conference calls for people to present their proposals and have = discussions around them. 
Having more discussions would help us make better progress, not only = within DMM or other WGs in IETF, but even in larger scale in the = industry.

Now I'm taking an initiative to start these = calls=85.

The objective is to facilitate discussions around next = generation mobility protocols and architectures.
The scope is not limited to DMM. In other words, it is OK to = discuss work that falls outside the scope of DMM (NETEXT, MIF, = etc=85.)
Calls will be open to anyone. Feel free to forward this = message to others=85
These will be only for informational = discussions, we'll not be seeking any decisions=85

The idea is to provide sufficient time for people to explain their = ideas properly, and others to have a chance to fully understand them and = give feedback.

=85

We'll start with the presentation of = vEPC from Ryuji.

We determined 3 dates for this first call. Please go on the Doodle = and register which one(s) work for you.
Based on that we'll determine = the Webex call date.

http://doodle.com/y87dk2kpt8rcbwpz


Make sure to enter = your selections no later than the end of next = Monday.


Cheers,

Alper



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



= --Apple-Mail=_C766DE74-DD69-4E90-AE21-E6D322FC9F8C-- From nobody Mon Mar 24 09:52:00 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334831A027E for ; Mon, 24 Mar 2014 09:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIyIu1qdFYQ9 for ; Mon, 24 Mar 2014 09:51:56 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id A9ED71A027C for ; Mon, 24 Mar 2014 09:51:55 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id q8so3969483lbi.28 for ; Mon, 24 Mar 2014 09:51:54 -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-type; bh=RYjKwy0saM0NRquvK8vvqjZX1JWkpxYq2boIhpxVCb8=; b=LRw7JiLz/fVBRgtLJ5ppwO/44RGeWFvoPhauoKSfBWA3u5/chf4et5zfqRD5L+gEoL TjQTh8xkEL6NTSrKC6ngw0NMCFY9wjTVoJLE3qCHzfzjWP79HtbyOQ/n7aM58T5wBATq xSnsPK6qjvHeUFoysmOL3bubQQutGmXqtU/SKTU7bFFsXNof6M7P5kGbElT4vyJfYVm8 gh1JYC6FsiCqDFjAJtz/0n1+QueOqdzSKbQd7+47s4IFdYJgnQxOIsj/+6vO33RVYKza nxyYCjmzH1PVgUuAD9bNyRjRuvVch5U2wCY6T2l0yeX3fLcCRALZVQI3MGyCQu8N8wQZ c7Zg== MIME-Version: 1.0 X-Received: by 10.153.7.200 with SMTP id de8mr46370896lad.19.1395679914278; Mon, 24 Mar 2014 09:51:54 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Mon, 24 Mar 2014 09:51:54 -0700 (PDT) In-Reply-To: <40BDB448-EA07-4218-8F13-A4264A91C583@yegin.org> References: <8B650D22-6089-4D1C-B499-C5E8DF6909AD@yegin.org> <40BDB448-EA07-4218-8F13-A4264A91C583@yegin.org> Date: Mon, 24 Mar 2014 11:51:54 -0500 Message-ID: From: Behcet Sarikaya To: Alper Yegin Content-Type: multipart/alternative; boundary=001a1137e98682c4d804f55d0d09 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/QTMh9aIxt65-mHwewJ3M-OSR5ag Cc: "dmm@ietf.org" Subject: Re: [DMM] Next-Gen Mobility Protocols and Architectures Webex calls... X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 24 Mar 2014 16:51:58 -0000 --001a1137e98682c4d804f55d0d09 Content-Type: text/plain; charset=ISO-8859-1 Hi Alper, I have not seen a proposal that excludes NA, Jouni's times always were not like that. Regards, Behcet On Mon, Mar 24, 2014 at 11:47 AM, Alper Yegin wrote: > Hi Behcet, > > The times are arranged according to presenter's availability and trying to > accommodate all time zones as much as possible (which is not practical > given that people will be participating from Japan to California...). No > matter what you do, some people are going to lose some sleep... > > Alper > > > > On Mar 24, 2014, at 5:53 PM, Behcet Sarikaya wrote: > > Hi Alper, > > I went to Doodle and noticed that the times have been arranged according > to non-North American audience. > > Was this deliberate? > > Regards, > > Behcet > > > On Thu, Mar 20, 2014 at 4:30 PM, Alper Yegin wrote: > >> >> Hello folks, >> >> Remember I was proposing to have conference calls for people to present >> their proposals and have discussions around them. >> Having more discussions would help us make better progress, not only >> within DMM or other WGs in IETF, but even in larger scale in the industry. >> >> Now I'm taking an initiative to start these calls.... >> >> The objective is to facilitate discussions around next generation >> mobility protocols and architectures. >> The scope is not limited to DMM. In other words, it is OK to discuss work >> that falls outside the scope of DMM (NETEXT, MIF, etc....) >> Calls will be open to anyone. Feel free to forward this message to others... >> These will be only for informational discussions, we'll not be seeking >> any decisions... >> >> The idea is to provide sufficient time for people to explain their ideas >> properly, and others to have a chance to fully understand them and give >> feedback. >> >> ... >> >> We'll start with the presentation of vEPC from Ryuji. >> >> We determined 3 dates for this first call. Please go on the Doodle and >> register which one(s) work for you. >> Based on that we'll determine the Webex call date. >> >> http://doodle.com/y87dk2kpt8rcbwpz >> >> >> Make sure to enter your selections no later than the end of next Monday. >> >> >> Cheers, >> >> Alper >> >> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> >> > > --001a1137e98682c4d804f55d0d09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alper,

I have not seen a pr= oposal that excludes NA, Jouni's times always were not like that.
Regards,

Behcet


On Mon, Mar 24, 2014 at 11:47 AM, Alper = Yegin <alper.yegin@yegin.org> wrote:
Hi Behcet,

The times= are arranged according to presenter's availability and trying to accom= modate all time zones as much as possible (which is not practical given tha= t people will be participating from Japan to California…). No matter= what you do, some people are going to lose some sleep… 

Alper


=
On Mar 24, 2014, at 5:53 PM, Behcet Sarikaya wrote:

=
Hi Alper,

I went to Doodl= e and noticed that the times have been arranged according to non-North Amer= ican audience.

Was this deliberate?

Regards,

Behcet


On Thu, Mar 20, 2014 at 4:30 PM, Alper Yegin <alper.yegin= @yegin.org> wrote:
Hello folks,

Remember I was proposing to hav= e conference calls for people to present their proposals and have discussio= ns around them. 
Having more discussions would help us make better progress, not only within= DMM or other WGs in IETF, but even in larger scale in the industry.
Now I'm taking an initiative to start these calls….

The = objective is to facilitate discussions around next generation mobility prot= ocols and architectures.
The scope is not limited to DMM. In other words, it is OK to discuss = work that falls outside the scope of DMM (NETEXT, MIF, etc….)
Cal= ls will be open to anyone. Feel free to forward this message to others&hell= ip;
These will be only for informational discussions, we'll not be s= eeking any decisions…

The idea is to provide sufficient time for people to explain their idea= s properly, and others to have a chance to fully understand them and give f= eedback.

…

We'll start with the presentation of vE= PC from Ryuji.

We determined 3 dates for this first call. Please go on the Doodle and = register which one(s) work for you.
Based on that we'll determine th= e Webex call date.

http://doodle.com/y87dk2kpt8rcbwpz


Make sure to enter your selections= no later than the end of next Monday.


Cheers,

Alper



____________________________= ___________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm




--001a1137e98682c4d804f55d0d09-- From nobody Mon Mar 24 10:14:10 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FAB1A0269 for ; Mon, 24 Mar 2014 10:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGTws7BGoVaq for ; Mon, 24 Mar 2014 10:14:03 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB6F1A0265 for ; Mon, 24 Mar 2014 10:14:03 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M0hDa-1XMqrr1PMU-00uix2; Mon, 24 Mar 2014 13:14:01 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_A127D6E5-AE44-40C5-9004-1CC1DF4E79CE" From: Alper Yegin In-Reply-To: Date: Mon, 24 Mar 2014 19:13:54 +0200 Message-Id: References: <8B650D22-6089-4D1C-B499-C5E8DF6909AD@yegin.org> <40BDB448-EA07-4218-8F13-A4264A91C583@yegin.org> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:3XMCJzCS3DZdfdRUMEIDM0HMrByBl3/skNv0alCqTtu JKHoRGnVw0ciddmNBvYfN3Ebts9lLTmMNc3MetQQ+++jOq6Rto F91+trkuG/ZK8MuiTlPL0+HydNe/LOnp2mB8zEojPvv1xiUn48 8N+0RogSoeRqB+UJhkd7ve52V647NEeGJR0u0P/1yHDGd1358f /uKBRkatEg4S63vuteDgxf6/JKwDB9A52hy3FuvYkYP8hMjBpq 3c08HH/DbrIx1sncZlbFRWeWcpy9iCu9tiPzxWuiK13YLkdleN QPy6ko2GrtoyWVNWqw7oftj9bu+Hb5gd7GUH/1HZXbZbRqKC4c v6n7p4CsRvJzijRcHabuUjrwjvDw0E1eP64h+dqLDRDrR5hzH5 Ps1eVhP5AbF7Q== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/laiRzxgNe5vLiqD7ikV5pvngYuc Cc: "dmm@ietf.org" Subject: Re: [DMM] Next-Gen Mobility Protocols and Architectures Webex calls... X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 17:14:09 -0000 --Apple-Mail=_A127D6E5-AE44-40C5-9004-1CC1DF4E79CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Behcet, Jouni's Feb 25th call was at 17:00 GMT+02, which is 12:00 am in = Japan/Korea. One of the currently proposed slots is the same nature (starting at = 12:00am), this time for US East Coast. Ryuji is presenting, and he's in Japan. Alper On Mar 24, 2014, at 6:51 PM, Behcet Sarikaya wrote: > Hi Alper, >=20 > I have not seen a proposal that excludes NA, Jouni's times always were = not like that. >=20 > Regards, >=20 > Behcet >=20 >=20 > On Mon, Mar 24, 2014 at 11:47 AM, Alper Yegin = wrote: > Hi Behcet, >=20 > The times are arranged according to presenter's availability and = trying to accommodate all time zones as much as possible (which is not = practical given that people will be participating from Japan to = California=85). No matter what you do, some people are going to lose = some sleep=85=20 >=20 > Alper >=20 >=20 >=20 > On Mar 24, 2014, at 5:53 PM, Behcet Sarikaya wrote: >=20 >> Hi Alper, >>=20 >> I went to Doodle and noticed that the times have been arranged = according to non-North American audience. >>=20 >> Was this deliberate? >>=20 >> Regards, >>=20 >> Behcet >>=20 >>=20 >> On Thu, Mar 20, 2014 at 4:30 PM, Alper Yegin = wrote: >>=20 >> Hello folks, >>=20 >> Remember I was proposing to have conference calls for people to = present their proposals and have discussions around them.=20 >> Having more discussions would help us make better progress, not only = within DMM or other WGs in IETF, but even in larger scale in the = industry. >>=20 >> Now I'm taking an initiative to start these calls=85. >>=20 >> The objective is to facilitate discussions around next generation = mobility protocols and architectures. >> The scope is not limited to DMM. In other words, it is OK to discuss = work that falls outside the scope of DMM (NETEXT, MIF, etc=85.) >> Calls will be open to anyone. Feel free to forward this message to = others=85 >> These will be only for informational discussions, we'll not be = seeking any decisions=85 >>=20 >> The idea is to provide sufficient time for people to explain their = ideas properly, and others to have a chance to fully understand them and = give feedback. >>=20 >> =85 >>=20 >> We'll start with the presentation of vEPC from Ryuji. >>=20 >> We determined 3 dates for this first call. Please go on the Doodle = and register which one(s) work for you. >> Based on that we'll determine the Webex call date. >>=20 >> http://doodle.com/y87dk2kpt8rcbwpz >>=20 >>=20 >> Make sure to enter your selections no later than the end of next = Monday. >>=20 >>=20 >> Cheers, >>=20 >> Alper >>=20 >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >>=20 >>=20 >=20 >=20 --Apple-Mail=_A127D6E5-AE44-40C5-9004-1CC1DF4E79CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Alper,

I have not seen a = proposal that excludes NA, Jouni's times always were not like = that.

Regards,

Behcet


On Mon, Mar 24, 2014 at 11:47 AM, = Alper Yegin <alper.yegin@yegin.org> = wrote:
Hi Behcet,

The = times are arranged according to presenter's availability and trying to = accommodate all time zones as much as possible (which is not practical = given that people will be participating from Japan to California=85). No = matter what you do, some people are going to lose some = sleep=85 

Alper



On Mar 24, = 2014, at 5:53 PM, Behcet Sarikaya wrote:

Hi Alper,

I went to = Doodle and noticed that the times have been arranged according to = non-North American audience.

Was this = deliberate?

Regards,

Behcet


On Thu, Mar 20, 2014 at 4:30 PM, Alper Yegin <alper.yegin@yegin.org> wrote:

Hello = folks,

Remember I was proposing to have = conference calls for people to present their proposals and have = discussions around them. 
Having more discussions would help us make better progress, not only = within DMM or other WGs in IETF, but even in larger scale in the = industry.

Now I'm taking an initiative to start these = calls=85.

The objective is to facilitate discussions around next = generation mobility protocols and architectures.
The scope is not limited to DMM. In other words, it is OK to = discuss work that falls outside the scope of DMM (NETEXT, MIF, = etc=85.)
Calls will be open to anyone. Feel free to forward this = message to others=85
These will be only for informational = discussions, we'll not be seeking any decisions=85

The idea is to provide sufficient time for people to explain their = ideas properly, and others to have a chance to fully understand them and = give feedback.

=85

We'll start with the presentation of = vEPC from Ryuji.

We determined 3 dates for this first call. Please go on the Doodle = and register which one(s) work for you.
Based on that we'll determine = the Webex call date.

http://doodle.com/y87dk2kpt8rcbwpz


Make sure to enter your = selections no later than the end of next = Monday.


Cheers,

Alper



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


=



= --Apple-Mail=_A127D6E5-AE44-40C5-9004-1CC1DF4E79CE-- From nobody Tue Mar 25 03:37:20 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34EC1A0181 for ; Tue, 25 Mar 2014 03:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VGiRU_C9MFg for ; Tue, 25 Mar 2014 03:36:42 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5251A0197 for ; Tue, 25 Mar 2014 03:36:42 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MbP5A-1Wl1X83EPM-00JMcj; Tue, 25 Mar 2014 06:36:41 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_2434F8C1-8574-4D13-925A-35879933CC61" From: Alper Yegin X-Priority: 3 X-Mail-Calendar-Part: Yes Date: Tue, 25 Mar 2014 12:36:37 +0200 Message-Id: <1428C971-BCCE-40A2-8E9D-6D732DA51FB3@yegin.org> References: <1518949455.2095711395743488008.JavaMail.nobody@rln9rmd101.webex.com> To: dmm@ietf.org X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:Ws3qttwQ4MrUaTqvz25KTRsYohlu6srqAwQZWHPaStK tLQajYHLTo8/EaIy1qaKSeMgWA1uD+xYdQzTlS60fiWCubKISn TUJKpPY0yZD2jLYfKLUGBa4fJp/3c52WqQ803VyflqkCVdPf10 o9CfKdwofL6strnk2OohesPmf2c4CyRfgMdCxI+Ga9l/ioc6XX u+Z1xomrBAjfz1KAjZbhR3q5uzaUQTw0XBRvLiXpW4htTLua4k vli7t+cbnnJ/TGQVh04jSmGi6jSD642CQ3Xx011RDO6y0IwUjR JJ4dxvsPxslAd5sriaiwXneyrDYdplNzEEGxphUn57qN+5cm77 PiVxSqy+vwVAdGtJXtDURlwGNXN+98WdeUpVNzg5krZRNxFoW/ twq61LW55a+dg== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/6FQ_BfcGv2u3nbddsgCIGaqs14Q Subject: [DMM] Fwd: Invitation to WebEx meeting: Next-Gen Mobility Protocols and Architectures X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 10:36:45 -0000 --Apple-Mail=_2434F8C1-8574-4D13-925A-35879933CC61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Folks, See below for this Friday's Webex call details. Alper Begin forwarded message: >=20 >=20 > Hi, > =09 > =20 > Alper Yegin is inviting you to this WebEx meeting: > =09 > Next-Gen Mobility Protocols and Architectures=20 > Fri, Mar 28, 7:00 am | 1 hr 30 min > Istanbul (Eastern Europe Time, GMT+02:00) > Host: Alper Yegin > =09 > Join > =09 > =20 > Add the attached iCalendar (.ics) file to your calendar. > =09 > Agenda >=20 > vEPC presentation by Ryuji. > =09 > Access Information >=20 > Where: WebEx Online > Meeting number: 230 030 283 > Password: This meeting does not require a password. > =09 > Audio Connection >=20 > +44-203-478-5289 UK Domestic Toll > Access code: 230 030 283 > Can't access your meeting? Get help. > Delivering the power of collaboration > Cisco WebEx Team >=20 > IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the meeting to be recorded. By joining this meeting, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the meeting. Please note that any such = recordings may be subject to discovery in the event of litigation. >=20 > =A92013 Cisco and/or its affiliates. All rights reserved. > MT-A-001 >=20 --Apple-Mail=_2434F8C1-8574-4D13-925A-35879933CC61 Content-Type: multipart/mixed; boundary="Apple-Mail=_C7F59655-D427-4FBB-AB92-8A1867F1FD51" --Apple-Mail=_C7F59655-D427-4FBB-AB92-8A1867F1FD51 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

= 3D"Cisco
=
=
Hi,
3D""
 
Alper Yegin is inviting you to this WebEx meeting:
3D""   
Next-Gen Mobility Protocols and Architectures
Fri, Mar 28, 7:00 am | 1 hr 30 = min
Host: Alper Yegin
  
3D""
 
3D""  

Agenda

vEPC presentation by Ryuji.
3D""  

Access Information

Where:  WebEx Online
Meeting = number:  230 030 283
Password:  This meeting does not require a = password.
3D""  

Audio Connection

+44-203-478-5289 UK Domestic Toll
Access code: 230 030 283

Can't access your = meeting? Get = help.
= = = = = = = = =
=
= Delivering the power of collaboration
= Cisco WebEx Team =
=
= =
3D"Footer"
=20
IMPORTANT = NOTICE: This WebEx service includes a feature that allows audio and any = documents and other materials exchanged or viewed during the meeting to = be recorded. By joining this meeting, you automatically consent to such = recordings. If you do not consent to the recording, discuss your = concerns with the meeting host prior to the start of the recording or do = not join the meeting. Please note that any such recordings may be = subject to discovery in the event of litigation.
=20

=A92013 Cisco = and/or its affiliates. All rights reserved.
MT-A-001
= 3D"Cisco"
= --Apple-Mail=_C7F59655-D427-4FBB-AB92-8A1867F1FD51 Content-Disposition: attachment; filename="Next-Gen Mobility Protocols and Architectures.ics" Content-Type: text/calendar; name="Next-Gen Mobility Protocols and Architectures.ics" Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR=0APRODID:-//Microsoft=20Corporation//Outlook=2012.0=20= MIMEDIR//EN=0AVERSION:2.0=0AMETHOD:REQUEST=0A=0ABEGIN:VTIMEZONE=0A= TZID:Eastern=20Europe=0ABEGIN:STANDARD=0ADTSTART:20001029T040000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D10;BYHOUR=3D4=0A= TZOFFSETFROM:+0300=0ATZOFFSETTO:+0200=0ATZNAME:Standard=20Time=0A= END:STANDARD=0ABEGIN:DAYLIGHT=0ADTSTART:20000326T030000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D3;BYHOUR=3D3=0A= TZOFFSETFROM:+0200=0ATZOFFSETTO:+0300=0ATZNAME:Daylight=20Savings=20Time=0A= END:DAYLIGHT=0AEND:VTIMEZONE=0A=0ABEGIN:VEVENT=0ACLASS:PUBLIC=0A= UID:M53ATCU9C6UYOT3D9Q0V9Y6CX2-1KJ9=0ADTSTAMP:20140325T103127Z=0A= SUMMARY:Next-Gen=20Mobility=20Protocols=20and=20Architectures=0A= LOCATION:WebEx=20Online=0APRIORITY:5=0ASEQUENCE:1027321958=0A= TRANSP:OPAQUE=0A=0AORGANIZER;CN=3D"Alper=20Yegin=20via=20Cisco=20= WebEx":MAILTO:alper_yegin@hotmail.com=0A= ATTENDEE;ROLE=3DREQ-PARTICIPANT;PARTSTAT=3DNEEDS-ACTION;RSVP=3DTRUE:MAILTO= :alper.yegin@yegin.org=0A=0ADTSTART;TZID=3D"Eastern=20= Europe":20140328T070000=0ADTEND;TZID=3D"Eastern=20= Europe":20140328T083000=0A=0ADESCRIPTION:Hi,\n\nAlper=20Yegin=20is=20= inviting=20you=20to=20this=20WebEx=20meeting:\n\nNext-Gen=20Mobility=20= Protocols=20and=20Architectures\nFri,=20Mar=2028,=207:00=20am=20|=201=20= hr=2030=20min\nIstanbul=20(Eastern=20Europe=20Time,=20GMT+02:00)\nHost:=20= Alper=20Yegin\n\nWhen=20it's=20time,=20join=20the=20meeting=20from=20= here:\nhttps://meetings.webex.com/collabs/meetings/join?uuid=3DM53ATCU9C6U= YOT3D9Q0V9Y6CX2-1KJ9\n\nAgenda\nvEPC=20presentation=20by=20= Ryuji.\n\nAccess=20Information\nWhere:=20WebEx=20Online\nMeeting=20= number:=20230=20030=20283\nMeeting=20password:=20This=20meeting=20does=20= not=20require=20a=20password.\n\nAudio=20Connection\n+44-203-478-5289=20= UK=20Domestic=20Toll\nAccess=20code:=20230=20030=20283\n\n\n\n\n\nCan't=20= access=20your=20meeting?=20Get=20= help:\nhttps://meetings.webex.com/collabs/#/support\n\n\nDelivering=20= the=20power=20of=20collaboration\nCisco=20WebEx=20= Team\n\n-----------------------------------------------------------\n\nIMP= ORTANT=20NOTICE:=20This=20WebEx=20service=20includes=20a=20feature=20= that=20allows=20audio=20and=20any=20documents=20and=20other=20materials=20= exchanged=20or=20viewed=20during=20the=20meeting=20to=20be=20recorded.=20= By=20joining=20this=20meeting,=20you=20automatically=20consent=20to=20= such=20recordings.=20If=20you=20do=20not=20consent=20to=20the=20= recording,=20discuss=20your=20concerns=20with=20the=20meeting=20host=20= prior=20to=20the=20start=20of=20the=20recording=20or=20do=20not=20join=20= the=20meeting.=20Please=20note=20that=20any=20such=20recordings=20may=20= be=20subject=20to=20discovery=20in=20the=20event=20of=20= litigation.\n\n=C2=A92013=20Cisco=20and/or=20its=20affiliates.=20All=20= rights=20reserved.\n\nMT-A-001\n=0A=0ABEGIN:VALARM=0AACTION:DISPLAY=0A= DESCRIPTION:REMINDER=0ATRIGGER:-PT900S=0AEND:VALARM=0A=0AEND:VEVENT=0A=0A= END:VCALENDAR=0A= --Apple-Mail=_C7F59655-D427-4FBB-AB92-8A1867F1FD51 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

--Apple-Mail=_C7F59655-D427-4FBB-AB92-8A1867F1FD51-- --Apple-Mail=_2434F8C1-8574-4D13-925A-35879933CC61-- From nobody Wed Mar 26 03:02:42 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AF31A02D2 for ; Wed, 26 Mar 2014 03:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uG2x-wQJiQys for ; Wed, 26 Mar 2014 03:02:37 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB0B1A01FF for ; Wed, 26 Mar 2014 03:02:36 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id u14so1288993lbd.19 for ; Wed, 26 Mar 2014 03:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=OE5VhrzW79eR8pcqcCwZ15AEdL6DHrwX2d7C4Hu93bc=; b=IzEVOczBUKpPJt+cKuc1fHTe4oUUmX5RmKpShyl1pS5asddfI81iGgadcMOTGetauH kR+4Dn7iJ99iqM4dl9m3bKJAsrfS5U+zdMIluPwIOxz4C2MG1jwZljcQ3ZLw8XpD7Y96 xbC18ItbSU1lplM9SuQK7wot6RffV3fdmjL/3ROj2HOWhXwulE+Clx+LZKyx9PM4CtSk jw8azSdHvpbYqNsIiKiBUBV8XlUv8WnOAXgUCHHGcaqwBQ2GW+ct0Jy6oco2Gor2KvJm XlbAQbELU+Gi2dk5upebmZVQi4KCWDtOL0dDPGw4GLXl7MKXiNM5tI3jqBBYNDZvESXJ SpLA== X-Received: by 10.153.7.200 with SMTP id de8mr53654062lad.19.1395828155172; Wed, 26 Mar 2014 03:02:35 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:4936:a1de:6965:ce31? ([2001:1bc8:101:f101:4936:a1de:6965:ce31]) by mx.google.com with ESMTPSA id am9sm19356505lac.11.2014.03.26.03.02.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Mar 2014 03:02:34 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <1AFEB85B-BE65-4426-B156-CA7B3A7F63E9@gmail.com> Date: Wed, 26 Mar 2014 12:02:32 +0200 To: "dmm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/iYEII_Fty6AENQ7Au6P-IhHmE-o Subject: [DMM] rechartering draft text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 10:02:39 -0000 Folks, Take a look at the latest revision. I have added the initial stab for the milestones. Comments and flames are welcome. If you want something to be changed, just propose text & diff. You might also want to say why the change is needed. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt - Jouni From nobody Wed Mar 26 07:32:12 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF671A0146 for ; Wed, 26 Mar 2014 07:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIFTLIAe1w8y for ; Wed, 26 Mar 2014 07:32:09 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id C9E0C1A00E3 for ; Wed, 26 Mar 2014 07:32:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s2QEW8jm000937; Wed, 26 Mar 2014 07:32:08 -0700 Received: from XCH-PHX-213.sw.nos.boeing.com (xch-phx-213.sw.nos.boeing.com [130.247.25.142]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s2QEW6Be000891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 26 Mar 2014 07:32:06 -0700 Received: from XCH-BLV-102.nw.nos.boeing.com (2002:82f7:1975::82f7:1975) by XCH-PHX-213.sw.nos.boeing.com (2002:82f7:198e::82f7:198e) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 26 Mar 2014 07:32:05 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.87]) by XCH-BLV-102.nw.nos.boeing.com ([169.254.2.207]) with mapi id 14.03.0174.001; Wed, 26 Mar 2014 07:32:05 -0700 From: "Templin, Fred L" To: Jouni Korhonen , "dmm@ietf.org" Thread-Topic: [DMM] rechartering draft text updated Thread-Index: AQHPSNqKUyECNGhGyECqX9Lv5ZbK8JrzbceQ Date: Wed, 26 Mar 2014 14:32:04 +0000 Message-ID: <2134F8430051B64F815C691A62D9831820C3F4@XCH-BLV-504.nw.nos.boeing.com> References: <1AFEB85B-BE65-4426-B156-CA7B3A7F63E9@gmail.com> In-Reply-To: <1AFEB85B-BE65-4426-B156-CA7B3A7F63E9@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/qO4hlUqEVz-WuRs134a3us4nv4U Subject: Re: [DMM] rechartering draft text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 14:32:11 -0000 Hi Jouni, In paragraph 5, it says: "At least IPv6 is assumed to be present in both the mobile host/router and the access networks." I disagree with the trailing phrase "and the access networks" since many access networks may remain as IPv4-only for a long time yet. It would satisfy my concern if the sentence were modified to simply drop the trailing phrase. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Wednesday, March 26, 2014 3:03 AM > To: dmm@ietf.org > Subject: [DMM] rechartering draft text updated >=20 > Folks, >=20 > Take a look at the latest revision. I have added the initial stab > for the milestones. Comments and flames are welcome. If you want > something to be changed, just propose text & diff. You might also > want to say why the change is needed. >=20 > https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.tx= t >=20 > - Jouni >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Mar 26 08:08:38 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB031A0119 for ; Wed, 26 Mar 2014 08:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm_MOFr5uVXu for ; Wed, 26 Mar 2014 08:08:32 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 461DA1A0107 for ; Wed, 26 Mar 2014 08:08:32 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LngZT-1X0WIg04VD-00hDQ2; Wed, 26 Mar 2014 11:08:29 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_054820D0-57B2-4271-B9BB-D5F37E818AF6" From: Alper Yegin In-Reply-To: <1AFEB85B-BE65-4426-B156-CA7B3A7F63E9@gmail.com> Date: Wed, 26 Mar 2014 17:08:20 +0200 Message-Id: <14A3D3C1-975B-44F6-B413-39C532711C1A@yegin.org> References: <1AFEB85B-BE65-4426-B156-CA7B3A7F63E9@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:Dl+c+YlK6VNnN9ce0qT1c21uE/GT6KV4em3dccZKJgB IUHXRRFwwBYGIhBIjKzSRRArr4bfLrPiZgSs+XJfMSjJ1k881L RQKOC+rw7lhBRGmhjm/4jQFuRou7ZnACkVoAiqT1nq+EXJw4+4 bnYfz/KqJQCAH84gyoPFIgExCpDxLgXOTzjTYpTMq/HsFA1IEL FxMvvia9QdOuV5oDYSzJgP0bLtLmbY7iN9p+AIdHM15k5SuSG/ ugAfuE6cBTXnyHPbY9TkVPRjnNPHzUVUx9nkzIDC3GgKqKQVhq K8Ylu7jze1iAHY1O+rlqGl/wO8JWdXf252Nyq94gV2DDK44p8j ZNodp6lSS9N+8WTxm32LOwwiS3rMvJTfgVSBbl+IeqgEPJWLFe Mxvqm59cgEl2A== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/giLoZK6_arxP4TRTAMFoJ16sFl8 Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering draft text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 15:08:35 -0000 --Apple-Mail=_054820D0-57B2-4271-B9BB-D5F37E818AF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Jouni, DMM can be used to realise such a distributed deployment model, by distributing forwarding functions at optimal location; = for example, closer either to the mobile user or the corresponding = node. s/user/node Although the maintenance of stable home address(es) and/or = prefix(es) and upper level sessions is a desirable goal when mobile = hosts/routers change their point of attachment to the Internet, it is not a = strict requirement. Mobile hosts/routers should not assume that IP addressing including home address(es) and/or home network = prefix(es) remain the same throughout the entire upper level session = lifetime, or that support for mobility functions is provided on the network = side in all conditions, unless these properties are specifically = indicated to the mobile node and its applications from the network. Is this trying to say "the network may not be able to provide a stable = IP address to the MN"? Even in the presence of a DMM solution? Mar 2014 - Submit 'The deployment models and scenarios' submitted to = the IESG. To be Informational RFC. Marc 2014 - Submit 'Enhanced gateway and mobility anchor selection' = submitted to the IESG. To be Proposed Standard. I guess these are meant to be 2015. Btw, the milestones do not seem to have an item to cover for "Forwarding = path and signalling management" Thanks Jouni Alper On Mar 26, 2014, at 12:02 PM, Jouni Korhonen wrote: > Folks, >=20 > Take a look at the latest revision. I have added the initial stab > for the milestones. Comments and flames are welcome. If you want > something to be changed, just propose text & diff. You might also > want to say why the change is needed. >=20 > = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >=20 > - Jouni >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm --Apple-Mail=_054820D0-57B2-4271-B9BB-D5F37E818AF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Jouni,

      DMM = can be used to realise such a distributed deployment
      model, by = distributing forwarding functions at optimal location; for
      example, = closer either to the mobile user or the corresponding = node.


s/user/node
=

  =     Although the maintenance of stable home address(es) and/or = prefix(es)
Even in the presence of a DMM = solution?

  Mar = 2014 - Submit 'The deployment models and scenarios' submitted to the = IESG.
  Marc 2014 - = Submit 'Enhanced gateway and mobility anchor selection' submitted to = the

I guess these are meant to be 2015.

Btw, the = milestones do not seem to have an item to cover for "Forwarding path and = signalling management"

Thanks Jouni
Alper


Folks,

Take a look at the latest revision. I = have added the initial stab
for the milestones. Comments and flames = are welcome. If you want
something to be changed, just propose text = & diff. You might also
want to say why the change is = needed.

https://github.com/jounikor/dmm-re-charter/blob/master/recharter= _draft.txt

- = Jouni

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

= --Apple-Mail=_054820D0-57B2-4271-B9BB-D5F37E818AF6-- From nobody Wed Mar 26 08:41:12 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB93C1A037E for ; Wed, 26 Mar 2014 08:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bm0tBlrPjxXN for ; Wed, 26 Mar 2014 08:41:08 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id 833EC1A0376 for ; Wed, 26 Mar 2014 08:41:07 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id c11so1608504lbj.40 for ; Wed, 26 Mar 2014 08:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W20RkuJ0ecicEgzAnIIoYhq5vkin9BNCcZ65Es9MQFw=; b=Vzd72+tHzuzdyICwhHbk0rrhXNc45hyCyip38dbWa/9TUUExoX2f2vhUuxY+bGmHva GCtcOmyTV0lXCtLASnecagx7Pn+UUgHy74VrJ4AnZtFtsyD/KcDpnZI5fbpZhT009vo5 X5Qy9QI0g2wIVCw3h7hTKVarwmNYjNG9xkFN3izXQ3E2yw9a4Iuioxs9dAtrlZy7n6WP GraOvNIRYH5DtuJuKvM9o2qhCxJh50Cz6COYjNroD05vrsvnTKV07OGife9gII68mLsT 7TmVEnD6yiT2+fkfQWckt+vAPe98axtZkljmAT+v11hrDSMP+HtiCCAbXiJdWTTLOE8J z3tQ== X-Received: by 10.152.42.144 with SMTP id o16mr55466501lal.9.1395848465483; Wed, 26 Mar 2014 08:41:05 -0700 (PDT) Received: from [188.117.15.107] ([188.117.15.107]) by mx.google.com with ESMTPSA id d4sm14247361lbr.27.2014.03.26.08.41.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Mar 2014 08:41:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <2134F8430051B64F815C691A62D9831820C3F4@XCH-BLV-504.nw.nos.boeing.com> Date: Wed, 26 Mar 2014 17:41:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1CCE4779-47D4-4E03-A293-5108DDAC8A92@gmail.com> References: <1AFEB85B-BE65-4426-B156-CA7B3A7F63E9@gmail.com> <2134F8430051B64F815C691A62D9831820C3F4@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/PoV3BoYd2uhlvmv5F7l1sLXPT4Q Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering draft text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 15:41:11 -0000 I hear you.. but this is what the original charter already said. We deliberately scope the charter in a way that we could avoid tunnelling between the end host and the access router. - Jouni On Mar 26, 2014, at 4:32 PM, "Templin, Fred L" = wrote: > Hi Jouni, >=20 > In paragraph 5, it says: >=20 > "At least IPv6 is assumed to be present in both the mobile host/router > and the access networks." >=20 > I disagree with the trailing phrase "and the access networks" > since many access networks may remain as IPv4-only for a long > time yet. It would satisfy my concern if the sentence were > modified to simply drop the trailing phrase. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> -----Original Message----- >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen >> Sent: Wednesday, March 26, 2014 3:03 AM >> To: dmm@ietf.org >> Subject: [DMM] rechartering draft text updated >>=20 >> Folks, >>=20 >> Take a look at the latest revision. I have added the initial stab >> for the milestones. Comments and flames are welcome. If you want >> something to be changed, just propose text & diff. You might also >> want to say why the change is needed. >>=20 >> = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >>=20 >> - Jouni >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Mar 26 08:47:31 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784B21A00E3 for ; Wed, 26 Mar 2014 08:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwV2EE_SUu67 for ; Wed, 26 Mar 2014 08:47:27 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5921A0165 for ; Wed, 26 Mar 2014 08:47:26 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id 10so1624760lbg.39 for ; Wed, 26 Mar 2014 08:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AjRkqSkz+bYFEmCmbCs/6U1ocvOUuKP6NkEqKSty66Q=; b=BugBsNtPUrZOIYJ3xXKJlVccd/jOLVGWJxgTT0EuTvLFQzQDUNyKJslM29pSt+Sp9C /PtjoojNxIjMQvJo1chZqlqgy95qvLzeVBDLjTxMcYoNMdbnU/WXNsofUTCEZvHSG9aU GSoieIKX21vPG5q0AmMCYsZbiZczAZVw+Gh+Rg0aoKhSBNK1lbd/v/j+yfeWwIsWaGVn 1u4NHq51k3C467oFg8vK+a3zLwSc4jhREbuAH9KbepMbazThyA4r80Pw6MMBy1c2ITpQ x4BeuoRToBw1pq6ICAVSMoE2wGddwERpT3HPX6jLxJDlvRi2cwpWY6InOM9xAM+M/qIC WIXw== X-Received: by 10.152.4.201 with SMTP id m9mr235612lam.61.1395848844983; Wed, 26 Mar 2014 08:47:24 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:4936:a1de:6965:ce31? ([2001:1bc8:101:f101:4936:a1de:6965:ce31]) by mx.google.com with ESMTPSA id sx1sm20136524lac.1.2014.03.26.08.47.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Mar 2014 08:47:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <14A3D3C1-975B-44F6-B413-39C532711C1A@yegin.org> Date: Wed, 26 Mar 2014 17:47:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1AFEB85B-BE65-4426-B156-CA7B3A7F63E9@gmail.com> <14A3D3C1-975B-44F6-B413-39C532711C1A@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/ZRjvIBy0Ew78IM6AfS4V13lbLJA Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering draft text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 15:47:29 -0000 On Mar 26, 2014, at 5:08 PM, Alper Yegin wrote: > Hi Jouni, >=20 > DMM can be used to realise such a distributed deployment > model, by distributing forwarding functions at optimal location; = for > example, closer either to the mobile user or the corresponding = node. >=20 >=20 > s/user/node Ack. >=20 >=20 > Although the maintenance of stable home address(es) and/or = prefix(es) > and upper level sessions is a desirable goal when mobile = hosts/routers > change their point of attachment to the Internet, it is not a = strict > requirement. Mobile hosts/routers should not assume that IP > addressing including home address(es) and/or home network = prefix(es) > remain the same throughout the entire upper level session = lifetime, > or that support for mobility functions is provided on the = network side > in all conditions, unless these properties are specifically = indicated > to the mobile node and its applications from the network. >=20 > Is this trying to say "the network may not be able to provide a stable = IP address to the MN"? > Even in the presence of a DMM solution? Yes.. it is imho a valid use case that the mn just does not care all = addresses having mobility. The DMM solution may provide stable address = only for a subset of addresses available for the mn. >=20 > Mar 2014 - Submit 'The deployment models and scenarios' submitted to = the IESG. > To be Informational RFC. > Marc 2014 - Submit 'Enhanced gateway and mobility anchor selection' = submitted to the > IESG. To be Proposed Standard. >=20 > I guess these are meant to be 2015. Uhh.. yes. (copy-paste is always dangerous) >=20 > Btw, the milestones do not seem to have an item to cover for = "Forwarding path and signalling management" Not at this point. Two reasons: I could not figure a good name for the = milestone and also was a bit concerned whether we would have all the = energy to work on this many documents in parallel. - Jouni >=20 > Thanks Jouni >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Mar 26, 2014, at 12:02 PM, Jouni Korhonen wrote: >=20 >> Folks, >>=20 >> Take a look at the latest revision. I have added the initial stab >> for the milestones. Comments and flames are welcome. If you want >> something to be changed, just propose text & diff. You might also >> want to say why the change is needed. >>=20 >> = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >>=20 >> - Jouni >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 From nobody Wed Mar 26 08:50:52 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA171A0113 for ; Wed, 26 Mar 2014 08:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjeQoEkQlcJa for ; Wed, 26 Mar 2014 08:50:48 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id C87761A033F for ; Wed, 26 Mar 2014 08:50:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s2QFol2c009949; Wed, 26 Mar 2014 08:50:47 -0700 Received: from XCH-PHX-512.sw.nos.boeing.com (xch-phx-512.sw.nos.boeing.com [10.57.37.29]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s2QFoeb1009846 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 26 Mar 2014 08:50:40 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.87]) by XCH-PHX-512.sw.nos.boeing.com ([169.254.12.218]) with mapi id 14.03.0174.001; Wed, 26 Mar 2014 08:50:40 -0700 From: "Templin, Fred L" To: Jouni Korhonen Thread-Topic: [DMM] rechartering draft text updated Thread-Index: AQHPSQnKUyECNGhGyECqX9Lv5ZbK8Jrzgzzg Date: Wed, 26 Mar 2014 15:50:39 +0000 Message-ID: <2134F8430051B64F815C691A62D9831820C5DD@XCH-BLV-504.nw.nos.boeing.com> References: <1AFEB85B-BE65-4426-B156-CA7B3A7F63E9@gmail.com> <2134F8430051B64F815C691A62D9831820C3F4@XCH-BLV-504.nw.nos.boeing.com> <1CCE4779-47D4-4E03-A293-5108DDAC8A92@gmail.com> In-Reply-To: <1CCE4779-47D4-4E03-A293-5108DDAC8A92@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/_M1WNZ0Vk12K8Reujzebi14-q4I Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering draft text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 15:50:50 -0000 Hi Jouni, > -----Original Message----- > From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] > Sent: Wednesday, March 26, 2014 8:41 AM > To: Templin, Fred L > Cc: dmm@ietf.org > Subject: Re: [DMM] rechartering draft text updated >=20 >=20 > I hear you.. but this is what the original charter already said. > We deliberately scope the charter in a way that we could avoid > tunnelling between the end host and the access router. What I am suggesting entails tunneling *over* the access router and to a mobility gateway of some kind, or tunneling directly from end host to end host when route optimization is employed. The tunneling could be IPv6-over-IPv6 or IPv6-over-IPv4. Thanks - Fred fred.l.templin@boeing.com > - Jouni >=20 >=20 > On Mar 26, 2014, at 4:32 PM, "Templin, Fred L" wrote: >=20 > > Hi Jouni, > > > > In paragraph 5, it says: > > > > "At least IPv6 is assumed to be present in both the mobile host/router > > and the access networks." > > > > I disagree with the trailing phrase "and the access networks" > > since many access networks may remain as IPv4-only for a long > > time yet. It would satisfy my concern if the sentence were > > modified to simply drop the trailing phrase. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen > >> Sent: Wednesday, March 26, 2014 3:03 AM > >> To: dmm@ietf.org > >> Subject: [DMM] rechartering draft text updated > >> > >> Folks, > >> > >> Take a look at the latest revision. I have added the initial stab > >> for the milestones. Comments and flames are welcome. If you want > >> something to be changed, just propose text & diff. You might also > >> want to say why the change is needed. > >> > >> https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft= .txt > >> > >> - Jouni > >> > >> _______________________________________________ > >> dmm mailing list > >> dmm@ietf.org > >> https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Mar 26 08:59:53 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB5A1A0119 for ; Wed, 26 Mar 2014 08:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1G65pza3KY-z for ; Wed, 26 Mar 2014 08:59:49 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE751A00D9 for ; Wed, 26 Mar 2014 08:59:48 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id y1so1630770lam.23 for ; Wed, 26 Mar 2014 08:59:47 -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-type; bh=KiibYXj+pEnCIErvwEb8dexEV9kG3/b1wWoIDBef1AA=; b=ISS4p8PhK3gQgYFnVD5JA6ayrW/Nkx9OFLjXvUq5SlVqHC1HF5b8lN5MLcJc3GsOjT +KDFSpUGbU0Lp7RKQ+F66gJwsvREvfNLfeFlQ8gPj4oSmIHYL+3ChR0t68fxCIr6mNgW D8OSO0D5a2OJaB3ShbGnoAkKwfImB4JLgivaNqDcRf7hRwSE/QOGk6HwhNBae2Vh1xVc IWuoD2myF5rmaCWTTPnmzQgwhojS8qme985oMLrkg97YRfL6XPAfWclfjSyfai1cJ7vd J+5CSOlHz0morGJuvQYW2KwLG9ZRcYc+reoHqin184fE49N1wK2huXOKrQT2EJ5Qvv8x nvfQ== MIME-Version: 1.0 X-Received: by 10.153.7.69 with SMTP id da5mr2333882lad.38.1395849586969; Wed, 26 Mar 2014 08:59:46 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Wed, 26 Mar 2014 08:59:46 -0700 (PDT) In-Reply-To: <1AFEB85B-BE65-4426-B156-CA7B3A7F63E9@gmail.com> References: <1AFEB85B-BE65-4426-B156-CA7B3A7F63E9@gmail.com> Date: Wed, 26 Mar 2014 10:59:46 -0500 Message-ID: From: Behcet Sarikaya To: Jouni Korhonen Content-Type: multipart/alternative; boundary=001a11345630ca90a904f5848efb Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/ZZ5jtIFw-p0chUFjngaLyFe4t5k Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering draft text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 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, 26 Mar 2014 15:59:50 -0000 --001a11345630ca90a904f5848efb Content-Type: text/plain; charset=ISO-8859-1 Hi Jouni, Thanks for your hard work on the charter text. On Wed, Mar 26, 2014 at 5:02 AM, Jouni Korhonen wrote: > Folks, > > Take a look at the latest revision. I have added the initial stab > for the milestones. Comments and flames are welcome. If you want > something to be changed, just propose text & diff. You might also > want to say why the change is needed. > I don't understand why we have re-selection as a separate charter item? Do you have an example document, draft which would qualify for this item? I would also suggest taking currently available solution candidate, i.e. vEPC draft and please tell us how that document fits into this charter? Lastly, at the end of the charter a statement on rechartering or closing down is needed for technical reasons, I think. Regards, Behcet > > https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt > > - Jouni > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --001a11345630ca90a904f5848efb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jouni,

Thanks for your hard work on t= he charter text.



On Wed, Mar 26, 2014 at 5:02 AM, Jouni Korhonen <jouni.nos= pam@gmail.com> wrote:
Folks,

Take a look at the latest revision. I have added the initial stab
for the milestones. Comments and flames are welcome. If you want
something to be changed, just propose text & diff. You might also
want to say why the change is needed.

I= don't understand why we have re-selection as a separate charter item?<= br>
Do you have an example document, draft which would qualify fo= r this item?

I would also suggest taking currently available solution can= didate, i.e. vEPC draft and please tell us how that document fits into this= charter?
=A0

Lastly, at the end of the charter a stat= ement on rechartering or closing down is needed for technical reasons, I th= ink.

Regards,

Behcet

https://github.com/jounikor/dmm-re-charter/bl= ob/master/recharter_draft.txt

- Jouni

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

--001a11345630ca90a904f5848efb-- From nobody Wed Mar 26 11:11:42 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243A21A01CC for ; Wed, 26 Mar 2014 11:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvE6ZXMCmUz6 for ; Wed, 26 Mar 2014 11:11:30 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id BB3A21A01CA for ; Wed, 26 Mar 2014 11:11:30 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M85w9-1XFBgS3VYn-00wHvG; Wed, 26 Mar 2014 14:11:13 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Wed, 26 Mar 2014 20:11:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8A3C3E3E-9BDF-4C1C-A9E6-CBEAEB0CCEF4@yegin.org> References: <1AFEB85B-BE65-4426-B156-CA7B3A7F63E9@gmail.com> <14A3D3C1-975B-44F6-B413-39C532711C1A@yegin.org> To: Jouni Korhonen X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:dcXVhgX1P0pBImvgS8jW6VZtYtkRX0R2EtcsdlIulqN 7Hlb89VZtFPDYuiRBwHMNg0Ayh+3siKix01dWBrKSfDc+lZLhh NrglmSg1cjHMjtKfs4e+1FthOjk0MTBVF3Hrf1ZMnRBJRq2Rq5 W1vyRLNjEWmRu6MfJkJlZPffAGulq0XUZyu8p2uiH/rO5mIegF UOj00NYUNogx4Wd28BmCqEa7cqI7YJbomI8tyQ333fhzbj4nuh nlgztr1yDMQcHinh8E1NM1VMMElcofET+1lNCP6sWYVVySQImv 4cURVHGt4BJHgaIaMW6BIErLWvg24tBhZOvstJRAoI9YMPL1Mg 2p0B/2Pbbl02O9X2qEa10oXfsH589XdgXcbnop9DdxhvXw78Bb LQE0vuqARDlYg== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/74l15_hmyfpApvdpIH_Ph1jvExQ Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering draft text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 18:11:39 -0000 On Mar 26, 2014, at 5:47 PM, Jouni Korhonen wrote: >=20 > On Mar 26, 2014, at 5:08 PM, Alper Yegin = wrote: >=20 >> Hi Jouni, >>=20 >> DMM can be used to realise such a distributed deployment >> model, by distributing forwarding functions at optimal location; = for >> example, closer either to the mobile user or the corresponding = node. >>=20 >>=20 >> s/user/node >=20 > Ack. >=20 >>=20 >>=20 >> Although the maintenance of stable home address(es) and/or = prefix(es) >> and upper level sessions is a desirable goal when mobile = hosts/routers >> change their point of attachment to the Internet, it is not a = strict >> requirement. Mobile hosts/routers should not assume that IP >> addressing including home address(es) and/or home network = prefix(es) >> remain the same throughout the entire upper level session = lifetime, >> or that support for mobility functions is provided on the = network side >> in all conditions, unless these properties are specifically = indicated >> to the mobile node and its applications from the network. >>=20 >> Is this trying to say "the network may not be able to provide a = stable IP address to the MN"? >> Even in the presence of a DMM solution? >=20 > Yes.. it is imho a valid use case that the mn just does not care all = addresses having mobility. The DMM solution may provide stable address = only for a subset of addresses available for the mn. >=20 >>=20 >> Mar 2014 - Submit 'The deployment models and scenarios' submitted to = the IESG. >> To be Informational RFC. >> Marc 2014 - Submit 'Enhanced gateway and mobility anchor selection' = submitted to the >> IESG. To be Proposed Standard. >>=20 >> I guess these are meant to be 2015. >=20 > Uhh.. yes. (copy-paste is always dangerous) >=20 >>=20 >> Btw, the milestones do not seem to have an item to cover for = "Forwarding path and signalling management" >=20 > Not at this point. Two reasons: I could not figure a good name for the = milestone and also was a bit concerned whether we would have all the = energy to work on this many documents in parallel. >=20 Jouni, that is the essential deliverable of the DMM WG, IMO. Alper > - Jouni >=20 >=20 >>=20 >> Thanks Jouni >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Mar 26, 2014, at 12:02 PM, Jouni Korhonen wrote: >>=20 >>> Folks, >>>=20 >>> Take a look at the latest revision. I have added the initial stab >>> for the milestones. Comments and flames are welcome. If you want >>> something to be changed, just propose text & diff. You might also >>> want to say why the change is needed. >>>=20 >>> = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >>>=20 >>> - Jouni >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>=20 >=20 From nobody Wed Mar 26 11:26:04 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018811A0345 for ; Wed, 26 Mar 2014 11:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKMKNGDgSMVI for ; Wed, 26 Mar 2014 11:26:01 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id DA02B1A0320 for ; Wed, 26 Mar 2014 11:26:00 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id ec20so1794176lab.39 for ; Wed, 26 Mar 2014 11:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AxgvGdrW4BlpS7FHgjSrAKkH1d+JiqhiPtv7c5iwOw8=; b=QlhjIQGE/vu334RHlqkUUtYDTyp2la6PZacHs94ePWYTkOS0G7nj5ZJK5QbjJ81wBw ugsKXM5sMNYsKbOaU0dTVYQmAAGJJQiOaldoN3RvifEBvLeUlw4e3gyYoDABOTHCrwSK shUwUlEd2rcFqT+rc6jeB1kac4pp3uCREDY6sDLt4dsWFMYmhpo8lNeO4uteliz3dQOg jJ0aJDuwlu4+sY+JJDp1lMi06gPy3LEInGz2iY56xafaiPHv7n0TVY3Iyj7a1VcclcZ/ hH702eidqX+kM2rZULCwaJB+EAprU5grJsNaMK00uj9kK7pIk3kLdhTDAkCVkj3uulRH 2bCg== X-Received: by 10.112.52.225 with SMTP id w1mr48382672lbo.22.1395858358488; Wed, 26 Mar 2014 11:25:58 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:6535:f4ba:8838:7db6? ([2001:1bc8:101:f101:6535:f4ba:8838:7db6]) by mx.google.com with ESMTPSA id d4sm14523558lbr.27.2014.03.26.11.25.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Mar 2014 11:25:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: <8A3C3E3E-9BDF-4C1C-A9E6-CBEAEB0CCEF4@yegin.org> Date: Wed, 26 Mar 2014 20:25:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <92AC68FB-2280-4A17-BCC1-C768A0D6EDD6@gmail.com> References: <1AFEB85B-BE65-4426-B156-CA7B3A7F63E9@gmail.com> <14A3D3C1-975B-44F6-B413-39C532711C1A@yegin.org> <8A3C3E3E-9BDF-4C1C-A9E6-CBEAEB0CCEF4@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/-hQJveolS1h8rKjvlrrv73WTcfk Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering draft text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 18:26:03 -0000 On Mar 26, 2014, at 8:11 PM, Alper Yegin wrote: >=20 > On Mar 26, 2014, at 5:47 PM, Jouni Korhonen wrote: >=20 >>=20 >> On Mar 26, 2014, at 5:08 PM, Alper Yegin = wrote: >>=20 >>> Hi Jouni, >>>=20 >>> DMM can be used to realise such a distributed deployment >>> model, by distributing forwarding functions at optimal location; = for >>> example, closer either to the mobile user or the corresponding = node. >>>=20 >>>=20 >>> s/user/node >>=20 >> Ack. >>=20 >>>=20 >>>=20 >>> Although the maintenance of stable home address(es) and/or = prefix(es) >>> and upper level sessions is a desirable goal when mobile = hosts/routers >>> change their point of attachment to the Internet, it is not a = strict >>> requirement. Mobile hosts/routers should not assume that IP >>> addressing including home address(es) and/or home network = prefix(es) >>> remain the same throughout the entire upper level session = lifetime, >>> or that support for mobility functions is provided on the = network side >>> in all conditions, unless these properties are specifically = indicated >>> to the mobile node and its applications from the network. >>>=20 >>> Is this trying to say "the network may not be able to provide a = stable IP address to the MN"? >>> Even in the presence of a DMM solution? >>=20 >> Yes.. it is imho a valid use case that the mn just does not care all = addresses having mobility. The DMM solution may provide stable address = only for a subset of addresses available for the mn. >>=20 >>>=20 >>> Mar 2014 - Submit 'The deployment models and scenarios' submitted to = the IESG. >>> To be Informational RFC. >>> Marc 2014 - Submit 'Enhanced gateway and mobility anchor selection' = submitted to the >>> IESG. To be Proposed Standard. >>>=20 >>> I guess these are meant to be 2015. >>=20 >> Uhh.. yes. (copy-paste is always dangerous) >>=20 >>>=20 >>> Btw, the milestones do not seem to have an item to cover for = "Forwarding path and signalling management" >>=20 >> Not at this point. Two reasons: I could not figure a good name for = the milestone and also was a bit concerned whether we would have all the = energy to work on this many documents in parallel. >>=20 >=20 > Jouni, that is the essential deliverable of the DMM WG, IMO. And how you would like to see that milestone to be formulated here? Give some text us to jump into.. Cheers, 2001:db8::4a:6f75:6e69 >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 >> - Jouni >>=20 >>=20 >>>=20 >>> Thanks Jouni >>>=20 >>> Alper >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Mar 26, 2014, at 12:02 PM, Jouni Korhonen wrote: >>>=20 >>>> Folks, >>>>=20 >>>> Take a look at the latest revision. I have added the initial stab >>>> for the milestones. Comments and flames are welcome. If you want >>>> something to be changed, just propose text & diff. You might also >>>> want to say why the change is needed. >>>>=20 >>>> = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >>>>=20 >>>> - Jouni >>>>=20 >>>> _______________________________________________ >>>> dmm mailing list >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >>>=20 >>=20 >=20 From nobody Thu Mar 27 00:06:03 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F311A046A for ; Thu, 27 Mar 2014 00:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3H0KJmrE6zOg for ; Thu, 27 Mar 2014 00:05:24 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id BC7E61A0471 for ; Thu, 27 Mar 2014 00:05:23 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LgpxO-1WpWt03q46-00o6Af; Thu, 27 Mar 2014 03:05:21 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_3033EDA7-496C-4252-B80E-91FD66FA672B" From: Alper Yegin In-Reply-To: <92AC68FB-2280-4A17-BCC1-C768A0D6EDD6@gmail.com> Date: Thu, 27 Mar 2014 09:05:13 +0200 Message-Id: References: <1AFEB85B-BE65-4426-B156-CA7B3A7F63E9@gmail.com> <14A3D3C1-975B-44F6-B413-39C532711C1A@yegin.org> <8A3C3E3E-9BDF-4C1C-A9E6-CBEAEB0CCEF4@yegin.org> <92AC68FB-2280-4A17-BCC1-C768A0D6EDD6@gmail.com> To: Jouni X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:iDe2MpyfrenVKquh/qlD04dSLT8YmEokZGQ/QzCLznr vzIM/96swWZxlTFxXRZhkdC5pf+9Mvkipwl+jG4rf8/dAtJI9c F5ysetpq4auAD0HYLZBUiPhr9F/Q/QnU9BgxOxj8lp5TPogdnJ 2IGf+9oDzwNQkE9Apcp7Typf4OWAGeq6a2zA3t4HKK9IQwANj8 5ZUpDwmQykEnzrPeshu9TViP/ByiYudHWtgZdYbPzwf1usTMNO TwU9y+e2WgoQ6DVriVlHaBANloNAK6OcbhaOu1m83buGYsZr1K Z1d9O45GHD7tnKGP/FqkKpAE8nXbl5HXiNHkHHiPhIBBX/5tfu pjvvC7xq4HWTPv2rQLQoPCdfK+3DW0w9+UPm1mkY96z/05eMEb gysylF3HaVyWg== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/KnDyfejF3Sf00QFhr-gxwX5dlSs Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering draft text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 07:05:35 -0000 X-List-Received-Date: Thu, 27 Mar 2014 07:05:35 -0000 --Apple-Mail=_3033EDA7-496C-4252-B80E-91FD66FA672B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii You already have text for that: "Forwarding path and signalling = management" You can use that name for the deliverable. Alper On Mar 26, 2014, at 8:25 PM, Jouni wrote: >=20 > On Mar 26, 2014, at 8:11 PM, Alper Yegin wrote: >=20 >>=20 >> On Mar 26, 2014, at 5:47 PM, Jouni Korhonen wrote: >>=20 >>>=20 >>> On Mar 26, 2014, at 5:08 PM, Alper Yegin = wrote: >>>=20 >>>> Hi Jouni, >>>>=20 >>>> DMM can be used to realise such a distributed deployment >>>> model, by distributing forwarding functions at optimal location; = for >>>> example, closer either to the mobile user or the corresponding = node. >>>>=20 >>>>=20 >>>> s/user/node >>>=20 >>> Ack. >>>=20 >>>>=20 >>>>=20 >>>> Although the maintenance of stable home address(es) and/or = prefix(es) >>>> and upper level sessions is a desirable goal when mobile = hosts/routers >>>> change their point of attachment to the Internet, it is not a = strict >>>> requirement. Mobile hosts/routers should not assume that IP >>>> addressing including home address(es) and/or home network = prefix(es) >>>> remain the same throughout the entire upper level session = lifetime, >>>> or that support for mobility functions is provided on the = network side >>>> in all conditions, unless these properties are specifically = indicated >>>> to the mobile node and its applications from the network. >>>>=20 >>>> Is this trying to say "the network may not be able to provide a = stable IP address to the MN"? >>>> Even in the presence of a DMM solution? >>>=20 >>> Yes.. it is imho a valid use case that the mn just does not care all = addresses having mobility. The DMM solution may provide stable address = only for a subset of addresses available for the mn. >>>=20 >>>>=20 >>>> Mar 2014 - Submit 'The deployment models and scenarios' submitted = to the IESG. >>>> To be Informational RFC. >>>> Marc 2014 - Submit 'Enhanced gateway and mobility anchor selection' = submitted to the >>>> IESG. To be Proposed Standard. >>>>=20 >>>> I guess these are meant to be 2015. >>>=20 >>> Uhh.. yes. (copy-paste is always dangerous) >>>=20 >>>>=20 >>>> Btw, the milestones do not seem to have an item to cover for = "Forwarding path and signalling management" >>>=20 >>> Not at this point. Two reasons: I could not figure a good name for = the milestone and also was a bit concerned whether we would have all the = energy to work on this many documents in parallel. >>>=20 >>=20 >> Jouni, that is the essential deliverable of the DMM WG, IMO. >=20 > And how you would like to see that milestone to be formulated here? > Give some text us to jump into.. >=20 > Cheers, > 2001:db8::4a:6f75:6e69 >=20 >=20 >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> - Jouni >>>=20 >>>=20 >>>>=20 >>>> Thanks Jouni >>>>=20 >>>> Alper >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Mar 26, 2014, at 12:02 PM, Jouni Korhonen wrote: >>>>=20 >>>>> Folks, >>>>>=20 >>>>> Take a look at the latest revision. I have added the initial stab >>>>> for the milestones. Comments and flames are welcome. If you want >>>>> something to be changed, just propose text & diff. You might also >>>>> want to say why the change is needed. >>>>>=20 >>>>> = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >>>>>=20 >>>>> - Jouni >>>>>=20 >>>>> _______________________________________________ >>>>> dmm mailing list >>>>> dmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_3033EDA7-496C-4252-B80E-91FD66FA672B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii You = already have text for that: "

You can use that name for the = deliverable.

Alper





On Mar 26, = 2014, at 8:25 PM, Jouni wrote:


On = Mar 26, 2014, at 8:11 PM, Alper Yegin wrote:


On Mar 26, = 2014, at 5:47 PM, Jouni Korhonen wrote:


On Mar 26, 2014, at 5:08 PM, = Alper Yegin <alper.yegin@yegin.org> = wrote:

Hi = Jouni,

=    DMM can be used to realise such a distributed = deployment
=    model, by distributing forwarding functions at optimal = location; for
=    example, closer either to the mobile user or the = corresponding = node.


s/user/node

Ack.



=    Although the maintenance of stable home address(es) = and/or prefix(es)
=    and upper level sessions is a desirable goal when = mobile = hosts/routers
=    change their point of attachment to the Internet, it = is not a strict
=    requirement. Mobile hosts/routers should not assume = that IP
=    addressing including home address(es) and/or home = network prefix(es)
=    remain the same throughout the entire upper level = session lifetime,
=    or that support for mobility functions is provided on = the network side
=    in all conditions, unless these properties are = specifically = indicated
=    to the mobile node and its applications from the = network.

Is = this trying to say "the network may not be able to provide a stable IP = address to the = MN"?
Even = in the presence of a DMM = solution?

Yes.. it is imho a valid use = case that the mn just does not care all addresses having mobility. The = DMM solution may provide stable address only for a subset of addresses = available for the mn.


Mar = 2014 - Submit 'The deployment models and scenarios' submitted to the = IESG.
=             &n= bsp;    To be Informational = RFC.
Marc = 2014 - Submit 'Enhanced gateway and mobility anchor selection' submitted = to the
=             &n= bsp;    IESG. To be Proposed = Standard.

I = guess these are meant to be = 2015.

Uhh.. yes. (copy-paste is always = dangerous)


Btw, = the milestones do not seem to have an item to cover for "Forwarding path = and signalling = management"

Not at this point. Two reasons: = I could not figure a good name for the milestone and also was a bit = concerned whether we would have all the energy to work on this many = documents in parallel.


Jouni, that is = the essential deliverable of the DMM WG, IMO.

And = how you would like to see that milestone to be formulated here?
Give = some text us to jump into..

Cheers,
= 2001:db8::4a:6f75:6e69



Alper






- Jouni



Thanks = Jouni

Alper







On Mar = 26, 2014, at 12:02 PM, Jouni Korhonen = wrote:

Folks,

Take a look at the latest = revision. I have added the initial = stab
for the milestones. Comments and = flames are welcome. If you = want
something to be changed, just = propose text & diff. You might = also
want to say why the change is = needed.

https://github.com/jounikor/dmm-re-charter/blob/master/recharter= _draft.txt

- = Jouni

_______________________________________________
dmm mailing = list
dmm@ietf.org
https://www.ietf.org/ma= ilman/listinfo/dmm





= --Apple-Mail=_3033EDA7-496C-4252-B80E-91FD66FA672B-- From nobody Thu Mar 27 00:31:09 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425EC1A02C7 for ; Thu, 27 Mar 2014 00:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4zRejKMXk6J for ; Thu, 27 Mar 2014 00:31:06 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B57541A02C4 for ; Thu, 27 Mar 2014 00:31:05 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id hr13so2323114lab.31 for ; Thu, 27 Mar 2014 00:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xnNALIGpjDynjUTPA/CsEdeu+/qwLMrW3BvzL1AX3F8=; b=NpWXtzOJ3p0r+iPFx4cepFUnDFHCiO7o7h5wHuDU/yIsT5EBs9hy5yJRP3RqF+Z+zm wphOinXBDRwU+2bK/yby9rAk6zGhPT6irATAeAofYXKcYcvuaHup5jAbtu+C7ZhuHIm0 SYYr9qogqc6YI+ZalN1jfGjJ2Hdmv9VHJ9FMpB6dCkSjVrkMt3Wpx7obtVskLI9J8edm Odn9mLSwbk2hE1qTo2vtqDnJGYii5EQa8sP1hIFdPhqzYv5A7ai3IVMe6Gow/KvQZwQq BttW25mad7jl0uEGVufGpajfHXo5yLlL1tDIG7XOBjUfpPCn4Px8wrOHD5qxPFEjnU7R Besw== X-Received: by 10.152.22.72 with SMTP id b8mr63239laf.63.1395905463421; Thu, 27 Mar 2014 00:31:03 -0700 (PDT) Received: from [192.168.250.130] ([194.100.71.98]) by mx.google.com with ESMTPSA id bm3sm834151lbb.12.2014.03.27.00.30.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Mar 2014 00:31:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: Date: Thu, 27 Mar 2014 09:30:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1AFEB85B-BE65-4426-B156-CA7B3A7F63E9@gmail.com> <14A3D3C1-975B-44F6-B413-39C532711C1A@yegin.org> <8A3C3E3E-9BDF-4C1C-A9E6-CBEAEB0CCEF4@yegin.org> <92AC68FB-2280-4A17-BCC1-C768A0D6EDD6@gmail.com> To: Alper Yegin X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/KbhcBO04-Vj7BPypx_1ZRle7mNk Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering draft text updated X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 07:31:08 -0000 On Mar 27, 2014, at 9:05 AM, Alper Yegin wrote: > You already have text for that: "Forwarding path and signalling = management" >=20 > You can use that name for the deliverable. Right. I was, though, expecting something that I could copy-paste = directly. Any desires for timelines? Cheers, 49.1972.0112.1111.1711.0105.00 >=20 > Alper >=20 >=20 >=20 >=20 >=20 > On Mar 26, 2014, at 8:25 PM, Jouni wrote: >=20 >>=20 >> On Mar 26, 2014, at 8:11 PM, Alper Yegin wrote: >>=20 >>>=20 >>> On Mar 26, 2014, at 5:47 PM, Jouni Korhonen wrote: >>>=20 >>>>=20 >>>> On Mar 26, 2014, at 5:08 PM, Alper Yegin = wrote: >>>>=20 >>>>> Hi Jouni, >>>>>=20 >>>>> DMM can be used to realise such a distributed deployment >>>>> model, by distributing forwarding functions at optimal = location; for >>>>> example, closer either to the mobile user or the corresponding = node. >>>>>=20 >>>>>=20 >>>>> s/user/node >>>>=20 >>>> Ack. >>>>=20 >>>>>=20 >>>>>=20 >>>>> Although the maintenance of stable home address(es) and/or = prefix(es) >>>>> and upper level sessions is a desirable goal when mobile = hosts/routers >>>>> change their point of attachment to the Internet, it is not a = strict >>>>> requirement. Mobile hosts/routers should not assume that IP >>>>> addressing including home address(es) and/or home network = prefix(es) >>>>> remain the same throughout the entire upper level session = lifetime, >>>>> or that support for mobility functions is provided on the = network side >>>>> in all conditions, unless these properties are specifically = indicated >>>>> to the mobile node and its applications from the network. >>>>>=20 >>>>> Is this trying to say "the network may not be able to provide a = stable IP address to the MN"? >>>>> Even in the presence of a DMM solution? >>>>=20 >>>> Yes.. it is imho a valid use case that the mn just does not care = all addresses having mobility. The DMM solution may provide stable = address only for a subset of addresses available for the mn. >>>>=20 >>>>>=20 >>>>> Mar 2014 - Submit 'The deployment models and scenarios' submitted = to the IESG. >>>>> To be Informational RFC. >>>>> Marc 2014 - Submit 'Enhanced gateway and mobility anchor = selection' submitted to the >>>>> IESG. To be Proposed Standard. >>>>>=20 >>>>> I guess these are meant to be 2015. >>>>=20 >>>> Uhh.. yes. (copy-paste is always dangerous) >>>>=20 >>>>>=20 >>>>> Btw, the milestones do not seem to have an item to cover for = "Forwarding path and signalling management" >>>>=20 >>>> Not at this point. Two reasons: I could not figure a good name for = the milestone and also was a bit concerned whether we would have all the = energy to work on this many documents in parallel. >>>>=20 >>>=20 >>> Jouni, that is the essential deliverable of the DMM WG, IMO. >>=20 >> And how you would like to see that milestone to be formulated here? >> Give some text us to jump into.. >>=20 >> Cheers, >> 2001:db8::4a:6f75:6e69 >>=20 >>=20 >>>=20 >>> Alper >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> - Jouni >>>>=20 >>>>=20 >>>>>=20 >>>>> Thanks Jouni >>>>>=20 >>>>> Alper >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Mar 26, 2014, at 12:02 PM, Jouni Korhonen wrote: >>>>>=20 >>>>>> Folks, >>>>>>=20 >>>>>> Take a look at the latest revision. I have added the initial stab >>>>>> for the milestones. Comments and flames are welcome. If you want >>>>>> something to be changed, just propose text & diff. You might also >>>>>> want to say why the change is needed. >>>>>>=20 >>>>>> = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >>>>>>=20 >>>>>> - Jouni >>>>>>=20 >>>>>> _______________________________________________ >>>>>> dmm mailing list >>>>>> dmm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From nobody Thu Mar 27 12:51:14 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898991A0760 for ; Thu, 27 Mar 2014 12:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZ6P2AbC4TZi for ; Thu, 27 Mar 2014 12:51:12 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6831A074D for ; Thu, 27 Mar 2014 12:51:10 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id c11so3040273lbj.3 for ; Thu, 27 Mar 2014 12:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=MkfPBJ0BJwoI95w2iWl7aVhq5t4Pw96J3Z+3ff11UTQ=; b=zLGwVwZTi1gCMCx7dRDxgQ7uEG461HaETtr6fGrsHyQXYFK3qHFhmwIpSBNwg5N61z svzQ7o+TK/HckcXVvaA2fZj6CcBawkkMpFfD/FtC9UqSRqVoSlifx1j2vLu4ZVC6jsC6 Q5K2U2/gyO8/SAPEuwbEQeg1Q+wJNVwar0xIMzhz4i0OeHxrS2RmqNfmK9FD7Rm8nW3O sJgDtyZknHJpgLKX9/UfoaqI3thu6aXv4xcu9aBZqSnbGEtkzpQy/T1e04AluUgDR7tD LIJ824aoXRxJ5ubOsHbzFR9x8YGnIQUQYPOhSNM8fanku+rhHSXEXZn6QvzRuYxEwZ8Y fL3Q== MIME-Version: 1.0 X-Received: by 10.112.128.231 with SMTP id nr7mr2060383lbb.9.1395949868255; Thu, 27 Mar 2014 12:51:08 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Thu, 27 Mar 2014 12:51:08 -0700 (PDT) Date: Thu, 27 Mar 2014 14:51:08 -0500 Message-ID: From: Behcet Sarikaya To: "dmm@ietf.org" Content-Type: multipart/alternative; boundary=047d7b343d20058e3304f59be80a Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/PpNDowvh_x-_HYJPSuqWmANN1fE Subject: [DMM] rechartering draft comments X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 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, 27 Mar 2014 19:51:13 -0000 --047d7b343d20058e3304f59be80a Content-Type: text/plain; charset=ISO-8859-1 |The DMM working group will also work on maintenance-oriented and | incremental extensions to the Proxy Mobile IPv6 protocol, specified | in RFC 5213 and RFC 5844. The Proxy Mobile IPv6 work primarily | addresses any protocol gaps required to support existing |deployments | and other standards development organizations using the Proxy |Mobile | IPv6 protocol in their system architectures. Add Mobile IPv6 or remove the whole paragraph | |Enhanced gateway & mobility anchor selection and re-selection: define | protocol solutions for a gateway and mobility anchor selection that | go beyond what has been, for example, described in RFC 6097. |The | solution should also define a mechanism for anchor re-selection |that allow | preserving ongoing mobility sessions in a single administrative |domain. Based on the above paragraph we have two charter items which basically make up the dmm solution. What is the justification? Is it RFC 6097 (no offense to you Jouni)? What about dmm solution that do not require any anchoring? What about SDN, NFV ideas that have been expressed by Dapeng and others? Sorry but I don't see any enthusiasm on this charter draft in the WG. Behcet --047d7b343d20058e3304f59be80a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
|The DMM working group will al= so work on maintenance-oriented and
|=A0= =A0=A0=A0 incremental extensions to the Proxy Mobile IPv6 protocol, specifi= ed
|=A0=A0=A0=A0 in RFC 5213 and RFC 5844. The Proxy Mobile IPv6 work primaril= y
|=A0=A0=A0=A0=A0 addresses any protocol = gaps required to support existing |deployments
=A0| =A0=A0=A0 and other standards development organizations using the= Proxy |Mobile
|=A0=A0=A0=A0=A0 IPv6 protocol in their system = architectures.


Add Mobile IPv6 or remove the whole paragraph

|
|Enhanced gateway & mobility anchor selection and re-selection: define =
|=A0=A0=A0=A0=A0=A0 protocol solutions fo= r a gateway and mobility anchor selection that
|=A0=A0=A0=A0=A0=A0 go beyond what has been, for example, described in= RFC 6097. |The
|=A0=A0=A0=A0=A0=A0=A0 solution should also define a mechanism for anchor r= e-selection |that allow
=A0| =A0=A0=A0=A0= =A0 preserving ongoing mobility sessions in a single administrative |domain= .

Based on the above paragraph we have = two charter items which basically make up the dmm solution.

What is the justification? Is it RFC 6097 (no off= ense to you Jouni)?
What about dmm solution that do not requi= re any anchoring?
What about SDN, NFV = ideas that have been expressed by Dapeng and others?

Sorry but I don't see any enthusiasm on this charter draft in the WG.
Behcet

--047d7b343d20058e3304f59be80a-- From nobody Thu Mar 27 14:26:40 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC751A03BE for ; Thu, 27 Mar 2014 14:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGcOypV1_wzQ for ; Thu, 27 Mar 2014 14:26:38 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id AFCE71A037E for ; Thu, 27 Mar 2014 14:26:37 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id hr13so3134067lab.3 for ; Thu, 27 Mar 2014 14:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=w9wjUA8h7dqVKKR2gLce3oZLF+pBAnWcNjRSSVBy7L0=; b=KzKBoSwDmTShUugLd8fES2zFuwrv5VlRKm0rI5VsQLxOap5wMhFg4Vs2T5izkOzKd4 s8y7DCycfLp5GvmH5hIw+nhm1uxaPIJtUtyDlOx8tY5OyJEAwCEowQaii8RLEr0yM8vC tavZ7p7MvAZWXMDuQgzYKFrgApe6wn26mquOR5e+trTZza3zj5uev4Z8Islxcq4ierA0 xSjxI6LHkwdHKbDKyLL83yhLX4NgfAUiPHaBKGBk5PZLhpgjuYwsg76i71Z3HegEIG3r 2VwiW/Ei1lIRqBe11NsWxiQWfEtLaC4Znawa0s3nAcZef/XQWnuFKAhaxu/4qo0BpY+/ 36NQ== X-Received: by 10.152.87.71 with SMTP id v7mr2535495laz.10.1395955594936; Thu, 27 Mar 2014 14:26:34 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:14cc:287d:1f40:b47c? ([2001:1bc8:101:f101:14cc:287d:1f40:b47c]) by mx.google.com with ESMTPSA id z10sm2216624lbu.1.2014.03.27.14.26.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Mar 2014 14:26:33 -0700 (PDT) Message-ID: <53349789.10901@gmail.com> Date: Thu, 27 Mar 2014 23:26:33 +0200 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: sarikaya@ieee.org, "dmm@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/bAryDg7fiSIestqrwKaEvwe2c0c Subject: Re: [DMM] rechartering draft comments X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 21:26:39 -0000 Behcet, Thank you for constructive feedback. See inline. 3/27/2014 9:51 PM, Behcet Sarikaya kirjoitti: > |The DMM working group will also work on maintenance-oriented and > | incremental extensions to the Proxy Mobile IPv6 protocol, specified > | in RFC 5213 and RFC 5844. The Proxy Mobile IPv6 work primarily > | addresses any protocol gaps required to support existing > |deployments > | and other standards development organizations using the Proxy > |Mobile > | IPv6 protocol in their system architectures. > > > Add Mobile IPv6 or remove the whole paragraph I see no point even trying to work on client mobile ipv6 enhancements.. > |Enhanced gateway & mobility anchor selection and re-selection: define > | protocol solutions for a gateway and mobility anchor selection > that > | go beyond what has been, for example, described in RFC 6097. |The > | solution should also define a mechanism for anchor > re-selection |that allow > | preserving ongoing mobility sessions in a single > administrative |domain. > > Based on the above paragraph we have two charter items which basically > make up the dmm solution. > > What is the justification? Is it RFC 6097 (no offense to you Jouni)? You know that it just happens to be the only RFC even attempting to explain how LMAs are selected dynamically. If the reference here is contentious, I am happy to remore it.. just give me alternative text. > What about dmm solution that do not require any anchoring In scope and in the current text. > What about SDN, NFV ideas that have been expressed by Dapeng and others? Not explicitly mentioned by those hype terms but not prohibited either in the charter text. > Sorry but I don't see any enthusiasm on this charter draft in the WG. Then help bring in the enthusiams. The easiest way is to provide explicit text that we can then evaluate. - Jouni > > Behcet > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Mar 27 14:40:22 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AD81A06A8 for ; Thu, 27 Mar 2014 14:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsG_pA7wpaAL for ; Thu, 27 Mar 2014 14:40:18 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE7B1A03F6 for ; Thu, 27 Mar 2014 14:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=630; q=dns/txt; s=iport; t=1395956416; x=1397166016; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=kn2y0TKr4w3JdDwWC4BAT8/z9//Ns3vvweLr9haILVc=; b=ZHsLjnBPggb6SSH657toIwQr6U/0Mh6GOnS2FkMauZq8mgJaln7QufaT ofVUuJr2YZJ6WD5EkZJi+bGtY77VdAFbW4Srguy/d/NKvnkThzBaoWbtC O6kw6U0o9e9RQZiFlWVqqFwDJ7tYk+9kdhGlVTo85DBoWX2fVynV68DJC k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAEaaNFOtJV2Y/2dsb2JhbABZgwaBEsJegR8WdIIsOlEBCDYxESUCBAESh2UDEcocDYcrF4xdgiSEOAEDlmCBbYxqhUqDL4Ir X-IronPort-AV: E=Sophos;i="4.97,745,1389744000"; d="scan'208";a="30965088" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP; 27 Mar 2014 21:40:16 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2RLeG0L024888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Mar 2014 21:40:16 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.56]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Thu, 27 Mar 2014 16:40:16 -0500 From: "Sri Gundavelli (sgundave)" To: Jouni Korhonen , "sarikaya@ieee.org" , "dmm@ietf.org" Thread-Topic: [DMM] rechartering draft comments Thread-Index: AQHPSgUjTFK1kX28EU+xG1rvE6x2dw== Date: Thu, 27 Mar 2014 21:40:14 +0000 Message-ID: In-Reply-To: <53349789.10901@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.211] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Wjg-7_Bc9MWba9Y_92Q6r8VWQy0 Subject: Re: [DMM] rechartering draft comments X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 21:40:20 -0000 On 3/27/14 2:26 PM, "Jouni Korhonen" wrote: > >You know that it just happens to be the only RFC even attempting to >explain >how LMAs are selected dynamically. If the reference here is contentious, >I am >happy to remore it.. just give me alternative text. I agree. RFC6097 and RFC6463 are relevant to the above work item. It is possible the WG may (most likely) adopt newer approaches for gateway selection, but a reference to the prior work is very much relevant. It is a very relevant reference. We do want to leverage work where possible. I'm fine with this. Regards Sri From nobody Thu Mar 27 14:58:02 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65BE1A06B2 for ; Thu, 27 Mar 2014 14:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLzU4CWPwpYy for ; Thu, 27 Mar 2014 14:57:34 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id D52ED1A03E1 for ; Thu, 27 Mar 2014 14:57:33 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MH0Fm-1WGezr34wk-00DLBM; Thu, 27 Mar 2014 17:57:31 -0400 From: Alper Yegin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Mar 2014 23:57:28 +0200 Message-Id: To: dmm@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:aqVXgbl0UQsWYWyDPXYJ5VpThd+e+eOvvN00kgmGAx8 ABFN9YChFf2V9Bwmy1v4saoFZvzRmhR6uhiTygA+doDDrszrTK FR67u3C1thTUu4wnGcAcIa7kE/2FtLSv0pR6v9LQEul5dRepBI cRHfB/1PWuA1GAxGQXdRbkkIwl+oFroPD066xK+UfBzGG8HIvK 1Ufp3RG1Bs45zBQ8vofK8afqTQBBY7zMtxBEtwfUKE1wBR3BV4 Sa+uZ+/6ucDdqPBxZbu61nsRRUjo+OTs4SrBg1m1JqvekKJVDD kRl9Xp7+Mzekqs5Ed9ftuty3Tni76KbPQIeoIftWaATK0qSLxI c68qKrobcbwYwPZnBggaUAwBo3yhb958dP4ECXRjt3OyNGWFTK bdwAlMrTuETFg== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/KsJKGtl_REv60cQJk_mR7DsRBgc Subject: [DMM] Next-Gen Mobility Protocols and Architectures Webex call #2 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 21:58:01 -0000 Folks, The second call is for Pete to present = http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00. There are three candidate dates from next week. Please use the following = doodle to mark the dates that work for you. http://doodle.com/um7cwnrk3ekid4pa Doodle deadline is the end of next Monday (March 31). Alper From nobody Thu Mar 27 15:18:26 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD921A03DA for ; Thu, 27 Mar 2014 15:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bb9Dz2xafBCv for ; Thu, 27 Mar 2014 15:18:21 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 629A81A06A8 for ; Thu, 27 Mar 2014 15:18:20 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id y1so3104960lam.37 for ; Thu, 27 Mar 2014 15:18:17 -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-type; bh=GSjGw2O4R8hV2FGLwCS/cqdZFWX6Lrhlm4B5l7Y6bP4=; b=fSW07szYO7OF/rQnZFWW/DQww9/kKPR1po7iwaIiXn8ioZhXVl7O7+sqslfHfDP2/j 4OxPDm0NMXr/LJ87OmS9p8FLQ2RNblr3Gmfo/5o89X7jfnDD4mrMYoW1QRyk7wNjRsRU 7Yn30esJ5G/kklGDEoL1TyiG+we0oQhykZNpowQS1fIgRIhtCtdcBL85fzShCEKEyHb+ MWdsyYElTleqN473WyvJqlsFnpVm+CG82P4rpbksPsNp0u1U/udjYhXMYrzYvPDWzOFn IzvjH+XaJLgK/We95yG2j95k1voP8cmF0li1/AqOMhn9VAkeiGuDYGh0K7g1PbBiGJmU mJFQ== MIME-Version: 1.0 X-Received: by 10.152.184.66 with SMTP id es2mr2703953lac.22.1395958697807; Thu, 27 Mar 2014 15:18:17 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Thu, 27 Mar 2014 15:18:17 -0700 (PDT) In-Reply-To: <53349789.10901@gmail.com> References: <53349789.10901@gmail.com> Date: Thu, 27 Mar 2014 17:18:17 -0500 Message-ID: From: Behcet Sarikaya To: Jouni Korhonen Content-Type: multipart/alternative; boundary=001a1135e20c4dd20504f59df60f Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/XfrF44ayBy4U0J4cbQLjlMV66mM Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering draft comments X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 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, 27 Mar 2014 22:18:23 -0000 --001a1135e20c4dd20504f59df60f Content-Type: text/plain; charset=ISO-8859-1 Hi Jouni, See inline. On Thu, Mar 27, 2014 at 4:26 PM, Jouni Korhonen wrote: > Behcet, > > Thank you for constructive feedback. See inline. > > 3/27/2014 9:51 PM, Behcet Sarikaya kirjoitti: > > |The DMM working group will also work on maintenance-oriented and >> | incremental extensions to the Proxy Mobile IPv6 protocol, specified >> | in RFC 5213 and RFC 5844. The Proxy Mobile IPv6 work primarily >> | addresses any protocol gaps required to support existing >> |deployments >> | and other standards development organizations using the Proxy >> |Mobile >> | IPv6 protocol in their system architectures. >> >> >> Add Mobile IPv6 or remove the whole paragraph >> > > I see no point even trying to work on client mobile ipv6 enhancements.. > > 3GPP may need it in the context of DSMIPv6, just like PMIPv6. > > |Enhanced gateway & mobility anchor selection and re-selection: define >> | protocol solutions for a gateway and mobility anchor selection >> that >> | go beyond what has been, for example, described in RFC 6097. |The >> | solution should also define a mechanism for anchor re-selection >> |that allow >> | preserving ongoing mobility sessions in a single administrative >> |domain. >> >> Based on the above paragraph we have two charter items which basically >> make up the dmm solution. >> >> What is the justification? Is it RFC 6097 (no offense to you Jouni)? >> > > You know that it just happens to be the only RFC even attempting to explain > how LMAs are selected dynamically. If the reference here is contentious, I > am > happy to remore it.. just give me alternative text. > > > What about dmm solution that do not require any anchoring >> > > In scope and in the current text. > > Where? I don't think any text counts as long as it is not in the milestones. > > What about SDN, NFV ideas that have been expressed by Dapeng and others? >> > > Not explicitly mentioned by those hype terms but not prohibited either > in the charter text. > > > Sorry but I don't see any enthusiasm on this charter draft in the WG. >> > > Then help bring in the enthusiams. The easiest way is to provide > explicit text that we can then evaluate. > > Let me bring back my proposal: First cycle, select one from each category of solutions, client, network based and routing based Second cycle, select one from the selected ones as the dmm solution. Hope this helps to bring the enthusiasm we need :-) Behcet > - Jouni > >> >> Behcet >> >> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> > > --001a1135e20c4dd20504f59df60f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jouni,

See inline.

On Thu, Ma= r 27, 2014 at 4:26 PM, Jouni Korhonen <jouni.nospam@gmail.com>= wrote:
Behcet,

Thank you for constructive feedback. See inline.

3/27/2014 9:51 PM, Behcet Sarikaya kirjoitti:

|The DMM working group will also work on maintenance-oriented and
| =A0 =A0 incremental extensions to the Proxy Mobile IPv6 protocol, specifi= ed
| =A0 =A0 in RFC 5213 and RFC 5844. The Proxy Mobile IPv6 work primarily | =A0 =A0 =A0addresses any protocol gaps required to support existing |depl= oyments
=A0| =A0 =A0 and other standards development organizations using the Proxy = |Mobile
| =A0 =A0 =A0IPv6 protocol in their system architectures.


Add Mobile IPv6 or remove the whole paragraph

I see no point even trying to work on client mobile ipv6 enhancements..

3GPP may need it in = the context of DSMIPv6, just like PMIPv6.
=A0

|Enhanced gateway & mobility anchor selection and re-selection: define<= br> | =A0 =A0 =A0 protocol solutions for a gateway and mobility anchor selectio= n that
| =A0 =A0 =A0 go beyond what has been, for example, described in RFC 6097. = |The
| =A0 =A0 =A0 =A0solution should also define a mechanism for anchor re-sele= ction |that allow
=A0| =A0 =A0 =A0 preserving ongoing mobility sessions in a single administr= ative |domain.

Based on the above paragraph we have two charter items which basically make= up the dmm solution.

What is the justification? Is it RFC 6097 (no offense to you Jouni)?

You know that it just happens to be the only RFC even attempting to explain=
how LMAs are selected dynamically. If the reference here is contentious, I = am
happy to remore it.. just give me alternative text.


What about dmm solution that do not require any anchoring

In scope and in the current text.


Where? I don't think any text counts as long as it is = not in the milestones.
=A0

What about SDN, NFV ideas that have been expressed by Dapeng and others?

Not explicitly mentioned by those hype terms but not prohibited either
in the charter text.


Sorry but I don't see any enthusiasm on this charter draft in the WG.

Then help bring in the enthusiams. The easiest way is to provide
explicit text that we can then evaluate.


Let me bring back my proposal:

=
First cycle, select one from each category of solutions, client,= network based and routing based
Second cycle, select one fro= m the selected ones as the dmm solution.

=A0Hope this helps to bring the enthusiasm we need :-)
Behcet
- Jouni

Behcet



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


--001a1135e20c4dd20504f59df60f-- From nobody Thu Mar 27 15:31:49 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC911A03DD for ; Thu, 27 Mar 2014 15:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGGrFyDdR21V for ; Thu, 27 Mar 2014 15:31:43 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id C8C831A024E for ; Thu, 27 Mar 2014 15:31:43 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.81]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WTIpp-0003Nn-KL; Thu, 27 Mar 2014 18:31:41 -0400 Message-ID: <5334A6CB.1010805@computer.org> Date: Thu, 27 Mar 2014 15:31:39 -0700 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Alper Yegin , dmm@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86a352782ebdb4352d1c5dde5faaf859b6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/alGmq3UaveUZ2UA_E4pFt3OSoJA Subject: Re: [DMM] Next-Gen Mobility Protocols and Architectures Webex call #2 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 22:31:45 -0000 Hello Alper, I guess it's hard to please everyone. Last week's choices were all impossible for me. This week's choices are all at 4:00am. I hope we can get the presentation materials beforehand and make comments. Regards, Charlie P. On 3/27/2014 2:57 PM, Alper Yegin wrote: > Folks, > > The second call is for Pete to present http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00. > > There are three candidate dates from next week. Please use the following doodle to mark the dates that work for you. > > http://doodle.com/um7cwnrk3ekid4pa > > Doodle deadline is the end of next Monday (March 31). > > Alper > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > -- Regards, Charlie P. From nobody Thu Mar 27 21:57:21 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301591A0441 for ; Thu, 27 Mar 2014 21:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rgn9S4Yx7f0w for ; Thu, 27 Mar 2014 21:57:18 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 482081A07D8 for ; Thu, 27 Mar 2014 21:57:18 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MfVoJ-1WjAac1VON-00ObiU; Fri, 28 Mar 2014 00:57:12 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: <5334A6CB.1010805@computer.org> Date: Fri, 28 Mar 2014 06:57:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5334A6CB.1010805@computer.org> To: Charles E. Perkins X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:q1oRip2U24/wotkWRjMdSof8o0IZFl9m2FXfzBTptTQ kzFODJmicXx51bhYrdqgXsurX1JNN5pRU7VFUGNIG7KjUjKrXb B0CIHgDv94/NLvsUC8jIqDifumGqKYq4Qiufigqil5Jd52qhWu UngLbI362V5xVoU4miafeeMt3TA9mgs+NvNP1t04pCjWOa+1E9 GaWCuE2hPWJ4c+ijYpOio3lTfdqNbyGlHhjveaLpA9hv5uMrrX viGd1aQ+Yiu90ThQb4zEcrQScvmEfo5Zmy4GfNRUFxGHfGvFRv nKVT2eVwkA7ZxHeKQhAoN2ahtZ9b12mq64vUvRq83ol9udi9AX yBOfaov7lsLEeWbP8PPQ7pHk21/8pmfRlj20JhEGpJXFfo5jGi GLWP55Ch3EU6A== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Rl8SAz-ZvOMoANyhsiOe4AIr7ko Cc: dmm@ietf.org Subject: Re: [DMM] Next-Gen Mobility Protocols and Architectures Webex call #2 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 04:57:20 -0000 Charlie, You are in Hawaii that week! It's not possible to cover Hawaii and avoid 4am-ish hours for some = participants... Alper On Mar 28, 2014, at 12:31 AM, Charles E. Perkins wrote: >=20 > Hello Alper, >=20 > I guess it's hard to please everyone. >=20 > Last week's choices were all impossible for me. >=20 > This week's choices are all at 4:00am. >=20 > I hope we can get the presentation materials beforehand and make = comments. >=20 > Regards, > Charlie P. >=20 >=20 > On 3/27/2014 2:57 PM, Alper Yegin wrote: >> Folks, >>=20 >> The second call is for Pete to present = http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00. >>=20 >> There are three candidate dates from next week. Please use the = following doodle to mark the dates that work for you. >>=20 >> http://doodle.com/um7cwnrk3ekid4pa >>=20 >> Doodle deadline is the end of next Monday (March 31). >>=20 >> Alper >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >>=20 >=20 >=20 > --=20 > Regards, > Charlie P. From nobody Thu Mar 27 22:44:54 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB231A0455 for ; Thu, 27 Mar 2014 22:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTxpPFN2i2Jq for ; Thu, 27 Mar 2014 22:44:51 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D95C21A07D7 for ; Thu, 27 Mar 2014 22:44:44 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id e16so3331642lan.2 for ; Thu, 27 Mar 2014 22:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=0R5Nz2ti+Dq/lNU90bW1gnvfzhWHN4Z9EPLH3UMwviA=; b=MIrZMyCuG8hHHYUx8pP8OUD0yqFNL8LktRydtucDslhXwsEdwEUQmHWypWsVDCeulM fVHj+LO+dOs34Gwx6R6kVP/MRH8zctOoolmQm2egNtxrNLT49FDz21gUUfdisEPdHJa8 mZM4SftRtcofRKoDQlE/eNNIk+IskF9BXGFU6/FaORjQG+/2d0hk7wCBO3BoKlWUp5Hz kliGJ6OLdPVOENHVTrjCdYGRpGEsk9yWcxfQGJB+PksQ+aag803mE8MGxz9HfmO1CPvY xkh3QfGpyRa01EKBtXd7LIrMhLHJxW/qWY4xWHXL7OAYAWht6ijwTnBaJ5G8DAnNjG4M 7VGQ== X-Received: by 10.152.1.8 with SMTP id 8mr4097259lai.1.1395985482156; Thu, 27 Mar 2014 22:44:42 -0700 (PDT) Received: from [188.117.15.107] ([188.117.15.107]) by mx.google.com with ESMTPSA id q8sm2926182lbr.3.2014.03.27.22.44.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Mar 2014 22:44:41 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8906E196-0079-4A90-8A42-93814FB22439@gmail.com> Date: Fri, 28 Mar 2014 07:44:39 +0200 To: dmm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/rTnAyIs0UfXkgeriRS13zDJ3TlY Subject: [DMM] issues posted for dmm gap analysis X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 05:44:52 -0000 Folks, Charlie made an extensive review of the gap analysis and posted few issues. See then here; = http://tools.ietf.org/wg/dmm/trac/query?status=3Dnew&status=3Dassigned&sta= tus=3Dreopened&component=3Dbest-practices-gap-analysis - JOuni From nobody Fri Mar 28 04:11:53 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAE41A04F8 for ; Fri, 28 Mar 2014 04:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPMnhRMULekW for ; Fri, 28 Mar 2014 04:11:42 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 01C1B1A0503 for ; Fri, 28 Mar 2014 04:11:41 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s2SBBcau029319 for ; Fri, 28 Mar 2014 12:11:38 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E27D6204C1A for ; Fri, 28 Mar 2014 12:13:17 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D151F204BD9 for ; Fri, 28 Mar 2014 12:13:17 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s2SBBMEr026465 for ; Fri, 28 Mar 2014 12:11:38 +0100 Message-ID: <533558DA.9020503@gmail.com> Date: Fri, 28 Mar 2014 12:11:22 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dmm@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/QtWvj1kYPbhqMp1xs9QQWC0x6DY Subject: Re: [DMM] rechartering draft comments X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 11:11:51 -0000 Le 27/03/2014 22:40, Sri Gundavelli (sgundave) a écrit : > > > On 3/27/14 2:26 PM, "Jouni Korhonen" wrote: > >> >> You know that it just happens to be the only RFC even attempting >> to explain how LMAs are selected dynamically. If the reference here >> is contentious, I am happy to remore it.. just give me alternative >> text. > > > I agree. RFC6097 and RFC6463 are relevant to the above work item. I am not sure where these two RFCs appeared from, I dont remember seeing any discussion about them. Clarification please? I suppose work on anchor selection would need a form of problem statement - is there a problem statement in the current drafts? > It is possible the WG may (most likely) adopt newer approaches for > gateway selection, but a reference to the prior work is very much > relevant. It is a very relevant reference. We do want to leverage > work where possible. I'm fine with this. I agree with these affirmations. Alex > > > > Regards Sri > > > _______________________________________________ dmm mailing list > dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm > > From nobody Fri Mar 28 04:59:39 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643F11A050E for ; Fri, 28 Mar 2014 04:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vc6sJ3mBgpH9 for ; Fri, 28 Mar 2014 04:59:36 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 7293D1A031E for ; Fri, 28 Mar 2014 04:59:36 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Lb5Wr-1WvwV82QYL-00lAib; Fri, 28 Mar 2014 07:59:34 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_20671BB9-5D11-4E54-8A78-ECA1A06EAA14" From: Alper Yegin X-Priority: 3 In-Reply-To: <1428C971-BCCE-40A2-8E9D-6D732DA51FB3@yegin.org> Date: Fri, 28 Mar 2014 13:59:30 +0200 Message-Id: <3BA3DB3F-57C1-418E-ABFB-4BD24F97C8BA@yegin.org> References: <1518949455.2095711395743488008.JavaMail.nobody@rln9rmd101.webex.com> <1428C971-BCCE-40A2-8E9D-6D732DA51FB3@yegin.org> To: dmm@ietf.org X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:8qPVTtucrUFSnzuVenLSRlFG8OXHaIa90/Kmu8RR1Qv zghXmBHNEqsaocD3iFGWPX1iPFmH02Co8bOVII5qtsSIswYPqM yqP8mQAeuUcygRVYT184mMQ+vrzJexnylj2UkccKakwOVwpSzI JY3ZZkDcn8Ggi5KUnCFaWx97UbafjFHr40hdqb08joS1/trJnq 1DwfwQ4UgRU1fvoSwWa7MVQVzK593dmyPXke4XgItzTt+S+P/k tn1ZgeRRCdtRTaSXyDwgTvjl8BYajh7qGlxCQo+2CEnfdhLv5W JW1QJHl+Zq3nu5hitPh0s/9hwCtRlgL6Jm9i7cjgelE7ihgsQV PtWxH0QAoUtobPT9ZzY4PUKWUyUpHUq34GANzjbUksPt4qfjsY DiLg+NdYLsePA== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/CqW6cMZPw-v62A0lEQ7PtDWx6w0 Subject: Re: [DMM] Invitation to WebEx meeting: Next-Gen Mobility Protocols and Architectures X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 11:59:38 -0000 --Apple-Mail=_20671BB9-5D11-4E54-8A78-ECA1A06EAA14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Ryuji's slides are here:=20 http://yegin.org/NGmobility/20140327-vEPC.pdf On Mar 25, 2014, at 12:36 PM, Alper Yegin wrote: > Folks, >=20 > See below for this Friday's Webex call details. >=20 > Alper >=20 >=20 > Begin forwarded message: >=20 >>=20 >>=20 >> Hi, >> =09 >> =20 >> Alper Yegin is inviting you to this WebEx meeting: >> =09 >> Next-Gen Mobility Protocols and Architectures=20 >> Fri, Mar 28, 7:00 am | 1 hr 30 min >> Istanbul (Eastern Europe Time, GMT+02:00) >> Host: Alper Yegin >> =09 >> Join >> =09 >> =20 >> Add the attached iCalendar (.ics) file to your calendar. >> =09 >> Agenda >>=20 >> vEPC presentation by Ryuji. >> =09 >> Access Information >>=20 >> Where: WebEx Online >> Meeting number: 230 030 283 >> Password: This meeting does not require a password. >> =09 >> Audio Connection >>=20 >> +44-203-478-5289 UK Domestic Toll >> Access code: 230 030 283 >> Can't access your meeting? Get help. >> Delivering the power of collaboration >> Cisco WebEx Team >>=20 >> IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the meeting to be recorded. By joining this meeting, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the meeting. Please note that any such = recordings may be subject to discovery in the event of litigation. >>=20 >> =A92013 Cisco and/or its affiliates. All rights reserved. >> MT-A-001 >>=20 > >=20 --Apple-Mail=_20671BB9-5D11-4E54-8A78-ECA1A06EAA14 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 http://yegin.org/NG= mobility/20140327-vEPC.pdf


On Mar 25, 2014, at 12:36 PM, Alper Yegin wrote:

Folks,

See = below for this Friday's Webex call = details.

Alper


=
Begin forwarded message:


= 3D"Cisco
=
=
Hi,
3D""
 
Alper Yegin is inviting you to this WebEx meeting:
3D""   
Next-Gen Mobility Protocols and Architectures
Fri, Mar 28, 7:00 am | 1 hr 30 = min
Host: Alper Yegin
  
3D""
 
3D""  

Agenda

vEPC presentation by Ryuji.
3D""  

Access Information

Where:  WebEx Online
Meeting = number:  230 030 283
Password:  This meeting does not require a = password.
3D""  

Audio Connection

+44-203-478-5289 UK Domestic Toll
Access code: 230 030 283

Can't access your = meeting? Get = help.
= = = = = = = = =
=
= Delivering the power of collaboration
= Cisco WebEx Team =
=
= =
3D"Footer"
=20
IMPORTANT = NOTICE: This WebEx service includes a feature that allows audio and any = documents and other materials exchanged or viewed during the meeting to = be recorded. By joining this meeting, you automatically consent to such = recordings. If you do not consent to the recording, discuss your = concerns with the meeting host prior to the start of the recording or do = not join the meeting. Please note that any such recordings may be = subject to discovery in the event of litigation.
=20

=A92013 Cisco = and/or its affiliates. All rights reserved.
MT-A-001
= 3D"Cisco"
<Next-Gen Mobility Protocols and = Architectures.ics>


= --Apple-Mail=_20671BB9-5D11-4E54-8A78-ECA1A06EAA14-- From nobody Fri Mar 28 06:28:14 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0841C1A064F for ; Fri, 28 Mar 2014 06:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZZfluQ6IDQn for ; Fri, 28 Mar 2014 06:28:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id E05681A0641 for ; Fri, 28 Mar 2014 06:28:09 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 62DE7374078; Fri, 28 Mar 2014 14:28:07 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 2F2C1C8056; Fri, 28 Mar 2014 14:28:07 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Fri, 28 Mar 2014 14:28:06 +0100 From: To: Alexandru Petrescu , "dmm@ietf.org" Thread-Topic: [DMM] rechartering draft comments Thread-Index: AQHPSfXqbujLNykCJk6iHseH1Zs44Zr1YcOAgAAD0wCAAOKhAIAANmIw Date: Fri, 28 Mar 2014 13:28:06 +0000 Message-ID: <20093_1396013287_533578E7_20093_2576_1_81C77F07008CA24F9783A98CFD706F7114216E77@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <533558DA.9020503@gmail.com> In-Reply-To: <533558DA.9020503@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.28.40915 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/hYF_tW3pXloBc7POp0_aNEbq8cQ Subject: Re: [DMM] rechartering draft comments X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 13:28:12 -0000 Hi Alex >-----Message d'origine----- >De=A0: dmm [mailto:dmm-bounces@ietf.org] De la part de Alexandru Petrescu >Envoy=E9=A0: vendredi 28 mars 2014 12:11 >=C0=A0: dmm@ietf.org >Objet=A0: Re: [DMM] rechartering draft comments > >Le 27/03/2014 22:40, Sri Gundavelli (sgundave) a =E9crit : >> >> >> On 3/27/14 2:26 PM, "Jouni Korhonen" wrote: >> >>> >>> You know that it just happens to be the only RFC even attempting to >>> explain how LMAs are selected dynamically. If the reference here is >>> contentious, I am happy to remore it.. just give me alternative text. >> >> >> I agree. RFC6097 and RFC6463 are relevant to the above work item. > >I am not sure where these two RFCs appeared from, I dont remember seeing >any discussion about them. Clarification please? > >I suppose work on anchor selection would need a form of problem statement >- is there a problem statement in the current drafts? > You can find information in the gap analysis draft; in http://tools.ietf.or= g/html/draft-aliahmad-dmm-anchor-selection as well Pierrick >> It is possible the WG may (most likely) adopt newer approaches for >> gateway selection, but a reference to the prior work is very much >> relevant. It is a very relevant reference. We do want to leverage work >> where possible. I'm fine with this. > >I agree with these affirmations. > >Alex > >> >> >> >> Regards Sri >> >> >> _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ 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 Fri Mar 28 06:54:48 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E451A1A064D for ; Fri, 28 Mar 2014 06:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMGZyktyUtFp for ; Fri, 28 Mar 2014 06:54:46 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id A95A31A0651 for ; Fri, 28 Mar 2014 06:54:46 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id D6B9F88108; Fri, 28 Mar 2014 06:54:44 -0700 (PDT) Received: from 10252181.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8A8EA71B0001; Fri, 28 Mar 2014 06:54:44 -0700 (PDT) Message-ID: <53357F1A.7060800@innovationslab.net> Date: Fri, 28 Mar 2014 09:54:34 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "dmm@ietf.org" , "draft-ietf-dmm-requirements@tools.ietf.org" X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="r3P5LfrdNNI1tlPghBa91k84VjqdpWoWt" Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/oZg38EJ7J2hbNVp4PzLayQ-ZtKo Subject: [DMM] IESG review of draft-ietf-dmm-requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 13:54:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --r3P5LfrdNNI1tlPghBa91k84VjqdpWoWt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All, The IESG discussed the requirements draft on its call yesterday. There are a few items that need to be addressed in the document and a larger, more educational, step that needs to be done prior to publication. There are two concrete changes needed in the document at this time. Barry Leiba raised the issue about the references to 3753, 5213, and 6275 should be normative. Alia Atlas has asked that there be some description of the applicability or deployment considerations driving these requirements. I think a good way to address this would be to describe a common deployment model in use today and point out where the requirements would lead to changes. It may be useful to have someone engage Alia on this topic. Another point raised, by Benoit Claise, is the OAM issue with these requirements. Benoit would either like to see OAM issues discussed in the requirements document or in the new charter. I think that is a valid concern that the WG needs to discuss, specifically where that need should be documented. As with the above, someone from DMM should chat with Benoit if there are questions on what he would like to s= ee. There are also a few good Comments raised by other ADs that should be addressed. Those can be seen on the document's ballot page: https://datatracker.ietf.org/doc/draft-ietf-dmm-requirements/ballot/ The last issue raised, by Ted Lemon, is the architectural impact of the mobility work. He ties it to this document since he is fearful that these requirements will lead to a solution that impacts the overall Internet architecture. To that end, I suggested that he invite several DMM participants (I suggested the chairs) to participate in an upcoming informal IESG call to discuss. I suspect that Ted will hold this document until that conversation occurs. Let me know if anyone has any questions on these points. Regards, Brian (your slightly frazzled AD) --r3P5LfrdNNI1tlPghBa91k84VjqdpWoWt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTNX8gAAoJEBOZRqCi7goqShMH/iHDvP1P/kSkHnHAz3welhAP BRikpcNfBlT/QDjEc4DMcuYraJ41daAm6DsR1nkkHd0429XgN6sWtHUmgErWUrvm CzFv2KuX3ZGjwcYeQzYI6bR5iwK+HiV1a6IDOJi3quROcdEOrTdLhc+8nb6bAg7y PX7u9fd2LMaJOqtJavzqoBlR5et0VGdzM0ggbLmk2klZ1UVAGY7vZ8zq1fexxa7B sfULNiOpozPkQJeX7vgoGzB7SAREPgOHmXSfULZoW9ZptpTCM967dmYcSpd9f1xa u62/NCELL0fZ6pFBachk7mla9Pfh9Lu169lrj3zmQI5rjdg59ELomzUJFoi4cxA= =4FNb -----END PGP SIGNATURE----- --r3P5LfrdNNI1tlPghBa91k84VjqdpWoWt-- From nobody Fri Mar 28 10:27:14 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D88C1A094C for ; Fri, 28 Mar 2014 10:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDPkcLecsXV9 for ; Fri, 28 Mar 2014 10:27:09 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id EF7651A0943 for ; Fri, 28 Mar 2014 10:27:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s2SHR6HT005960; Fri, 28 Mar 2014 10:27:06 -0700 Received: from XCH-PHX-211.sw.nos.boeing.com (xch-phx-211.sw.nos.boeing.com [130.247.25.140]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s2SHR38P005914 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 28 Mar 2014 10:27:04 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.87]) by XCH-PHX-211.sw.nos.boeing.com ([169.254.11.245]) with mapi id 14.03.0174.001; Fri, 28 Mar 2014 10:27:03 -0700 From: "Templin, Fred L" To: Alper Yegin , "dmm@ietf.org" Thread-Topic: [DMM] Invitation to WebEx meeting: Next-Gen Mobility Protocols and Architectures Thread-Index: AQHPSn02xa60TsboC0660LJZ+qovPJr2vOMA Date: Fri, 28 Mar 2014 17:27:02 +0000 Message-ID: <2134F8430051B64F815C691A62D9831821265C@XCH-BLV-504.nw.nos.boeing.com> References: <1518949455.2095711395743488008.JavaMail.nobody@rln9rmd101.webex.com> <1428C971-BCCE-40A2-8E9D-6D732DA51FB3@yegin.org> <3BA3DB3F-57C1-418E-ABFB-4BD24F97C8BA@yegin.org> In-Reply-To: <3BA3DB3F-57C1-418E-ABFB-4BD24F97C8BA@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831821265CXCHBLV504nwnosboe_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/OteYNEoujcVkx9Ehc3ueuSbbNhA Subject: Re: [DMM] Invitation to WebEx meeting: Next-Gen Mobility Protocols and Architectures X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 17:27:12 -0000 --_000_2134F8430051B64F815C691A62D9831821265CXCHBLV504nwnosboe_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alper, Thank you for hosting the call, and thanks to Ryuji for presenting. In his = talk, Ryuji cited the Connection by Boeing experience where injection and withdrawal of mobile network prefixes into the global BGP routing tables caused excessive= churn and instability. We avoided those issues in our design of IRON and AERO, wh= ere we are using an Autonomous System-interior instance of BGP to manage mobile ne= twork prefixes while still representing the AS to the rest of the Internet as one= or a few short prefixes that never change. The documents can be viewed here, and I w= ould welcome any comments or questions: https://datatracker.ietf.org/doc/draft-templin-ironbis/ https://datatracker.ietf.org/doc/draft-templin-aerolink/ Thanks - Fred fred.l.templin@boeing.com From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin Sent: Friday, March 28, 2014 5:00 AM To: dmm@ietf.org Subject: Re: [DMM] Invitation to WebEx meeting: Next-Gen Mobility Protocols= and Architectures Ryuji's slides are here: http://yegin.org/NGmobility/20140327-vEPC.pdf On Mar 25, 2014, at 12:36 PM, Alper Yegin wrote: Folks, See below for this Friday's Webex call details. Alper Begin forwarded message: [Cisco WebEx logo] Hi, [https://meetings.webex.com/collabsres0103l/common/wwf-avatar-blank.png] Alper Yegin is inviting you to this WebEx meeting: [https://meetings.webex.com/collabsres0103l/local_domain_res/images/emails/= meeting.png] Next-Gen Mobility Protocols and Architectures Fri, Mar 28, 7:00 am | 1 hr 30 min Istanbul (Eastern Europe Time, GMT+02:00) Host: Alper Yegin Join [https://meetings.webex.com/collabsres0103l/local_domain_res/images/emails/= calender.png] Add the attached iCalendar (.ics) file to your calendar. [https://meetings.webex.com/collabsres0103l/local_domain_res/images/emails/= agenda-16.png] Agenda vEPC presentation by Ryuji. [https://meetings.webex.com/collabsres0103l/local_domain_res/images/emails/= access-info-16.png] Access Information Where: WebEx Online Meeting number: 230 030 283 Password: This meeting does not require a password. [https://meetings.webex.com/collabsres0103l/local_domain_res/images/emails/= audio-16.png] Audio Connection +44-203-478-5289 UK Domestic Toll Access code: 230 030 283 Can't access your meeting? Get help. Delivering the power of collaboration Cisco WebEx Team [Footer] IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the meeting= to be recorded. By joining this meeting, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e meeting. Please note that any such recordings may be subject to discovery= in the event of litigation. (c)2013 Cisco and/or its affiliates. All rights reserved. MT-A-001 [Cisco] --_000_2134F8430051B64F815C691A62D9831821265CXCHBLV504nwnosboe_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alper,

 <= /p>

Thank you for hosting the= call, and thanks to Ryuji for presenting. In his talk, Ryuji

cited the Connection by B= oeing experience where injection and withdrawal of

mobile network prefixes i= nto the global BGP routing tables caused excessive churn<= /p>

and instability. We avoid= ed those issues in our design of IRON and AERO, where we<= /p>

are using an Autonomous S= ystem-interior instance of BGP to manage mobile network

prefixes while still repr= esenting the AS to the rest of the Internet as one or a few

short prefixes that never= change. The documents can be viewed here, and I would

welcome any comments or q= uestions:

 <= /p>

https://datatracker.ietf.org/doc= /draft-templin-ironbis/

https://datatracker.ietf.org/do= c/draft-templin-aerolink/

 <= /p>

Thanks – Fred<= /o:p>

fred.l.templin@boeing.com=

 <= /p>

From: dmm [mai= lto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin
Sent: Friday, March 28, 2014 5:00 AM
To: dmm@ietf.org
Subject: Re: [DMM] Invitation to WebEx meeting: Next-Gen Mobility Pr= otocols and Architectures

 

Ryuji's slides are here: 

 

 

 

 

On Mar 25, 2014, at 12:36 PM, Alper Yegin wrote:



Folks,

 

See below for this Friday's Webex call details.=

 

Alper

 

 

Begin forwarded message:



 

 

Hi,

 

Alper Yegin is inviting you to this WebEx= meeting:

 

 

  

Next-Gen Mobility Protocols and Architectures

Fri, Mar 28, 7:00 am= | 1 hr 30 min

Istanbul (Eastern Europe Tim= e, GMT+02:00)

Host: Alper Yegin=

  

 

 

 

Add the attached iCalendar (= .ics) file to your calendar.

 

 

 

Agenda

vEPC pr= esentation by Ryuji.

 

 

 

Access Information

Where:<= /o:p>

  <= /o:p>

WebEx Online=

Meeting numb= er:

  <= /o:p>

230 030 283<= o:p>

Password:

  <= /o:p>

This meeting= does not require a password.

 

 

 

Audio Connection

+= ;44-203-478-5289 UK Domestic Toll

Access code: 230 030 283

 

 

 

 

Can't acces= s your meeting? Get help.

Delivering the power of col= laboration
Cisco WebEx Team

3D"Footer"

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio = and any documents and other materials exchanged or viewed during the meeting to be recorded. By joining this meeting, you automatica= lly consent to such recordings. If you do not consent to the recording, dis= cuss your concerns with the meeting host prior to the start of the recordin= g or do not join the meeting. Please note that any such recordings may be subject to discovery in the event of = litigation.

©2013 Cisco and/or its affiliates. All rights reserved.
MT-A-001

3D"Cisco"

<Next-Gen Mobility Protocols and Architectures.ic= s>

 

 

--_000_2134F8430051B64F815C691A62D9831821265CXCHBLV504nwnosboe_-- From nobody Fri Mar 28 11:33:15 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913C51A0718 for ; Fri, 28 Mar 2014 11:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtTlH5ecORYM for ; Fri, 28 Mar 2014 11:33:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 602841A0959 for ; Fri, 28 Mar 2014 11:33:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCN31815; Fri, 28 Mar 2014 18:33:06 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Mar 2014 18:32:31 +0000 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Mar 2014 18:33:01 +0000 Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.182]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.03.0158.001; Sat, 29 Mar 2014 02:32:51 +0800 From: Peter McCann To: Ryuji Wakikawa Thread-Topic: Questions on draft-matsushima-stateless-uplane-vepc-02 Thread-Index: Ac9KtB6Rb3ZkAL9uQKOBlDJ5Pb1U9A== Date: Fri, 28 Mar 2014 18:32:50 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE753D9FBA1@szxeml522-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/5QkcCEnTj0yP_TRGfS88sTd5SG4 Cc: "dmm@ietf.org" Subject: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 18:33:12 -0000 Ryuji, After viewing your slides from the presentation you did overnight (sorry I = couldn't be on the call) I went back and re-read the draft-matushima-stateless-uplan= e-vepc-02 draft. I am still confused about a number of things: You show in Figure 4, step 15 a Route Update (is this a BGP UPDATE?) going = from the EPC-E to the core network RTR, containing a Destination of UE-prefix and a = Next-Hop of EPC-E address. However, in Section 3.4, you describe the RTR as knowing= only the PDN prefix, which is the same for all EPC-E, and the use of "hot-potato" ro= uting to deliver the packets to the nearest EPC-E no matter the UE destination IP ad= dress. Which one is it? Are the UE prefixes advertised into the core or not? Assuming for now that the UE prefixes are not advertised into the core, but= only the PDN prefixes are advertised, then that means that every EPC-E must know abo= ut every UE session, including the eNB F-TEID for every UE in the network, correct? = That's because any one of them at any time could receive a packet for the UE from = the core. This doesn't seem scalable to me. You seem to attempt to address this issue in Section 4.1 when you talk abou= t multiple "sets" of EPC-E devices, each one dedicated to a given geographic region. = It seems to me that each "set" of EPC-E could cover no more than the scope covered b= y a single SGW today, because they each have the same amount of state as an SGW. Esse= ntially you have described how to build a replicated SGW with failover to different= nodes=20 based on the re-convergence of BGP after a failure (presumably you could ge= t the core network to react to the closure of a BGP TCP session). So I think thi= s addresses the problem of fault-tolerance that has been identified with the tunnel-bas= ed solutions, but not really the scalability bottleneck problem. In fact, if you consider mobility from one "set" to another, if you want to= keep the UE's IP address, you would need to broadcast the same set of PDN prefixes f= rom all sets of EPC-E. In fact this would mean that all EPC-E throughout the netwo= rk, even if they are in different "sets", need to be prepared to handle packets for = any UE and so they ALL would need the eNB F-TEIDs for ALL UEs. Please tell me whe= re I have made a mistake. -- Peter J. McCann Huawei Technologies (USA) Peter.McCann@Huawei.com +1 908 541 3563 Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ 08807-2863 U= SA From nobody Sun Mar 30 12:05:22 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA1D1A08C6 for ; Sun, 30 Mar 2014 12:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnIMmnxYazkw for ; Sun, 30 Mar 2014 12:05:18 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 53AE61A08C4 for ; Sun, 30 Mar 2014 12:05:18 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.81]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WUL2e-0001f2-Sd for dmm@ietf.org; Sun, 30 Mar 2014 15:05:12 -0400 Message-ID: <53386AE6.90602@computer.org> Date: Sun, 30 Mar 2014 12:05:10 -0700 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "dmm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86c7d59635d1fd82a8d45a1f91534e61f5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/c-MgwDqE-A1ldgzMqoNV2UE9tNg Subject: [DMM] [dmm] issue #46: rfcdiff output showing suggested editorial changes for draft-ietf-dmm-best-practices-gap-analysis-03.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 19:05:20 -0000 Hello folks, I made an editorial pass through draft-ietf-dmm-best-practices-gap-analysis-03 and used 'rfcdiff' to highlight the changes. The 'rfcdiff' output is attached to the ticket for issue #46. It also includes an abbreviated list of the other issues that I have already inserted onto the issue tracker. I also uploaded the rfcdiff output to the IETF wiki page for [dmm]. Here is the URL: http://trac.tools.ietf.org/wg/dmm/trac/attachment/wiki/WikiStart/Diff%20%20draft-ietf-dmm-best-practices-gap-analysis-03.txt%20-%20draft-ietf-dmm-best-practices-gap-analysis-03cep-v2.txt.htm When you see that web page, it probably looks like a raw .html file. I don't know how to fix that, but if you download the file and browse it, you should see the rfcdiff output as it's supposed to look. -- Regards, Charlie P. From nobody Mon Mar 31 02:32:37 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285F81A07A1 for ; Mon, 31 Mar 2014 02:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cj_m8QOTgGXr for ; Mon, 31 Mar 2014 02:32:33 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 3804D1A0987 for ; Mon, 31 Mar 2014 02:32:33 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M5dE8-1XEx6K0Xt2-00y36K; Mon, 31 Mar 2014 05:32:29 -0400 From: Alper Yegin Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_19E1741B-73E7-458E-9CC6-BEB0ABA3F229" Date: Mon, 31 Mar 2014 12:32:23 +0300 In-Reply-To: To: dmm@ietf.org References: Message-Id: <7C0603AE-E1D6-4639-858C-307DA21F61D9@yegin.org> X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:uqTxtc+Xfahx9t4SV7iDQTFqRLEdVQfBzJjpWmfMKmS 5n+US2v2lLhjGMQ+X7ovPG+P1BPqWHH6bvX41lxTwAbjvsSgRm dOVsUPS9JeM5zcJG1yeTqkmWR+7S6XeVwZMb7cACbsiYHOUw8U LOsnLWm5KCfxRHW89H4a8j+ME1zaoXLlcZ7fhSe5IcNp2PM8hJ 08Ot7vmkKiCejlplLN4vli8/9GDd/EqhjmOt72gCknKc0ZSzJB C/iylM6z3cHZOgjMJIYpoQlwKDvu8j+5sXbauocguv3UV+M3pb rqfzSKFTi4vxTUFvdeAkfAdzMg0uff9tnDGIHyeIYr0J8OxpXq tEaa6RuL1N1Ko01IaJ9Dvv+xJ4e0T/4gCV6Ux++bBl/1dPpSs6 69Xfrtlj9v2DQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/yATAbgIhB3SN1NGU1mU7eJuUOd0 Subject: Re: [DMM] Next-Gen Mobility Protocols and Architectures Webex call #2 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 09:32:35 -0000 --Apple-Mail=_19E1741B-73E7-458E-9CC6-BEB0ABA3F229 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Folks, Reminder=85. Doodle deadline is today. If you'd like to join the call, = make sure to register the dates that work for you. > http://doodle.com/um7cwnrk3ekid4pa Alper On Mar 27, 2014, at 11:57 PM, Alper Yegin wrote: > Folks, >=20 > The second call is for Pete to present = http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00. >=20 > There are three candidate dates from next week. Please use the = following doodle to mark the dates that work for you. >=20 > http://doodle.com/um7cwnrk3ekid4pa >=20 > Doodle deadline is the end of next Monday (March 31). >=20 > Alper >=20 >=20 --Apple-Mail=_19E1741B-73E7-458E-9CC6-BEB0ABA3F229 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Alper




On Mar 27, = 2014, at 11:57 PM, Alper Yegin wrote:

Folks,

The second call is for Pete to present = http://to= ols.ietf.org/html/draft-mccann-dmm-flatarch-00.

There are = three candidate dates from next week. Please use the following doodle to = mark the dates that work for you.

http://doodle.com/um7cwnrk3eki= d4pa

Doodle deadline is the end of next Monday (March = 31).

Alper



= --Apple-Mail=_19E1741B-73E7-458E-9CC6-BEB0ABA3F229-- From nobody Mon Mar 31 03:25:57 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE741A067B for ; Mon, 31 Mar 2014 03:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnujW5x-VruQ for ; Mon, 31 Mar 2014 03:25:54 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id E646B1A0667 for ; Mon, 31 Mar 2014 03:25:53 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id f73so7375143yha.13 for ; Mon, 31 Mar 2014 03:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bcvFPg/NUWKVaOMwc3t++SNCruwgbkruslTT4qQkYJY=; b=E/y3R56/sYMoaBafdyXkbrYdjTs6d+QpwZXNi8JlYRLJQs0JnUcBxJTiWlVsA37phm gwKUZrzGlaRBSPepx4ETMd4JIoqWDD2uAbFWRmsnU04XGeRVDrsTJzCBwlzJu71jVa9a Yet+hdxUpQ/HID1ILQAV4dQxkiLsZ3bGjAAQcetdWWRJ0ye01oROJVweLZqSofv/cRW7 HMiIMm0Jjqed9pauUaIIa23cHyWhQNL/QU9ydNDCUHMCowL341qUYLJP1F6GcFXcC2wR uB8EgFhgVy27ohnsJLVJg2tWle3m56DCl1xlKRq36D+U/KfqaRy187sRVql+ik7025Ck LF2A== MIME-Version: 1.0 X-Received: by 10.236.42.43 with SMTP id i31mr34448787yhb.31.1396261550721; Mon, 31 Mar 2014 03:25:50 -0700 (PDT) Received: by 10.170.161.194 with HTTP; Mon, 31 Mar 2014 03:25:50 -0700 (PDT) In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE753D9FBA1@szxeml522-mbx.china.huawei.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE753D9FBA1@szxeml522-mbx.china.huawei.com> Date: Mon, 31 Mar 2014 19:25:50 +0900 Message-ID: From: Satoru Matsushima To: Peter McCann Content-Type: multipart/alternative; boundary=20cf3010e5b1be903c04f5e47918 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/_OFtdUeRNxMYiQnV1ZGQhu8N_JU Cc: "dmm@ietf.org" Subject: Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 10:25:56 -0000 --20cf3010e5b1be903c04f5e47918 Content-Type: text/plain; charset=ISO-8859-1 Hi Peter, On Sat, Mar 29, 2014 at 3:32 AM, Peter McCann wrote: > Ryuji, > > After viewing your slides from the presentation you did overnight (sorry I > couldn't > be on the call) I went back and re-read the > draft-matushima-stateless-uplane-vepc-02 > draft. I am still confused about a number of things: > Thanks. Let me try to answer your questions. > > You show in Figure 4, step 15 a Route Update (is this a BGP UPDATE?) going > from the > EPC-E to the core network RTR, containing a Destination of UE-prefix and a > Next-Hop > of EPC-E address. However, in Section 3.4, you describe the RTR as > knowing only the > PDN prefix, which is the same for all EPC-E, and the use of "hot-potato" > routing to > deliver the packets to the nearest EPC-E no matter the UE destination IP > address. > > Which one is it? Are the UE prefixes advertised into the core or not? > No, it isn't meant that specific routes to indicate each UEs prefix are advertised into the core. I'll try to improve that text in next revision of the draft. > > Assuming for now that the UE prefixes are not advertised into the core, > but only the > PDN prefixes are advertised, then that means that every EPC-E must know > about every > UE session, including the eNB F-TEID for every UE in the network, correct? Yes, it's correct. > That's because any one of them at any time could receive a packet for the > UE from the core. > This doesn't seem scalable to me. > I agree with you if a EPC-E has whole UE specific routes that exceed its capacity, it doesn't scale, yes. In the recent presentation through the webex, Ryuji were trying to explain that it's not intended to do. Routes contained in EPC-E will be limited/partitioned by operators policy, such as region, service, population scale, etc., > > You seem to attempt to address this issue in Section 4.1 when you talk > about multiple > "sets" of EPC-E devices, each one dedicated to a given geographic region. Ah, no. Sec 4.1 is intended to explain just scalability issue, and how to deal that issues with routing techniques in operation. > It seems to me that each "set" of EPC-E could cover no more than the > scope covered by a single > SGW today, because they each have the same amount of state as an SGW. > Essentially > you have described how to build a replicated SGW with failover to > different nodes > based on the re-convergence of BGP after a failure (presumably you could > get the > core network to react to the closure of a BGP TCP session). So I think > this addresses > the problem of fault-tolerance that has been identified with the > tunnel-based solutions, > but not really the scalability bottleneck problem. > The nature of BGP makes easy to do that. I think Sec 3.4 would be right place to explain that. But I couldn't see that flavor of text in sec 4.1. Would you point which text in Sec 4.1 makes you confuse? > > In fact, if you consider mobility from one "set" to another, if you want > to keep the > UE's IP address, you would need to broadcast the same set of PDN prefixes > from all > sets of EPC-E. In fact this would mean that all EPC-E throughout the > network, even > if they are in different "sets", need to be prepared to handle packets for > any UE > and so they ALL would need the eNB F-TEIDs for ALL UEs. Please tell me > where I have > made a mistake. > No, an EPC-E just only receives packets from v6 core network toward UEs that routes installed into EPC-E. Because of that an EPC-E should advertise aggregated routes only for that includes its downstream UEs. When the EPC-E advertises whole routes to the core as you explained, yes I agree with you that won't be scalable. But it would depend on EPC-E capacity and size of UE population in the network. cheers, --satoru --20cf3010e5b1be903c04f5e47918 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Peter,=A0


On Sat, Mar 29, 2014 at 3:32 AM, Peter McCann <Pete= r.McCann@huawei.com> wrote:
Ryuji,

After viewing your slides from the presentation you did overnight (sorry I = couldn't
be on the call) I went back and re-read the draft-matushima-stateless-uplan= e-vepc-02
draft. =A0I am still confused about a number of things:

Thanks. Let me try to answer your questions.
=A0

You show in Figure 4, step 15 a Route Update (is this a BGP UPDATE?) going = from the
EPC-E to the core network RTR, containing a Destination of UE-prefix and a = Next-Hop
of EPC-E address. =A0However, in Section 3.4, you describe the RTR as knowi= ng only the
PDN prefix, which is the same for all EPC-E, and the use of "hot-potat= o" routing to
deliver the packets to the nearest EPC-E no matter the UE destination IP ad= dress.

Which one is it? =A0Are the UE prefixes advertised into the core or not?

No, it isn't meant that specific rout= es to indicate each UEs prefix are advertised into the core.
I= 9;ll try to improve that text in next revision of the draft.
=A0

Assuming for now that the UE prefixes are not advertised into the core, but= only the
PDN prefixes are advertised, then that means that every EPC-E must know abo= ut every
UE session, including the eNB F-TEID for every UE in the network, correct? =

Yes, it's correct.
=A0
=
=A0That's=A0because any one of them at any time could receive a packet = for the UE from the core.
This doesn't seem scalable to me.

I= agree with you if a EPC-E has whole UE specific routes that exceed its cap= acity, it doesn't scale, yes. In the recent presentation through the we= bex, Ryuji were trying to explain that it's not intended to do. Routes = contained in EPC-E will be limited/partitioned by operators policy, such as= region, service, population scale, etc.,

=A0

You seem to attempt to address this issue in Section 4.1 when you talk abou= t multiple
"sets" of EPC-E devices, each one dedicated to a given geographic= region.

Ah, no. Sec 4.1 is intended to exp= lain just scalability issue, and how to deal that issues with routing techn= iques in operation.
=A0
=A0It seems=A0to me that each= "set" of EPC-E could cover no more than the scope covered by a s= ingle
SGW today, because they each have the same amount of state as an SGW. =A0Es= sentially
you have described how to build a replicated SGW with failover to different= nodes
based on the re-convergence of BGP after a failure (presumably you could ge= t the
core network to react to the closure of a BGP TCP session). =A0So I think t= his addresses
the problem of fault-tolerance that has been identified with the tunnel-bas= ed solutions,
but not really the scalability bottleneck problem.
The nature of BGP makes easy to do that. I think Sec 3.4 would = be right place to explain that. But I couldn't see that flavor of text = in sec 4.1. Would you point which text in Sec 4.1 makes you confuse?

=A0

In fact, if you consider mobility from one "set" to another, if y= ou want to keep the
UE's IP address, you would need to broadcast the same set of PDN prefix= es from all
sets of EPC-E. =A0In fact this would mean that all EPC-E throughout the net= work, even
if they are in different "sets", need to be prepared to handle pa= ckets for any UE
and so they ALL would need the eNB F-TEIDs for ALL UEs. =A0Please tell me w= here I have
made a mistake.

No, an EPC-E just only = receives packets from v6 core network toward UEs that routes installed into= EPC-E. Because of that an EPC-E should advertise aggregated routes only fo= r that includes its downstream UEs. When the EPC-E advertises whole routes = to the core as you explained, yes I agree with you that won't be scalab= le. But it would depend on EPC-E capacity and size of UE population in the = network.

cheers,
--satoru
--20cf3010e5b1be903c04f5e47918-- From nobody Mon Mar 31 06:19:15 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDA41A0847 for ; Mon, 31 Mar 2014 06:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVbbJQISo4d0 for ; Mon, 31 Mar 2014 06:19:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A3D5D1A0832 for ; Mon, 31 Mar 2014 06:19:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFC62111; Mon, 31 Mar 2014 13:19:03 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 31 Mar 2014 14:18:24 +0100 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 31 Mar 2014 14:19:02 +0100 Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.182]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.03.0158.001; Mon, 31 Mar 2014 21:18:51 +0800 From: Peter McCann To: Satoru Matsushima Thread-Topic: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02 Thread-Index: Ac9KtB6Rb3ZkAL9uQKOBlDJ5Pb1U9AB1GmMAABZbv2A= Date: Mon, 31 Mar 2014 13:18:50 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE753D9FE19@szxeml522-mbx.china.huawei.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE753D9FBA1@szxeml522-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/womniiZnBa1AFDUPOklWcsxdE1s Cc: "dmm@ietf.org" Subject: Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 13:19:13 -0000 Hi, Satoru, Thanks for the answers - I think I understand better now. Let me just confirm a few points below... Satoru Matsushima wrote: > Hi Peter, >=20 >=20 > On Sat, Mar 29, 2014 at 3:32 AM, Peter McCann > wrote: >=20 >=20 >> Ryuji, >>=20 >> After viewing your slides from the presentation you did overnight >> (sorry I couldn't be on the call) I went back and re-read the >> draft-matushima- stateless-uplane-vepc-02 draft. I am still confused >> about a number of things: >=20 >=20 >=20 > Thanks. Let me try to answer your questions. >=20 >=20 >=20 >=20 >> You show in Figure 4, step 15 a Route Update (is this a BGP >> UPDATE?) going from the >> EPC-E to the core network RTR, containing a Destination of UE- prefix >> and a Next-Hop >> of EPC-E address. However, in Section 3.4, you describe the RTR as >> knowing only the >> PDN prefix, which is the same for all EPC-E, and the use of "hot- >> potato" routing to >> deliver the packets to the nearest EPC-E no matter the UE destination >> IP address. >>=20 >> Which one is it? Are the UE prefixes advertised into the core or not? >=20 >=20 >=20 > No, it isn't meant that specific routes to indicate each UEs prefix > are advertised into the core. > I'll try to improve that text in next revision of the draft. Yes please clarify because the current text seems to say that UE prefixes are advertised into the core. >=20 >=20 >=20 >> Assuming for now that the UE prefixes are not advertised into the core, >> but only the PDN prefixes are advertised, then that means that every >> EPC-E must know about every UE session, including the eNB F-TEID for >> every UE in the network, correct? >=20 >=20 > Yes, it's correct. >=20 >=20 >> That's because any one of them at any time could receive a packet >> for the UE from the core. >> This doesn't seem scalable to me. >=20 >=20 >=20 > I agree with you if a EPC-E has whole UE specific routes that exceed > its capacity, it doesn't scale, yes. In the recent presentation > through the webex, Ryuji were trying to explain that it's not intended to= do. > Routes contained in EPC-E will be limited/partitioned by operators > policy, such as region, service, population scale, etc., I was a bit confused by the suggestion to partition by region, because there would be no mobility across regions if you partitioned in this way. That's because different regions would use different PDN prefixes. But, I suppose it would be ok to do this if you didn't need to support UE mobility across regions (or if you used OTT mobility such as client MIP for those cases). >> You seem to attempt to address this issue in Section 4.1 when you talk >> about multiple "sets" of EPC-E devices, each one dedicated to a given >> geographic region. >=20 >=20 > Ah, no. Sec 4.1 is intended to explain just scalability issue, and how > to deal that issues with routing techniques in operation. Ok, I guess in the most common case you would have several "slices" of EPC-E, each set serving a different PDN prefix and a different set of UEs. There would be one EPC-E from each slice, each representing a partition of the PDN prefixes, at each EPC-E deployment site between eNBs and core. A given UE's current location would need to be BGP UPDATEd to each of the EPC-E in the slice that covered that UE's PDN prefix. >> It seems to me that each "set" of EPC-E could cover no more than the >> scope covered by a single SGW today, because they each have the same >> amount of state as an SGW. Essentially you have described how to build >> a replicated SGW with failover to different nodes based on the >> re-convergence of BGP after a failure (presumably you could get the >> core network to react to the closure of a BGP TCP session). So I think >> this addresses the problem of fault-tolerance that has been identified >> with the tunnel-based solutions, but not really the scalability >> bottleneck problem. >=20 > The nature of BGP makes easy to do that. I think Sec 3.4 would be > right place to explain that. But I couldn't see that flavor of text in > sec 4.1. Would you point which text in Sec 4.1 makes you confuse? It was the text in the penultimate paragraph that talked about partitioning by region. If you do that, there is no mobility across regions, right? But if you partition by PDN prefix (sets of UEs) then you can have a whole stack of EPC-E at each deployment site, covering the entire population of UEs. >> In fact, if you consider mobility from one "set" to another, if you >> want to keep the >> UE's IP address, you would need to broadcast the same set of PDN >> prefixes from all >> sets of EPC-E. In fact this would mean that all EPC-E throughout the >> network, even >> if they are in different "sets", need to be prepared to handle >> packets for any UE >> and so they ALL would need the eNB F-TEIDs for ALL UEs. Please tell >> me where I have >> made a mistake. >=20 >=20 >=20 > No, an EPC-E just only receives packets from v6 core network toward > UEs that routes installed into EPC-E. Because of that an EPC-E should > advertise aggregated routes only for that includes its downstream UEs. > When the EPC-E advertises whole routes to the core as you explained, > yes I agree with you that won't be scalable. But it would depend on > EPC-E capacity and size of UE population in the network. Ok, so each EPC-E just serves a slice (set of PDN prefixes) of the UE population, right? There is no need to put all UEs on all EPC-Es. -Pete >=20 > cheers, > --satoru From nobody Mon Mar 31 23:22:46 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFB11A6FE2 for ; Mon, 31 Mar 2014 23:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWGNoWDMOwXM for ; Mon, 31 Mar 2014 23:22:43 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id EDA161A0962 for ; Mon, 31 Mar 2014 23:22:42 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LevDD-1WpduV0t7n-00qZpk; Tue, 01 Apr 2014 02:22:39 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_3294730F-7519-498D-8524-04A2DE9EBAF0" From: Alper Yegin X-Priority: 3 X-Mail-Calendar-Part: Yes Date: Tue, 1 Apr 2014 09:22:33 +0300 Message-Id: <7A5DC1F3-AEA2-435A-9AB5-9C2C5A67E5E3@yegin.org> References: <1674200251.2898621396333226272.JavaMail.nobody@rln9rmd101.webex.com> To: dmm@ietf.org X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:hXEAMNc6uHXFTgPG7gZ7n9I4waKjcteL4VpSz2hJMbB /lFOauujCCyTHB00/YXqXRoEdY8swCSXxTLxCu2mXMtrprar7z vSaV1ly7AAeuMQtDOTdM8jxsgIlMvBUKif6xHWBAzmKeuV5quY xS0O7DPO+ch9C5TRBCjLO/kz9s8A5d9ciVDTE4rN3Yhuen3K9M vyBoa9fc69QizyZ353j6bxZyOYGzKHRvi6WKzDY3cXme3Iz4cu /vjwaYOwwNzqNQ2icWihoO9jO30XRMWn2WbmefgoQ5+4AwNj7E EEb0lU81dzKaJrP8flz+cfzCHUNbZ924Sjnc4PAHk+d2dDg/pb aTBaMc4SBllzaA/iwPMeP3MIAcRKCwKDyC8pExnFeogvYC7E6a mQtedditASw3Q== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/rhxFjYxr7yRWV1ZoUgnEUv3vWDM Subject: [DMM] Fwd: Invitation to WebEx meeting: Next-Gen Mobility Protocols and Architectures (Call #2) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 06:22:45 -0000 --Apple-Mail=_3294730F-7519-498D-8524-04A2DE9EBAF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Folks, Please see below for the details of the upcoming call (on Thursday). Alper Begin forwarded message: >=20 >=20 >=20 > Hi, > =09 > =20 > Alper Yegin is inviting you to this WebEx meeting: > =09 > Next-Gen Mobility Protocols and Architectures (Call #2)=20 > Thu, Apr 3, 5:00 pm | 1 hr 30 min > Istanbul (Eastern Europe Summer Time, GMT+03:00) > Host: Alper Yegin > =09 > Join > =09 > =20 > Add the attached iCalendar (.ics) file to your calendar. > =09 > Agenda >=20 > Pete presenting "Authentication and Mobility Management in a Flat = Architecture" > http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00 > =09 > Access Information >=20 > Where: WebEx Online > Meeting number: 232 864 967 > Password: This meeting does not require a password. > =09 > Audio Connection >=20 > +44-203-478-5289 UK Domestic Toll > Access code: 232 864 967 > Can't access your meeting? Get help. > Delivering the power of collaboration > Cisco WebEx Team >=20 > IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the meeting to be recorded. By joining this meeting, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the meeting. Please note that any such = recordings may be subject to discovery in the event of litigation. >=20 > =A92013 Cisco and/or its affiliates. All rights reserved. > MT-A-001 >=20 --Apple-Mail=_3294730F-7519-498D-8524-04A2DE9EBAF0 Content-Type: multipart/mixed; boundary="Apple-Mail=_6CE332E4-6246-4E58-B054-0AD155C7ACED" --Apple-Mail=_6CE332E4-6246-4E58-B054-0AD155C7ACED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


= 3D"Cisco
=
=
Hi,
3D""
 
Alper Yegin is inviting you to this WebEx meeting:
3D""   
Next-Gen Mobility Protocols and Architectures (Call = #2)
Thu, Apr 3, 5:00 pm | 1 hr 30 = min
Host: = Alper Yegin
  
3D""
 
3D""  

Agenda

= Pete presenting "Authentication and Mobility Mana= gement in a Flat Architecture"
http://to= ols.ietf.org/html/draft-mccann-dmm-flatarch-00
3D""  

Access Information

Where:  WebEx Online
Meeting = number:  232 864 967
Password:  This meeting does not require a = password.
3D""  

Audio Connection

+44-203-478-5289 UK Domestic Toll
Access code: 232 864 967

Can't access your = meeting? Get = help.
= = = = = = = = =
=
= Delivering the power of collaboration
= Cisco WebEx Team =
=
= =
3D"Footer"
=20
IMPORTANT = NOTICE: This WebEx service includes a feature that allows audio and any = documents and other materials exchanged or viewed during the meeting to = be recorded. By joining this meeting, you automatically consent to such = recordings. If you do not consent to the recording, discuss your = concerns with the meeting host prior to the start of the recording or do = not join the meeting. Please note that any such recordings may be = subject to discovery in the event of litigation.
=20

=A92013 Cisco = and/or its affiliates. All rights reserved.
MT-A-001
= 3D"Cisco"
= --Apple-Mail=_6CE332E4-6246-4E58-B054-0AD155C7ACED Content-Disposition: attachment; filename="Next-Gen Mobility Protocols and Architectures (Call _2).ics" Content-Type: text/calendar; name="Next-Gen Mobility Protocols and Architectures (Call _2).ics" Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR=0APRODID:-//Microsoft=20Corporation//Outlook=2012.0=20= MIMEDIR//EN=0AVERSION:2.0=0AMETHOD:REQUEST=0A=0ABEGIN:VTIMEZONE=0A= TZID:Eastern=20Europe=0ABEGIN:STANDARD=0ADTSTART:20001029T040000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D10;BYHOUR=3D4=0A= TZOFFSETFROM:+0300=0ATZOFFSETTO:+0200=0ATZNAME:Standard=20Time=0A= END:STANDARD=0ABEGIN:DAYLIGHT=0ADTSTART:20000326T030000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D3;BYHOUR=3D3=0A= TZOFFSETFROM:+0200=0ATZOFFSETTO:+0300=0ATZNAME:Daylight=20Savings=20Time=0A= END:DAYLIGHT=0AEND:VTIMEZONE=0A=0ABEGIN:VEVENT=0ACLASS:PUBLIC=0A= UID:MDM6G5H922H7V4X7Z96MT0YHJA-1KJ9=0ADTSTAMP:20140401T062026Z=0A= SUMMARY:Next-Gen=20Mobility=20Protocols=20and=20Architectures=20(Call=20= #2)=0ALOCATION:WebEx=20Online=0APRIORITY:5=0ASEQUENCE:1033219341=0A= TRANSP:OPAQUE=0A=0AORGANIZER;CN=3D"Alper=20Yegin=20via=20Cisco=20= WebEx":MAILTO:alper_yegin@hotmail.com=0A= ATTENDEE;ROLE=3DREQ-PARTICIPANT;PARTSTAT=3DNEEDS-ACTION;RSVP=3DTRUE:MAILTO= :alper.yegin@yegin.org=0A=0ADTSTART;TZID=3D"Eastern=20= Europe":20140403T170000=0ADTEND;TZID=3D"Eastern=20= Europe":20140403T183000=0A=0ADESCRIPTION:Hi,\n\nAlper=20Yegin=20is=20= inviting=20you=20to=20this=20WebEx=20meeting:\n\nNext-Gen=20Mobility=20= Protocols=20and=20Architectures=20(Call=20#2)\nThu,=20Apr=203,=205:00=20= pm=20|=201=20hr=2030=20min\nIstanbul=20(Eastern=20Europe=20Summer=20= Time,=20GMT+03:00)\nHost:=20Alper=20Yegin\n\nWhen=20it's=20time,=20join=20= the=20meeting=20from=20= here:\nhttps://meetings.webex.com/collabs/meetings/join?uuid=3DMDM6G5H922H= 7V4X7Z96MT0YHJA-1KJ9\n\nAgenda\nPete=20presenting=20"Authentication=20= and=20Mobility=20Management=20in=20a=20Flat=20= Architecture"\nhttp://tools.ietf.org/html/draft-mccann-dmm-flatarch-00\n\n= Access=20Information\nWhere:=20WebEx=20Online\nMeeting=20number:=20232=20= 864=20967\nMeeting=20password:=20This=20meeting=20does=20not=20require=20= a=20password.\n\nAudio=20Connection\n+44-203-478-5289=20UK=20Domestic=20= Toll\nAccess=20code:=20232=20864=20967\n\n\n\n\n\nCan't=20access=20your=20= meeting?=20Get=20= help:\nhttps://meetings.webex.com/collabs/#/support\n\n\nDelivering=20= the=20power=20of=20collaboration\nCisco=20WebEx=20= Team\n\n-----------------------------------------------------------\n\nIMP= ORTANT=20NOTICE:=20This=20WebEx=20service=20includes=20a=20feature=20= that=20allows=20audio=20and=20any=20documents=20and=20other=20materials=20= exchanged=20or=20viewed=20during=20the=20meeting=20to=20be=20recorded.=20= By=20joining=20this=20meeting,=20you=20automatically=20consent=20to=20= such=20recordings.=20If=20you=20do=20not=20consent=20to=20the=20= recording,=20discuss=20your=20concerns=20with=20the=20meeting=20host=20= prior=20to=20the=20start=20of=20the=20recording=20or=20do=20not=20join=20= the=20meeting.=20Please=20note=20that=20any=20such=20recordings=20may=20= be=20subject=20to=20discovery=20in=20the=20event=20of=20= litigation.\n\n=C2=A92013=20Cisco=20and/or=20its=20affiliates.=20All=20= rights=20reserved.\n\nMT-A-001\n=0A=0ABEGIN:VALARM=0AACTION:DISPLAY=0A= DESCRIPTION:REMINDER=0ATRIGGER:-PT900S=0AEND:VALARM=0A=0AEND:VEVENT=0A=0A= END:VCALENDAR=0A= --Apple-Mail=_6CE332E4-6246-4E58-B054-0AD155C7ACED Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

--Apple-Mail=_6CE332E4-6246-4E58-B054-0AD155C7ACED-- --Apple-Mail=_3294730F-7519-498D-8524-04A2DE9EBAF0--

On Mar 20, 2014, at 6:03 AM, Jouni Korhonen = wrote:

o Mobility state exposing I-D. = This would communication
between the end host and the = network. Maybe also covering
the missing parts within the end = host.. Are we OK with one
I-D or how people want to see = this?
o ..


There's the API = aspect on the terminal (one I-D),
and there is the MN-network interface ones (e.g., = extending RA, DHCP, etc.)


So you want an API = document? I have some reservations documenting
an APIs as-is. Could = this be an extension to RFC5014? I'd see this
approach feasible since = there are even (partial) implementations of
the RFC5014 in popular = operating systems.


Yes, we = are talking about extensions to source address selection (RFC = 5014).


Then the = subsequent thing. Each MN-NW interface would be one document,
if I = understand the above comment correctly? Which one(s) to do first?
ND = or/and DHCP?


Yes. = Both.

Alper


- JOuni





Alper





- Jouni


On Mar 17, 2014, at 2:41 PM, = Jouni Korhonen <jouni.nospam@gmail.com> = wrote:

Folks,

I have = updated the charter draft text = slightly:
https://github.com/jounikor/dmm-re-charter/blob/master/recharter= _draft.txt

Basically:

Added = Sri's comment on PMIPv6 = maintenance.
Added = Alper's comment of location of mobility = functions.
Added = links to other IETF WGs on possible mobility enabling = technologies.
Added = a comment that virtualised network functions are in = scope.

- = Jouni

_______________________________________________
dmm = mailing list
dmm@ietf.org
https://www.ietf.org/ma= ilman/listinfo/dmm