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

From: h chan <[email-masked]>
Date: Fri, 21 Dec 2012 22:44:49 +0000

Revised paragraph in Introduction:
   Mobile users are, more than ever, consuming Internet content; such
   traffic imposes new requirements on mobile core networks for data
   traffic delivery.  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.  Moreover, when the traffic demand exceeds
   available 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].  Gateway selection mechanism is
   also taking the user proximity into account within EPC [TS.29303].
   These mechanisms were not pursued in the past owing to charging and
   billing reasons.  However assigning a gateway anchor node from a
   visited network in roaming scenario has until recently been done and
   are limited to voice services only.  Issues such as charging and
   billing require solutions beyond the mobility protocol.

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of jouni korhonen
Sent: Monday, November 12, 2012 3:33 PM
To: [email-masked]
Subject: [DMM] comments on draft-ietf-dmm-requirements-02

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.

---

From: h chan <[email-masked]>
Date: Fri, 21 Dec 2012 22:46:52 +0000

Revised paragraph in Section 3.2:

   Mobility management may be partially or fully distributed.  In the
   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
   detail in [I-D.yokota-dmm-scenario].  While mobility management can
   be distributed, it is not necessary for other functions to be
   similarly distributed.  For example, a centralized subscription
   management may co-exist with distributed mobility management.

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of jouni korhonen
Sent: Monday, November 12, 2012 3:33 PM
To: [email-masked]
Subject: [DMM] comments on draft-ietf-dmm-requirements-02

Hi,

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.

---

From: h chan <[email-masked]>
Date: Fri, 21 Dec 2012 22:49:47 +0000

Revised PS2:

   PS2:  Divergence from other evolutionary trends in network
         architectures such as distribution of content delivery.

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

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Konstantinos Pentikousis
Sent: Wednesday, November 14, 2012 12:28 PM
To: jouni korhonen
Cc: [email-masked]
Subject: Re: [DMM] comments on draft-ietf-dmm-requirements-02

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

_______________________________________________
dmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmm

---

From: h chan <[email-masked]>
Date: Fri, 21 Dec 2012 22:55:07 +0000

Revised PS3：
   PS3:  Low scalability of centralized tunnel management and mobility
         context maintenance

         Setting up tunnels through a central anchor and maintaining
         mobility context for each MN therein requires more resources in
         a centralized design, thus reducing scalability.  Distributing
         the tunnel 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

> 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: h chan <[email-masked]>
Date: Fri, 21 Dec 2012 22:58:19 +0000

Revised REQ4:

   REQ4:  Existing mobility protocols

          A DMM solution SHOULD first consider reusing and extending
          IETF-standardized protocols before specifying new protocols.

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of jouni korhonen
Sent: Monday, November 12, 2012 3:33 PM
To: [email-masked]
Subject: [DMM] comments on draft-ietf-dmm-requirements-02

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.