Subject: [DMM] comments on draft-ietf-dmm-requirements-02

From: jouni korhonen <[email-masked]>
Date: Mon, 12 Nov 2012 23:32:35 +0200

Hi,

<as an individual contributor and not wearing any hats>

In Introduction it says:

  "..
   capacity, service providers need to implement new strategies such as
   selective traffic offload (e.g. 3GPP work items LIPA/SIPTO [TS.23829])
   through alternative access networks (e.g.  WLAN) [Paper-
   Mobile.Data.Offloading].  Moreover, the presence of content providers
   closer to the mobile/fixed Internet Service Providers network
   requires taking into account local Content Delivery Networks (CDNs)
   while providing mobility services."

 o I would also mention here that the gateway selection mechanism can take the
   user proximity into account at least within EPC [29.303].. as we are already
   referencing to 3GPP as an example.

 o One another aspect I would mention here is the commercial deployment reality.
   While we have means for selecting and using more optimally located gateways
   those are not pursued due charging and billing reasons; here I mean that
   while assigning a gateway anchor node from a visited network while the MN is
   roaming is not done until recently (and still only limited to voice services).
   That kind of issues are not solved by a mobility protocol but a different trust
   and/or billing models between network operators.

In Section 3.2

  "..
   former case only the data plane is distributed.  Fully distributed
   mobility management implies that both the data plane and the control
   plane are distributed.  These different approaches are described in
   .."

 o Would it be OK to mention here that even if full distribution could be achieved
   for the mobility part of the system, some parts are still going to be centralized
   or just geographically replicated at best? Here I mean functions like
   subscriber management, subscription databases and network access authentication.

In Section 4.1:

  "PS2:  Divergence from other evolutionary trends in network
         architecture

         Centralized mobility management can become non-optimal with a
         flat network architecture."

 o What are the "other"? I would consider removing PS2 if we cannot name
   those.

  "PS3:  Low scalability of centralized route and mobility context
         maintenance"

 o Isn't e.g. the SDN evolution just doing to the opposite? Highly
   centralized management point for traffic steering? I would reconsider
   PS3 unless we have more evidence that this is really an issue. Or
   then we need to point out something that makes it more context 
   specific for DMM or mobility.

In Section 4.2:

  "REQ2:  Transparency to Upper Layers when needed

          DMM solutions MUST provide transparent mobility support above
          the IP layer when needed.  Such transparency is needed, for.."

 o Doesn't the "when needed" make the earlier MUST conditional? At least
   I understand it so. If that is the case we probably could just say:
   "DMM solutions SHOULD provide transparent mobility support above the
    IP layer." ?

In Section 4.4:

  o I would just remove the sentence: 
    "Motivation: Using IETF protocols is easier to deploy and to
     update." IMHO it brings no additional clarity what has already been
     said.

In Section 4.5:

  o I would reword "Compatibility" to "Backwards and forward compatibility".

A general editorial note. I would consider rewording all these "PSx" and 
"O-PSx" problem statement and just include them into the generic requirement
text.

- Jouni

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Tue, 13 Nov 2012 15:52:35 +0000

Hi Jouni, all,

  |  "PS2:  Divergence from other evolutionary trends in network
  |         architecture
  |
  |         Centralized mobility management can become non-optimal with a
  |         flat network architecture."
  |
  | o What are the "other"? I would consider removing PS2 if we cannot
  |name those.

I think "other" here refers to the distributed nature of delivering network services/content today (e.g. multiple data centers, CDNs etc.). It's not only the mobile that moves around these days, but your "correspondent" node as well.

  |  "PS3:  Low scalability of centralized route and mobility context
  |         maintenance"
  |
  | o Isn't e.g. the SDN evolution just doing to the opposite? Highly
  |   centralized management point for traffic steering? I would

Oh dear, should we discuss SDN scalability here? :)

  |  "REQ2:  Transparency to Upper Layers when needed
  |
  |          DMM solutions MUST provide transparent mobility support
  |above the IP layer when needed.  Such transparency is needed,
  |for.."
  |
  | o Doesn't the "when needed" make the earlier MUST conditional? At
  |least I understand it so. If that is the case we probably could just say:
  |   "DMM solutions SHOULD provide transparent mobility support above
  |the IP layer." ?

I know we should not be talking implementation, but since I got inspired just now, this is the way I parse the former:

procedure dmmXYZ (in: mobility_support_required, out: mobility_support) {
mobility_support = false;
...
if (mobility_support_required==true) then mobility_support=true;
...
}

Your proposal does not capture the conditionality of mobility support for different hosts, applications, and even different sessions of the same app. I read it more like

// set to 0 for disabling mobility support
#define MOBILITY_SUPPORT 1 

  |In Section 4.4:
  |
  |  o I would just remove the sentence:
  |    "Motivation: Using IETF protocols is easier to deploy and to
  |     update." IMHO it brings no additional clarity what has already
  |     been said.

Second this too, although the section looks a bit too short then.

Best Regards,

Kostas

---

From: <[email-masked]>
Date: Tue, 13 Nov 2012 19:20:28 +0000

Hi Jouni, Kostas,

Please see comments inline.

Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> Konstantinos Pentikousis
> Envoyé : mardi 13 novembre 2012 16:53
> À : jouni korhonen; [email-masked]
> Objet : Re: [DMM] comments on draft-ietf-dmm-requirements-02
> 
> Hi Jouni, all,
> 
> I think "other" here refers to the distributed nature of delivering
> network services/content today (e.g. multiple data centers, CDNs etc.).
> It's not only the mobile that moves around these days, but your
> "correspondent" node as well.
>

Exactly. Here, we refer to distribution of content delivery, i.e. CDN. Probably, one of the main motivation for distributing mobility management :-) IMHO, if we should keep only one PS, it would be PS#2 :-)
 
> I know we should not be talking implementation, but since I got
> inspired just now, this is the way I parse the former:
> 
> procedure dmmXYZ (in: mobility_support_required, out: mobility_support)
> { mobility_support = false; ...
> if (mobility_support_required==true) then mobility_support=true; ...
> }
> 
> Your proposal does not capture the conditionality of mobility support
> for different hosts, applications, and even different sessions of the
> same app. I read it more like
> 
> // set to 0 for disabling mobility support #define MOBILITY_SUPPORT 1
> 

I agree that conditional mobility support, depending on application capability, is a key requirement. However, I think that this requirement is orthogonal to the distribution of mobility management functions; actually, we may have the same requirement with centralized mobility management, right? Basically, here, we refer to the capability of an application to use either a home IP address or a local IP address, depending respectively on the need, or not, for IP session continuity. This is not really a DMM issue but a source address selection problem and the terminal (i.e. the function tackling with source address selection) must be able to distinguish between anchored address/prefix and local address/prefix to make a decision. This is why we have also suggested a work item on prefix coloring in DMM, even if the scope of prefix coloring is larger than DMM.

> _______________________________________________
> dmm mailing list
> [email-masked]
> 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,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

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

---

From: jouni korhonen <[email-masked]>
Date: Tue, 13 Nov 2012 23:17:40 +0200

Pierrick, Kostas,

> Exactly. Here, we refer to distribution of content delivery, i.e. CDN. Probably, one of the main motivation for distributing mobility management :-) IMHO, if we should keep only one PS, it would be…

Maybe we need to then say something about it like 
  "Divergence from other evolutionary trends in network
   architectures such as distribution of content delivery" ?

>> Oh dear, should we discuss SDN scalability here? :)

No (without smile). But that is another trend to opposite direction and
we should have a sufficient argument for our assertion here imho. What
is so fundamentally resource consuming in "mobility context" handling
that it requires distribution? Is it just a combination of all functions
in one place (that has little to do with mobility per se)?

>> same app. I read it more like

I get the point.. but I have a slight issue here. I would need to implement
the "mobility stack" whatever support function anyway even if none of my
application care about it. On the other hand network based mobility should (!)
be transparent to the MN or is this promise also long gone in reality?

> I agree that conditional mobility support, depending on application capability, is a key requirement. However, I think that this requirement is orthogonal to the distribution of mobility management functions; actually, we may have the same requirement with centralized mobility management, right? Basically, here, we refer to the capability of an application to use either a home IP

Yes.

>  address or a local IP address, depending respectively on the need, or not, for IP session continuity. This is not really a DMM issue but a source address selection problem and the terminal (i.e. the function tackling with source address selection) must be able to distinguish between anchored address/prefix and local address/prefix to make a decision. This is why we have also suggested a work item on prefix coloring in DMM, even if the scope of prefix coloring is larger than DMM.

Agree for some obvious reason ;)

>> Second this too, although the section looks a bit too short then.

Less is quite often more ;)

- Jouni

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Wed, 14 Nov 2012 17:32:18 +0000

Hi Pierrick, all,

  |IMHO, if we should keep only one PS, it would be PS#2 :-)

How about combining PS1 and PS2?

  |I agree that conditional mobility support, depending on application
  |capability, is a key requirement. However, I think that this
  |requirement is orthogonal to the distribution of mobility management
  |functions; actually, we may have the same requirement with centralized
  |mobility management, right?

You are right, it is orthogonal.

  | This is not really a DMM issue

Indeed, but if we're to design a modern mobility management solution then it should be considered from the beginning, right?

Best Regards,

Kostas

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Wed, 14 Nov 2012 18:28:17 +0000

Hi Jouni, all,

  |Maybe we need to then say something about it like
  |  "Divergence from other evolutionary trends in network
  |   architectures such as distribution of content delivery" ?

Sounds good to me.

  |No (without smile). But that is another trend to opposite direction
  |and we should have a sufficient argument for our assertion here imho. What
  |is so fundamentally resource consuming in "mobility context" handling
  |that it requires distribution? Is it just a combination of all
  |functions in one place (that has little to do with mobility per se)?

I think scalability here refers to the "hub-and-spoke" nature of the routing fabric as introduced by a "centralized" mobility anchor. You may have valid technical and/or operational reasons for adopting a hub-and-spoke model, that's ok. But maybe others may want an alternative model which aims for different optimalities, and for those the hub-and-spoke model is not, well, "scalable".

SDN, well the OpenFlow flavor of it anyway, is "logically centralized" wrt network control, not how packets move around. SDN can do hub-and-spoke as well as other routing fabrics. Information-centric networking, another major trend, is definitely not pointing towards the merits of the current type of centralization... So I think PS3 is valid.
 
  |I would need to implement the "mobility stack" whatever support function
  |anyway even if none of my application care about it.

If you are absolutely sure that none of your apps needs mobility support, and none will ever need it in the future, then there's no reason to implement it, sure. But if there's a chance one app may need it and 100 won't, then perhaps you get to implement it. The difference is that, if you do implement that "mobility stack", with conditional support you run that code for one app only (and route the respective packets accordingly), while with today's approach you do the same for 101 apps.

Best Regards,

Kostas

---

From: <[email-masked]>
Date: Thu, 15 Nov 2012 08:39:53 +0000

> >>  |         Centralized mobility management can become non-optimal
> with
> >> a
> > Exactly. Here, we refer to distribution of content delivery, i.e.
> CDN.
> > Probably, one of the main motivation for distributing mobility
> > management :-) IMHO, if we should keep only one PS, it would be PS#2
> > :-)
> 

Agreed.

Pierrick

---

From: <[email-masked]>
Date: Thu, 15 Nov 2012 09:10:01 +0000

> De : Konstantinos Pentikousis [mailto:[email-masked]]
> Envoyé : mercredi 14 novembre 2012 18:32
> À : SEITE Pierrick OLNC/OLN; jouni korhonen; [email-masked]
> Objet : RE: [DMM] comments on draft-ietf-dmm-requirements-02
> 
> Hi Pierrick, all,
> 
> Indeed, but if we're to design a modern mobility management solution
> then it should be considered from the beginning, right?
> 

For sure. I'm 100% convinced about benefit of "dynamic" mobility management. I'm just saying that conditional mobility support is a requirement for mobility management system but probably not for DMM protocol. IMHO, conditional mobility support according application capability is probably a connection management issue (i.e. interface, source address selection issue) without direct impact on DMM protocol itself. Anyway, it is worth to stress this requirement since "always-on" mobility support should be avoided.

---

From: jouni korhonen <[email-masked]>
Date: Thu, 15 Nov 2012 12:56:31 +0200

Hi,

>  |   architectures such as distribution of content delivery" ?

Good.

> SDN, well the OpenFlow flavor of it anyway, is "logically centralized" wrt network control, not how packets move around. SDN can do hub-and-spoke as well as other routing fabrics. Information-centr…

PS3 says "centralized route management".. I would be far more comfortable if PS3 says "centralized tunnel management" which is more concretely what we do today as per hub-and-spoke type tunneled traffic deployments.

> If you are absolutely sure that none of your apps needs mobility support, and none will ever need it in the future, then there's no reason to implement it, sure. But if there's a chance one app may…

Fair reasoning. However, what is the "mobility stack" here then? Is it something we today understand as a MIP enabled stack or could it be something more generic? What I mean here is that we should be very cautious with MN side impacts not to freak out less mobility cautious people. If the "mobility stack" could be beneficial also outside mobility use cases that would be awesome.

- Jouni

---

From: [email-masked]
Date: Tue, 20 Nov 2012 15:03:36 +0800

Hi, All

>> Exactly. Here, we refer to distribution of content delivery, i.e. CDN. 
Probably, one of the main motivation for distributing mobility management 
:-) IMHO, if we should keep only one PS, it would be PS#2 :-)

> architectures such as distribution of content delivery" ?

[Luowen]  Maybe "other" just means another kind of network architecture 
evolution trends. I interpret the "other" just as the "flatten network".

> I know we should not be talking implementation, but since I got inspired 

> procedure dmmXYZ (in: mobility_support_required, out: mobility_support) 
{
> if (mobility_support_required==true) then mobility_support=true;

[Luowen] I interpret this logic as the network support mobility, and 
depends on applications on each individual mobile node to choose use the 
mobility or not. I think it reasonable, and whether to choose use mobility 
support or not is applications' decision.

> Your proposal does not capture the conditionality of mobility support 
for different hosts, applications, and even different sessions of the same 
app. I read it more like

> #define MOBILITY_SUPPORT 1 

[Luowen] I interpret this logic as the operator could have some kind of 
global configuration to decide whether to provide mobility support to all 
its subscribers or not. It may provide, then #define MOBILITY_SUPPORT 1 
,otherwise #define MOBILITY_SUPPORT 0. I think it reasonable, some 
operator may only provide fixed/nomadic access service.

>> If you are absolutely sure that none of your apps needs mobility 
support, and none will ever need it in the future, then there's no reason 
to implement it, sure. But if there's a chance one app may need it and 100 
won't, then perhaps you get to implement it. The difference is that, if 
you do implement that "mobility stack", with conditional support you run 
that code for one app only (and route the respective packets accordingly), 
while with today's approach you do the same for 101 apps.

> Fair reasoning. However, what is the "mobility stack" here then? Is it 
something we today understand as a MIP enabled stack or could it be 
something more generic? What I mean here is that we should be very 
cautious with MN side impacts not to freak out less mobility cautious 
people. If the "mobility stack" could be beneficial also outside mobility 
use cases that would be awesome.

[Luowen] Hi Jouni, what do you mean "What I mean here is that we should be 
very cautious with MN side impacts not to freak out less mobility cautious 
people" ?  The applicaions on the mobile node doesn't need to understand 
what is the mobility (i.e. the application developer doesn't need to 
understand), and it seems to let an ordinary user to understand the 
mobilty concept is impossible. As per my understanding, the application 
only care to bind to an IP@ which can survive longer than itself.

BR
Luowen

jouni korhonen <[email-masked]> 
发件人:  [email-masked]
2012/11/15 18:56

收件人
Konstantinos Pentikousis <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [DMM] comments on draft-ietf-dmm-requirements-02

Hi,

Good.

> I think scalability here refers to the "hub-and-spoke" nature of the 
routing fabric as introduced by a "centralized" mobility anchor. You may 
have valid technical and/or operational reasons for adopting a 
hub-and-spoke model, that's ok. But maybe others may want an alternative 
model which aims for different optimalities, and for those the 
hub-and-spoke model is not, well, "scalable".
> 
> SDN, well the OpenFlow flavor of it anyway, is "logically centralized" 
wrt network control, not how packets move around. SDN can do hub-and-spoke 
as well as other routing fabrics. Information-centric networking, another 
major trend, is definitely not pointing towards the merits of the current 
type of centralization... So I think PS3 is valid.

PS3 says "centralized route management".. I would be far more comfortable 
if PS3 says "centralized tunnel management" which is more concretely what 
we do today as per hub-and-spoke type tunneled traffic deployments.

> If you are absolutely sure that none of your apps needs mobility 
support, and none will ever need it in the future, then there's no reason 
to implement it, sure. But if there's a chance one app may need it and 100 
won't, then perhaps you get to implement it. The difference is that, if 
you do implement that "mobility stack", with conditional support you run 
that code for one app only (and route the respective packets accordingly), 
while with today's approach you do the same for 101 apps.

Fair reasoning. However, what is the "mobility stack" here then? Is it 
something we today understand as a MIP enabled stack or could it be 
something more generic? What I mean here is that we should be very 
cautious with MN side impacts not to freak out less mobility cautious 
people. If the "mobility stack" could be beneficial also outside mobility 
use cases that would be awesome.

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Tue, 20 Nov 2012 10:03:31 +0200

On Nov 20, 2012, at 9:03 AM, [email-masked] wrote:

[snip]

> [Luowen] Hi Jouni, what do you mean "What I mean here is that we should be very cautious with MN side impacts not to freak out less mobility cautious people" ?  The applicaions on the mobile node doesn't need to understand what is the mobility (i.e. the

I mean the below the "applications that any random developer can do" support.. i.e. middleware, vendor APIs, OS & IP stack level things etc. For example, if the "mobility stack" needs to hook deep inside the IP stack, it basically has to be part of the platform level baseline software to be successful. If the "mobility stack" is something that just requires higher privileges (like installing a driver) than a consumer has, then operators & enterprises can distribute required software at will.

- Jouni

>  application developer doesn't need to understand), and it seems to let an ordinary user to understand the mobilty concept is impossible. As per my understanding, the application only care to bind to an IP@ which can survive longer than itself.

---

From: [email-masked]
Date: Thu, 22 Nov 2012 10:02:41 +0800

Hi Jouni,

> I mean the below the "applications that any random developer can do" 
support.. i.e. middleware, vendor APIs, OS & IP stack level things etc. 
For example, if the "mobility stack" needs to hook deep inside the IP 
stack, it basically has to be part of the platform level baseline software 
to be successful. If the "mobility stack" is something that just requires 
higher privileges (like installing a driver) than a consumer has, then 
operators & enterprises can distribute required software at will.

[Luowen] I see it could be a middleware or something like that. May be it 
is easy to install this middleware just as to install a driver, and the 
developers don't have to know how the IP mobility is realized, only need 
to know how to invoke it is OK. What is missing here I could image maybe a 
guideline to guide the developer which kind of applicaion needs which kind 
of mobility support (i.e with or without mobility support). But what are 
benifits for a developer to follow this guideline? I mean, it will be much 
easier for a develpoer coding his applcation programme if a stable IP@ can 
be guaranteed.

BR
Luowen

2012/11/20 16:03

收件人
[email-masked]
抄送
"[email-masked]" <[email-masked]>, [email-masked], Konstantinos 
Pentikousis <[email-masked]>
主题
Re: 答复: Re: [DMM] comments on draft-ietf-dmm-requirements-02

[snip]

> 
> [Luowen] Hi Jouni, what do you mean "What I mean here is that we should 
be very cautious with MN side impacts not to freak out less mobility 
cautious people" ?  The applicaions on the mobile node doesn't need to 
understand what is the mobility (i.e. the

I mean the below the "applications that any random developer can do" 
support.. i.e. middleware, vendor APIs, OS & IP stack level things etc. 
For example, if the "mobility stack" needs to hook deep inside the IP 
stack, it basically has to be part of the platform level baseline software 
to be successful. If the "mobility stack" is something that just requires 
higher privileges (like installing a driver) than a consumer has, then 
operators & enterprises can distribute required software at will.

- Jouni

>  application developer doesn't need to understand), and it seems to let 
an ordinary user to understand the mobilty concept is impossible. As per 
my understanding, the application only care to bind to an IP@ which can 
survive longer than itself.

---

From: h chan <[email-masked]>
Date: Tue, 27 Nov 2012 02:02:16 +0000

How about changing PS3 to the following:

Low scalability of centralized tunnel and mobility context maintenance

Setting up tunnels through a central anchor which maintains the mobility context for each MN therein requires more resources at the centralized anchor, thus reducing scalability. 
Distributing the routes and the mobility context maintenance function among different networks can increase scalability.

The current text is:

Low scalability of centralized route and mobility context maintenance

Setting up routes through a central anchor and maintaining mobility context for each MN therein requires more resources in a centralized design, thus reducing scalability. 
Distributing the route maintenance function and the mobility context maintenance function among different network entities can increase scalability.

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of jouni korhonen
Sent: Thursday, November 15, 2012 4:57 AM
To: Konstantinos Pentikousis
Cc: [email-masked]
Subject: Re: [DMM] comments on draft-ietf-dmm-requirements-02

Hi,

On Nov 14, 2012, at 8:28 PM, Konstantinos Pentikousis wrote:

>>  |    centralized management point for traffic steering? I would reconsider
>>  |    PS3 unless we have more evidence that this is really an issue. Or
>>  |    then we need to point out something that makes it more context 
>>  |    specific for DMM or mobility.
>> 

- Jouni