Subject: [DMM] demand for DMM traffic steering

From: Marco Liebsch <[email-masked]>
Date: Fri, 11 Jul 2014 15:59:52 +0000

Folks, I would like to discuss the demand for DMM traffic steering as preparation for
Toronto.

DMM enables smart deployment and selection of network components serving as User-Plane
anchor to the mobile node. The MN's IP address or prefix (HNP/HoA) is assigned to the selected
anchor and bound to the MN's locator (CoA, pCoA, ..)

Now, there are two cases:

(1) Selected anchor is in the network of the MN's HoA/HNP (topologically correct address)
(2) Selected anchor is not in the network of the MN's HoA/HNP (topologically incorrect address)

Case (1) is what IP mobility assumed so far. Default routes in the transport network deliver the
packet into the network which hosts the MN's assigned anchor.

Case (2) can happen in 2 cases:
(a) MN gets assigned a new anchor mid-session but wants to keep its HoA/HNP. That's what has been
called so far anchor re-location
(b) MN has a stable IP address (e.g. profile-bound) but the network wants to select an anchor
according to the requested service, i.e. anchor should be close to a local server or CDN cache.
In that case the MN's IP address will be topologically incorrect from the very beginning of its
attachment.

All cases (a) and (b) may require steering the MN's traffic according to a host policy, as the
route deviates from the default.

First questions we may rise:

I)                    Are we on the same page regarding the above cases?

II)                  What comes first in DMM: IP address configuration or anchor selection?

Hope we can discuss some opinions ahead of the meeting.
marco

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 11 Jul 2014 17:45:44 +0000

Hi Marco,

I think we may have to qualify the term "anchor". In our conf calls we used the terms, Control Plane Anchor (CPA), Data Plane Anchor (DPA) with Home/Access prefix tags.

At the start of a session, the selected anchor assigns a topologically correct address. The HoA/HNP for a mobile node's session is always topologically anchored on that node. That anchor is the Home CPA/DPA (Integrated case) and for the controller scenario, those functions are split across two nodes.  However, once the MN changes its point of attachment, then the selected anchor for that attachment can be the Acces-CPA/Access-DPA in relation to the home CPA/DPA. The session is still anchored on the home CPA/DPA, but the access CPA/DPA is providing the CoA (pardon me,  its your locator per the LISP terminology, or our classic CoA) and the routing state.  However, this access CPN/DPN is also a Home CPN/DPN as the MN can create a new session and may obtain a new HoA/MNP.

The aspect of session relocation is relevant for the initial session and at that point your case#2 comes into picture. At this point, we have a choice to keep both Access CPN/DPN  and Home CPN/DPN and apply traditional schemes for forwarding traffic, or relocate the session to the new Access CPA/DPA and make that as the Home CPA/DPN for the initial session. But, the access CPA/DPA is always a local gateway (typically first-hop router) and so not sure how the gateway selection can be relevant in this context. Gateway selection is relevant in a two node architecture with access and home anchors, and selection being about the home anchor.

Regards
Sri

From: Marco Liebsch <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 11, 2014 8:59 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [DMM] demand for DMM traffic steering

DMM enables smart deployment and selection of network components serving as User-Plane
anchor to the mobile node. The MN’s IP address or prefix (HNP/HoA) is assigned to the selected
anchor and bound to the MN’s locator (CoA, pCoA, ..)

(1) Selected anchor is in the network of the MN’s HoA/HNP (topologically correct address)
(2) Selected anchor is not in the network of the MN’s HoA/HNP (topologically incorrect address)

Case (1) is what IP mobility assumed so far. Default routes in the transport network deliver the
packet into the network which hosts the MN’s assigned anchor.

Case (2) can happen in 2 cases:
(a) MN gets assigned a new anchor mid-session but wants to keep its HoA/HNP. That’s what has been
called so far anchor re-location
(b) MN has a stable IP address (e.g. profile-bound) but the network wants to select an anchor
according to the requested service, i.e. anchor should be close to a local server or CDN cache.
In that case the MN’s IP address will be topologically incorrect from the very beginning of its
attachment.

All cases (a) and (b) may require steering the MN’s traffic according to a host policy, as the
route deviates from the default.

---

From: <[email-masked]>
Date: Sat, 12 Jul 2014 05:59:01 +0000

Hi Sri,

Thanks for your explanation!
I think I agree with most of your explanatory text.
 The gateway selection comes in place for both situations that you described, where the gateway is the access CPA/DPA mentioned in your example. Each time that the MN changes its point of attachment a gateway selection procedure needs to take place. Since a suitable anchor (gateway) should be selected (e.g. close to local service, such as a CDN cache)

The issues that arise here are:

=> What comes first: Anchor (Gateway) Selection or IP address (HNP/HoA) assignment?

=> How is the  traffic steering supported?
Please note that traffic steering is required when:
o) Transport network’s default routes do not convey traffic to MN’s anchor
o) After anchor (gateway) relocation and demand for IP address continuity
o) At initial anchor assignment when MN’s configured IP address does not topologically fit into the selected anchor’s network

Best regards,
Georgios

PS. please note that I am on holidays and have very sporadic Internet access

________________________________
Van: dmm [[email-masked]] namens Sri Gundavelli (sgundave) [[email-masked]]
Verzonden: vrijdag 11 juli 2014 19:45
Aan: Marco Liebsch; [email-masked]
Onderwerp: Re: [DMM] demand for DMM traffic steering

Hi Marco,

Regards
Sri

---

From: Alper Yegin <[email-masked]>
Date: Sat, 12 Jul 2014 10:36:00 +0300

Sri and Marco,

Is any of what you are describing captured in the existing drafts? If so, please provide the pointers.

Alper

On Jul 11, 2014, at 8:45 PM, Sri Gundavelli (sgundave) wrote:

> From: Marco Liebsch <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 14 Jul 2014 12:50:27 +0000

Hi Sri,
Thanks for your prompt response. please see inline.

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Freitag, 11. Juli 2014 19:46
To: Marco Liebsch; [email-masked]
Subject: Re: [DMM] demand for DMM traffic steering

Hi Marco,

I thought that gets clear from my description, but you are right. This thread focuses on the
data/user plane anchor.

At the start of a session, the selected anchor assigns a topologically correct address.

I guess you're referring to the mobility session, not the data session. Yes, that's
today's procedure: Select (data-plane) anchor first, then assign an IP address which
fits to the anchor's network.

 The HoA/HNP for a mobile node's session is always topologically anchored on that node. That anchor is the Home CPA/DPA (Integrated case) and for the controller scenario, those functions are split across two nodes.  However, once the MN changes its point of attachment, then the selected anchor for that attachment can be the Acces-CPA/Access-DPA in relation to the home CPA/DPA. The session is still anchored on the home CPA/DPA, but the access CPA/DPA is providing the CoA (pardon me,  its your locator per the LISP terminology, or our classic CoA) and the routing state.  However, this access CPN/DPN is also a Home CPN/DPN as the MN can create a new session and may obtain a new HoA/MNP.

I think it can be even the same CPA that controls multiple DPAs, whether it's the home or the access.

About the terms: I like the identifier/locator terms as they apply to any mobility solution without
taking a particular one (e.g. PMIP) as base line for a discussion. This is not LISP-specific.
See, MIP maps an identifier (HoA) to a locator (CoA). Northbound to the HA, the HoA serves as
both, identifier and locator assuming a topologically correct HoA at that anchor. Same for
PMIP; or even Cellular IP, where the locator is an output port, or BGP, where the locator is
a hext hop :) So I think this is suitable terminology to discuss DMM, in particular if we still
differentiate the northbound and the southbound operation from a distributed data plane anchor
viewpoint. Questions to answer are then how are packet routed to selected DPA in particular if
the assigned HoA is topologically incorrect at the used DPA. The protocol southbound
to the DPA may use any mobility specific transport, e.g. tunnel (to the locator :)) .

The aspect of session relocation is relevant for the initial session and at that point your case#2 comes into picture.

Yes, that was the rationale behind.

At this point, we have a choice to keep both Access CPN/DPN  and Home CPN/DPN and apply traditional schemes for forwarding traffic, or relocate the session to the new Access CPA/DPA and make that as the Home CPA/DPN for the initial session. But, the access CPA/DPA is always a local gateway (typically first-hop router) and so not sure how the gateway selection can be relevant in this context.

Moving a mobile's mobility state (binding a HoA to a locator) from a previous DPA to a new DPA
is gateway relocation. Well, relocation of the data plane anchor. The control plane anchor
will/may stay the same.

Gateway selection is relevant in a two node architecture with access and home anchors, and selection being about the home anchor.

Selection is an orthogonal problem. Of course an initial DPA and a target DPA must be
selected during DPA relocation. But the mechanism to transfer binding context and to
steer traffic to the new anchor is a different technology compared to selection.

Then: If we think about the case 2b below, that implies that the initially selected
DPA (is it the home DPA in your model?) binds a HoA which is topologically
not correct from the very beginning. Here, traffic steering may be required from
the first registration already. I am just wondering if there is a reasonable use case
behind this. PI address binding?

marco

Regards
Sri

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 14 Jul 2014 13:17:28 +0000

Hi Alper,

the discussed procedures were always on the table in the context of
decentralized anchors. There are expired drafts but also active ones,
which address the use case to change a data plane anchor while keeping
the previously assigned HoA in use. Also our ID about a DMM framework addresses
these use cases in the context of traffic steering above data plane anchor level.
Hope that helps.

marco

From: Alper Yegin [mailto:[email-masked]]
Sent: Samstag, 12. Juli 2014 09:36
To: Sri Gundavelli (sgundave)
Cc: Marco Liebsch; [email-masked]
Subject: Re: [DMM] demand for DMM traffic steering

Sri and Marco,

Alper

Hi Marco,

Regards
Sri

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

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 15 Jul 2014 06:59:49 +0000

Hi Marco,

Might be difficult to converge over email on this topic. But, I will try.

The entity (CP and/or DP) where the subscriber's control plane state got created is always "Home CPA" and the entity where the subscriber home address (lets say EID :) ) is topologically anchored is always the "home DPA". There is no reason for the home CPA to allocate a DPA and a prefix that have not topological relation. IMO, the CPA should ensure it allocates a topologically correct address, by selecting a DPA and the allocated address pool associated with that anchor.   Any incorrect allocation may happen for supporting session chaining in roaming scenarios, but truly the home CPA in such scenario is outside the admin domain.  If our goal is for realizing optimized routing, we rather ensure there is no traffic steering requirement after the first registration. But again, there are two scenarios  here. The a.) very flat model with a controller and a bunch of DPA's that Pete was interested in (Pete's model), and the b) model of splitting CP and DP in access and home domains. For the former case, the DPA (Home+Access) will always be a floating anchor,  but for the later case, its only the access DPA which is a floating anchor. IMO, in both the cases, the aspect of CPA migration is rare and for very specific use-cases that we need to qualify.

Moving a mobile’s mobility state (binding a HoA to a locator) from a previous DPA to a new DPA
is gateway relocation. Well, relocation of the data plane anchor. The control plane anchor
will/may stay the same.

HoA to COA binding change  (EID to Locator mapping) should not be looked at as gateway relocation. Unless we move the address across anchors by updating the routing infrastructure, there is never a DPA migration. The moment we talk about Locator, it implies we have access DPA and home DPA, and change of access DPA is not relocation, its only a state change on the home DPA. The DPA relocation is mainly for the very flat, pete's model. But, again, that model will be bounded in size, given the # of routes.

Agree, the CPA relocation is rare,  specially in the controller-based architectures. We have some use cases for Geo-Redundancy where CPA migration will be needed, but again we need to qualify that use-cases as that comes at some cost.

Regards
Sri

From: Marco Liebsch <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 14, 2014 5:50 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [DMM] demand for DMM traffic steering

Hi Sri,

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Freitag, 11. Juli 2014 19:46
To: Marco Liebsch; [email-masked]<mailto:[email-masked]>
Subject: Re: [DMM] demand for DMM traffic steering

Hi Marco,

I guess you’re referring to the mobility session, not the data session. Yes, that’s
today’s procedure: Select (data-plane) anchor first, then assign an IP address which
fits to the anchor’s network.

I think it can be even the same CPA that controls multiple DPAs, whether it’s the home or the access.

Moving a mobile’s mobility state (binding a HoA to a locator) from a previous DPA to a new DPA
is gateway relocation. Well, relocation of the data plane anchor. The control plane anchor
will/may stay the same.

marco

Regards
Sri

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 15 Jul 2014 07:00:48 +0000

Alper – That can be fixed.

Sri

From: Alper Yegin <[email-masked]<mailto:[email-masked]>>
Date: Saturday, July 12, 2014 12:36 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: Marco Liebsch <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] demand for DMM traffic steering

Sri and Marco,

Alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 15 Jul 2014 14:01:07 +0300

Sri,

I was asking about that for the sake of getting all of the details (or following the discussion better).

> HoA to COA binding change  (EID to Locator mapping) should not be looked at as gateway relocation. 
> Unless we move the address across anchors by updating the routing infrastructure, there is never 
> a DPA migration. The moment we talk about Locator, it implies we have access DPA and home DPA, 
> and change of access DPA is not relocation, its only a state change on the home DPA. 

So, in your terminology MAG is a access DPA and LMA is a home DPA, right?
And as such, both MAG and LMA are called "anchors".
Calling MAG an anchor  may come as a surprise to some people.
We need to nail down the terminology.

Alper

On Jul 15, 2014, at 10:00 AM, Sri Gundavelli (sgundave) wrote:

> From: Alper Yegin <[email-masked]>
> To: Sri Gundavelli <[email-masked]>
> Cc: Marco Liebsch <[email-masked]>, "[email-masked]" <[email-masked]>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 15 Jul 2014 14:09:25 +0000

Alper,

We should not attempt to map these terms to existing protocol functions at this stage. All we are saying,  in a controller-based model the CP is terminated on the controller/(Home CPA) and the user-plane is terminated on the Home DPA. The interface between these entities (CPA and DPA) is OpenFlow/FORCES/XYZ. Unless, we bring the access and the home level separation, there is no "classic" mobility protocol interface in such model. If we keep this very flat, there is just a controller and a bunch of data-plane nodes with a OpenFlow type interface. In one variation, the access DPN and the Home DPA  can be colored in the same way with the same function, keeping it very flat. Alternatively, the Access DPN can have forwarding state that will allow it forward the packets to the Home DPA.

If we bring the Access and Home network aspects in the above model, the CPA functions can be split into "Access CPA" and "Home CPA". In such model, the classic mobility protocol interfaces can be used between these two entities.

Here, I can map the functions as following:

Home CPA ==> Home Agent (CP), LMA (CP), GGSN (CP), PGW (CP)
Home DPA ==> Home Agent (UP), LMA (UP), GGSN (UP), PGW (UP)

Access CPA ==> Foreign Agent (CP), MAG (CP), SGSN (CP), SGW (CP),
Access DPN ==> Foreign Agent (UP), MAG (UP), SGSN (CP), SGW (UP),

Regards
Sri

Date: Tuesday, July 15, 2014 4:01 AM

Sri,

Alper

Sri

Sri and Marco,

Alper

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 15 Jul 2014 18:20:19 +0000

I fully agree that we should not bring in LMA/MAG terms and map them to the two types of
DPAs. Though your terms Access and Home DPA allow such association.

I think we should classify the DPA first. What about Home DPA and Visited DPA (instead of Access DPA)?
A Home DPA is an anchor, which binds an MN's topologically correct IP address. Transferring that IP address
to a new anchor, this will be a Visited DPA, since the imported home address does not
fit to the DPA's network. When the MN's IP address is deprecated and not used for a data session
anymore, the MN may receive a new IP address from the current anchor, which is topologically
correct again. This makes the Visited DPA to a Home DPA. Does that match your model?

marco

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Dienstag, 15. Juli 2014 16:09
To: Alper Yegin
Cc: Marco Liebsch; [email-masked]
Subject: Re: [DMM] demand for DMM traffic steering

Alper,

Regards
Sri

Sri,

Alper

Alper - That can be fixed.

Sri

Sri and Marco,

Alper

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 15 Jul 2014 18:33:11 +0000

Marco,

The "visited" terminology is more modeled for supporting inter-operator roaming scenarios. In such roaming scenario, the peering relation between those SP networks between every DPA in one SP network and CPA in another SP account is  highly unlikely. Its more logical to assume the peering is between a aggregation gateway (Home CPA/DPA) in the visited network and the CPA/DPA in the home network. That way, we keep the number of required security relations to a minimum set. So, by staying with the "access" and "home" terminology, we can keep the business relation outside the technical spec.  The way I see it, the DPA always stays in the home network, unless there is DP migration, impacting the routing infra.

Sri

From: Marco Liebsch <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 15, 2014 11:20 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, Alper Yegin <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [DMM] demand for DMM traffic steering

I think we should classify the DPA first. What about Home DPA and Visited DPA (instead of Access DPA)?
A Home DPA is an anchor, which binds an MN’s topologically correct IP address. Transferring that IP address
to a new anchor, this will be a Visited DPA, since the imported home address does not
fit to the DPA’s network. When the MN’s IP address is deprecated and not used for a data session
anymore, the MN may receive a new IP address from the current anchor, which is topologically
correct again. This makes the Visited DPA to a Home DPA. Does that match your model?

marco

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Dienstag, 15. Juli 2014 16:09
To: Alper Yegin
Cc: Marco Liebsch; [email-masked]<mailto:[email-masked]>
Subject: Re: [DMM] demand for DMM traffic steering

Alper,

Regards
Sri

Sri,

Alper

Sri

Sri and Marco,

Alper

---

From: "Hirschman, Brent B [CTO]" <[email-masked]>
Date: Tue, 15 Jul 2014 19:10:13 +0000

If I may jump in here for a quick comment:

I like the use of access and home network technologies.  A single operator may have multiple access networks so home and visited may not have as much relevance.  Also, the Service provider may be access agnostic or have no specific access network, so Home may be a good representation.  Differentiating between Home and visited/access should be an administrative point and not necessarily a commercial/business point.

Brent Hirschman
Tech Dev Strategist III
Sprint Corporation
6220 Sprint Parkway
Overland Park, KS 66251
Office - 913-762-6736
Mobile - 913-593-6221

From: dmm [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Tuesday, July 15, 2014 1:33 PM
To: Marco Liebsch; Alper Yegin
Cc: [email-masked]
Subject: Re: [DMM] demand for DMM traffic steering

Marco,

Sri

marco

Alper,

Regards
Sri

Sri,

Alper

Sri

Sri and Marco,

Alper

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 15 Jul 2014 20:27:44 +0000

Sri, Brent,

my intent want not to enter the inter-admin domain discussion. Valid point that 'visited' cries for
inter-domain associations. My interest is less about terms but more about the relationship between the mentioned DPAs.
I read your home and access DPA functions as they always exist together for an MN's registration.
This is the case when we separate control- and user-plane of a PMIP LMA and MAG.
But what matches the Home and what the Access DPA if client MIP is deployed?

I am wondering if DMM can work around the assumption of a single DPA (probably the distributed and
selected home DPA), which binds an MN's IP address. That works for MIP, PMIP as well as routing-based DMM solutions, such as
Pete's BGP, where the DPA is assumed co-located with base stations. Same applies to Satoru's concept of the
EPC-Edge, which is the DPA in the context of DMM.

marco

From: Hirschman, Brent B [CTO] [mailto:[email-masked]]
Sent: Dienstag, 15. Juli 2014 21:10
To: Sri Gundavelli (sgundave); Marco Liebsch; Alper Yegin
Cc: [email-masked]
Subject: RE: [DMM] demand for DMM traffic steering

Brent Hirschman
Tech Dev Strategist III
Sprint Corporation
6220 Sprint Parkway
Overland Park, KS 66251
Office - 913-762-6736
Mobile - 913-593-6221

Cc: [email-masked]<mailto:[email-masked]>

Marco,

Sri

marco

Alper,

Regards
Sri

Sri,

Alper

Sri

Sri and Marco,

Alper

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 16 Jul 2014 05:18:11 +0000

Hi Marco,

DMM can absolutely support a Single DPA model, but we have to acknowledge that this is a special case of the two-node (Access-DPA and Home-DPA) model. The home and access DPA functions collapse into a single entity, eliminating the need for a tunnel or other overlay forwarding state.

The same argument goes for the Single Controller model; the very flat model with a single controller that is managing similarly colored DPA nodes (or Access and Home DPA nodes) in the network. This is the special case of the two node (Access and Home CPA) model. The Access and Home CPA functions collapse, eliminating the need for a mobility protocol interface.

Now, to your point as how these functions map to different vEPC models and proposals,

  1.  In the very flat model that Pete wants to realize, the Access DPA and Home DPA functions collapse into a single entity. In that model, there is no access DPA, the aggressive domain-wide route routing updates will ensure the current/serving access DPA is the topological anchor for the address. The base station/first-host access router where the MN is attached is truly the routing anchor.
  2.  Looking at the Satoru-san's  and wakikawa-san's proposal, its again a flat model. They goal is to "remove mobility specific states from the forwarding nodes". The fundamental difference between the flat model and is about the interface between the Controller and the DPA entities. In one model its the OpenFlow/FORCES interface and the other approach is about a hitchhiking on the BGP transport. But, in both the models there is single  DPA. While I'm not opposed to the very flat model, but I do believe we can look at the flat model as an sub-case of the other approach with access and DPA/CPA functions.
  3.  On the question on how this maps to client mobility protocols, the Access DPA for a client-based system is a just a first-hop router. That node is not providing any mobility functions. This is the case for both IPSec/IKEv2, MIPv6 as well. The mobility states and the relation is only at the MN and at the home CPA/DPA.

Regards
Sri

From: Marco Liebsch <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 15, 2014 1:27 PM
To: "Hirschman, Brent B [CTO]" <[email-masked]<mailto:[email-masked]>>, Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, Alper Yegin <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [DMM] demand for DMM traffic steering

Sri, Brent,

my intent want not to enter the inter-admin domain discussion. Valid point that ‘visited’ cries for
inter-domain associations. My interest is less about terms but more about the relationship between the mentioned DPAs.
I read your home and access DPA functions as they always exist together for an MN’s registration.
This is the case when we separate control- and user-plane of a PMIP LMA and MAG.
But what matches the Home and what the Access DPA if client MIP is deployed?

I am wondering if DMM can work around the assumption of a single DPA (probably the distributed and
selected home DPA), which binds an MN’s IP address. That works for MIP, PMIP as well as routing-based DMM solutions, such as
Pete’s BGP, where the DPA is assumed co-located with base stations. Same applies to Satoru’s concept of the
EPC-Edge, which is the DPA in the context of DMM.

marco

Brent Hirschman
Tech Dev Strategist III
Sprint Corporation
6220 Sprint Parkway
Overland Park, KS 66251
Office – 913-762-6736
Mobile – 913-593-6221

Marco,

Sri

marco

Alper,

Regards
Sri

Sri,

Alper

Sri

Sri and Marco,

Alper

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 16 Jul 2014 16:03:57 +0900

Sri and all

I didn’t capture all the discussion, but I agree with your architecture and terminology in this pictures. 
Sir, where can i find your architecture draft of this? 

regards,
ryuji

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 16 Jul 2014 09:42:29 +0000

Sri, I think this matches my description and model very well. For traffic steering I consider the
MN's current Home DPA of particular relevance, without looking further into the mobility protocol
specifics between the Home and the Access DPA. My view of anchor relocation is to change the
Home DPA mid-session. Binding an existing HoA/HNP to the new Home DPA requires steering of the
MN's traffic northbound to the Home DPA.

To conclude from that discussion: Home DPA does not mean centralized DPA, but the Home DPA can
be distributed to an extreme (access, Base Station, ..) if the deployment model considers this.

Does your model consider offloading traffic at the Access DPA?

marco

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Mittwoch, 16. Juli 2014 07:18
To: Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin
Cc: [email-masked]
Subject: Re: [DMM] demand for DMM traffic steering

Hi Marco,

Regards
Sri

Sri, Brent,

marco

Brent Hirschman
Tech Dev Strategist III
Sprint Corporation
6220 Sprint Parkway
Overland Park, KS 66251
Office - 913-762-6736
Mobile - 913-593-6221

Marco,

Sri

marco

Alper,

Regards
Sri

Sri,

Alper

Sri

Sri and Marco,

Alper

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 16 Jul 2014 13:17:48 +0000

Brent – Agree. We need to capture this discussion. We can agree on a common terminology.

Regards
Sri

From: <Hirschman>, "Brent B [CTO]" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 15, 2014 12:10 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, Marco Liebsch <[email-masked]<mailto:[email-masked]>>, Alper Yegin <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [DMM] demand for DMM traffic steering

Brent Hirschman
Tech Dev Strategist III
Sprint Corporation
6220 Sprint Parkway
Overland Park, KS 66251
Office – 913-762-6736
Mobile – 913-593-6221

Marco,

Sri

marco

Alper,

Regards
Sri

Sri,

Alper

Sri

Sri and Marco,

Alper

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 16 Jul 2014 13:20:06 +0000

Ryuji,

We need to capture this discussion. Goal for next week is for all to agree
on few things and write-up some text right there Š.

Regards
Sri

On 7/16/14 12:03 AM, "Ryuji Wakikawa" <[email-masked]> wrote:

>Sri and all
>
>I didn¹t capture all the discussion, but I agree with your architecture
>and terminology in this pictures.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 16 Jul 2014 13:32:21 +0000

Marco,

If the idea is DP anchor relocation after every L3 mobility event, you have a single-node DPA model. The MN attach point at every location will take the Home DPA Role after each Relocation trigger. Any time you cannot relocate a Home DPA, you end with a two node Access/Home DPA model, which IMO offers nice flexibility with respect to when to initiate DP relocation and when to go with a two-node DPA model.

1. Yes, Home DPA does not mean Centralized DPA. But, we have to agree this is a special case of a two node (Access/Home) DPA model.
2. Yes. Home DPA can be in the access Base Station, but that node MUST function as a L3 router. We cannot put this functionality on a L2 bridging device, as that creates lot of technical issues. We should just say, "Home DPA can be hosted in any node that can function as a L3 router"

Also, for this approach we need to scope the size of the mobility domain given the high-frequency routing updates. This model works when the size of the admin domain is relatively small. Any case, we need to qualify those aspects.

Regards
Sri

From: Marco Liebsch <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 16, 2014 2:42 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, "Hirschman, Brent B [CTO]" <[email-masked]<mailto:[email-masked]>>, Alper Yegin <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [DMM] demand for DMM traffic steering

Sri, I think this matches my description and model very well. For traffic steering I consider the
MN’s current Home DPA of particular relevance, without looking further into the mobility protocol
specifics between the Home and the Access DPA. My view of anchor relocation is to change the
Home DPA mid-session. Binding an existing HoA/HNP to the new Home DPA requires steering of the
MN’s traffic northbound to the Home DPA.

marco

Hi Marco,

Regards
Sri

Sri, Brent,

marco

Brent Hirschman
Tech Dev Strategist III
Sprint Corporation
6220 Sprint Parkway
Overland Park, KS 66251
Office – 913-762-6736
Mobile – 913-593-6221

Marco,

Sri

marco

Alper,

Regards
Sri

Sri,

Alper

Sri

Sri and Marco,

Alper

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 16 Jul 2014 13:39:40 +0000

(Changing the subject line).

> Does your model consider offloading traffic at the Access DPA?

Yes. Multiple approaches.

- Approach of allocating a local session after each L3 handover. The traffic associated will that new sessions always be offloaded from that DPA, which is also the Home DPA for that new session.
- For any existing session which has a remote Home DPA, SIPTO based approach for offloading select traffic from the Access DPA.

Sri

From: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 16, 2014 6:32 AM
To: Marco Liebsch <[email-masked]<mailto:[email-masked]>>, "Hirschman, Brent B [CTO]" <[email-masked]<mailto:[email-masked]>>, Alper Yegin <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] demand for DMM traffic steering

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 16 Jul 2014 21:49:05 +0300

I agree the below points.

- Jouni

7/16/2014 4:32 PM, Sri Gundavelli (sgundave) kirjoitti:
> Marco,
>
> If the idea is DP anchor relocation after every L3 mobility event, you
> have a single-node DPA model. The MN attach point at every location will
> take the Home DPA Role after each Relocation trigger. Any time you
> cannot relocate a Home DPA, you end with a two node Access/Home DPA
> model, which IMO offers nice flexibility with respect to when to
> initiate DP relocation and when to go with a two-node DPA model.
>
>
> 1. Yes, Home DPA does not mean Centralized DPA. But, we have to agree
> this is a special case of a two node (Access/Home) DPA model.
> 2. Yes. Home DPA can be in the access Base Station, but that node MUST
> function as a L3 router. We cannot put this functionality on a L2
> bridging device, as that creates lot of technical issues. We should just
> say, "Home DPA can be hosted in any node that can function as a L3 router"
>
> Also, for this approach we need to scope the size of the mobility domain
> given the high-frequency routing updates. This model works when the size
> of the admin domain is relatively small. Any case, we need to qualify
> those aspects.
>
>
>
> Regards
> Sri
>
>
>
> To: Sri Gundavelli <[email-masked] <mailto:[email-masked]>>,
> "Hirschman, Brent B [CTO]" <[email-masked]
> <mailto:[email-masked]>>, Alper Yegin <[email-masked]
> <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> *From:*Sri Gundavelli (sgundave) [mailto:[email-masked]]
> *Sent:* Mittwoch, 16. Juli 2014 07:18
> *To:* Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [DMM] demand for DMM traffic steering
>
> Hi Marco,
>
> DMM can absolutely support a Single DPA model, but we have to
> acknowledge that this is a special case of the two-node (Access-DPA and
> Home-DPA) model. The home and access DPA functions collapse into a
> single entity, eliminating the need for a tunnel or other overlay
> forwarding state.
>
> The same argument goes for the Single Controller model; the very flat
> model with a single controller that is managing similarly colored DPA
> nodes (or Access and Home DPA nodes) in the network. This is the special
> case of the two node (Access and Home CPA) model.The Access and Home CPA
> functions collapse, eliminating the need for a mobility protocol interface.
>
>  1. In the very flat model that Pete wants to realize, the Access DPA
>     and Home DPA functions collapse into a single entity. In that model,
>     there is no access DPA, the aggressive domain-wide route routing
>     updates will ensure the current/serving access DPA is the
>     topological anchor for the address. The base station/first-host
>     access router where the MN is attached is truly the routing anchor.
>  2. Looking at the Satoru-san's  and wakikawa-san's proposal, its again
>     a flat model. They goal is to "remove mobility specific states from
>     the forwarding nodes". The fundamental difference between the flat
>     model and is about the interface between the Controller and the DPA
>     entities. In one model its the OpenFlow/FORCES interface and the
>     other approach is about a hitchhiking on the BGP transport. But, in
>     both the models there is single  DPA. While I'm not opposed to the
>     very flat model, but I do believe we can look at the flat model as
>     an sub-case of the other approach with access and DPA/CPA functions.
>  3. On the question on how this maps to client mobility protocols, the
>     Access DPA for a client-based system is a just a first-hop router.
>     That node is not providing any mobility functions. This is the case
>     for both IPSec/IKEv2, MIPv6 as well. The mobility states and the
>     relation is only at the MN and at the home CPA/DPA.
>
> Regards
>
> Sri
>
> *From: *Marco Liebsch <[email-masked]
> <mailto:[email-masked]>>
> *Date: *Tuesday, July 15, 2014 1:27 PM
> *To: *"Hirschman, Brent B [CTO]" <[email-masked]
> <mailto:[email-masked]>>, Sri Gundavelli <[email-masked]
> <mailto:[email-masked]>>, Alper Yegin <[email-masked]
> <mailto:[email-masked]>>
> *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> *Subject: *RE: [DMM] demand for DMM traffic steering
>
> Sri, Brent,
>
> inter-domain associations. My interest is less about terms but more
> about the relationship between the mentioned DPAs.
> selected home DPA), which binds an MN’s IP address. That works for MIP,
> PMIP as well as routing-based DMM solutions, such as
> *From:*Hirschman, Brent B [CTO] [mailto:[email-masked]]
> *Sent:* Dienstag, 15. Juli 2014 21:10
> *To:* Sri Gundavelli (sgundave); Marco Liebsch; Alper Yegin
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [DMM] demand for DMM traffic steering
>
> I like the use of access and home network technologies.  A single
> operator may have multiple access networks so home and visited may not
> have as much relevance.  Also, the Service provider may be access
> agnostic or have no specific access network, so Home may be a good
> representation.  Differentiating between Home and visited/access should
> be an administrative point and not necessarily a commercial/business point.
>
> */Brent Hirschman/*
>
> Tech Dev Strategist III
>
> Sprint Corporation
>
> 6220 Sprint Parkway
>
> Overland Park, KS 66251
>
> Office – 913-762-6736
>
> Mobile – 913-593-6221
>
> *From:*dmm [mailto:[email-masked]] *On Behalf Of *Sri Gundavelli
> (sgundave)
> *Sent:* Tuesday, July 15, 2014 1:33 PM
> *To:* Marco Liebsch; Alper Yegin
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [DMM] demand for DMM traffic steering
>
> Marco,
>
> The "visited" terminology is more modeled for supporting inter-operator
> roaming scenarios. In such roaming scenario, the peering relation
> between those SP networks between every DPA in one SP network and CPA in
> another SP account is  highly unlikely. Its more logical to assume the
> peering is between a aggregation gateway (Home CPA/DPA) in the visited
> network and the CPA/DPA in the home network. That way, we keep the
> number of required security relations to a minimum set. So, by staying
> with the "access" and "home" terminology, we can keep the business
> relation outside the technical spec.  The way I see it, the DPA always
> stays in the home network, unless there is DP migration, impacting the
> routing infra.
>
> Sri
>
> *From: *Marco Liebsch <[email-masked]
> <mailto:[email-masked]>>
> *Date: *Tuesday, July 15, 2014 11:20 AM
> *To: *Sri Gundavelli <[email-masked] <mailto:[email-masked]>>,
> Alper Yegin <[email-masked] <mailto:[email-masked]>>
> *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> *Subject: *RE: [DMM] demand for DMM traffic steering
>
> I think we should classify the DPA first. What about *Home DPA* and
> *Visited DPA* (instead of Access DPA)?
>
> *From:*Sri Gundavelli (sgundave) [mailto:[email-masked]]
> *Sent:* Dienstag, 15. Juli 2014 16:09
> *To:* Alper Yegin
> *Cc:* Marco Liebsch; [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [DMM] demand for DMM traffic steering
>
> Alper,
>
> We should not attempt to map these terms to existing protocol functions
> at this stage. All we are saying,  in a controller-based model the CP is
> terminated on the controller/(Home CPA) and the user-plane is terminated
> on the Home DPA. The interface between these entities (CPA and DPA) is
> OpenFlow/FORCES/XYZ. Unless, we bring the access and the home level
> separation, there is no "classic" mobility protocol interface in such
> model. If we keep this very flat, there is just a controller and a bunch
> of data-plane nodes with a OpenFlow type interface. In one variation,
> the access DPN and the Home DPA  can be colored in the same way with the
> same function, keeping it very flat. Alternatively, the Access DPN can
> have forwarding state that will allow it forward the packets to the Home
> DPA.
>
> If we bring the Access and Home network aspects in the above model, the
> CPA functions can be split into "Access CPA" and "Home CPA". In such
> model, the classic mobility protocol interfaces can be used between
> these two entities.
>
> *From: *Alper Yegin <[email-masked] <mailto:[email-masked]>>
> *Date: *Tuesday, July 15, 2014 4:01 AM
> *To: *Sri Gundavelli <[email-masked] <mailto:[email-masked]>>
> *Cc: *Marco Liebsch <[email-masked]
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> *Subject: *Re: [DMM] demand for DMM traffic steering
>
> Sri,
>
> *From: *Alper Yegin <[email-masked] <mailto:[email-masked]>>
> *Date: *Saturday, July 12, 2014 12:36 AM
> *To: *Sri Gundavelli <[email-masked] <mailto:[email-masked]>>
> *Cc: *Marco Liebsch <[email-masked]
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> *Subject: *Re: [DMM] demand for DMM traffic steering
>
> Sri and Marco,
>
> ------------------------------------------------------------------------
>
>
> This e-mail may contain Sprint proprietary information intended for the
> sole use of the recipient(s). Any use by others is prohibited. If you
> are not the intended recipient, please contact the sender and delete all
> copies of the message.
>
>
>

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 16 Jul 2014 21:31:39 +0000

Sri,
please see inline.

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Mittwoch, 16. Juli 2014 15:32
To: Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin
Cc: [email-masked]
Subject: Re: [DMM] demand for DMM traffic steering

Marco,

Yes, that's close to the model I had in mind. Remain anchored at the DPA, which preforms mobility
management. Then, at some point when it makes sense (not every L3 handover, but when e.g. the routing path
can be optimized), relocate the DPA. The new DPA may provide a new, topologically correct IP to the MN,
or may import and bind the previous IP if IP address continuity is required. In the latter case tailored routing
rules for traffic steering are required.

The role of the Access DPA in case the Home DPA performs mobility management I left aside so far, as it serves
more as locator (access gateway). It's not necessarily an anchor in terms of mobility management, unless we talk
about a hierarchy of mobility anchors.
If we bring in offload at an Access DPA, the Access DPA provides a different IP address to the MN
and becomes the Home DPA for traffic using that IP. The role of the original Home DPA may be solely to determine
which traffic to offload at the Access DPA.

With all this (the Access DPA becoming a Home DPA..) I am wondering if the Access DPA deserves the
term Anchor. Also according to your description we only have Home DPAs, which bind an MN's IP and
perform mobility management. The Access-thing is not an anchor until it performs offload, which
makes a Home DPA out of it. Isn't it more a Data Plane Access Gateway until it becomes a real anchor?

marco

Regards
Sri

marco

Hi Marco,

Regards
Sri

Sri, Brent,

marco

Brent Hirschman
Tech Dev Strategist III
Sprint Corporation
6220 Sprint Parkway
Overland Park, KS 66251
Office - 913-762-6736
Mobile - 913-593-6221

Marco,

Sri

marco

Alper,

Regards
Sri

Sri,

Alper

Sri

Sri and Marco,

Alper

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 17 Jul 2014 04:37:16 +0000

Hi Marco,

If there should be the use of word, "Anchor" in "access DPA" term is  a minor issue, IMO.  We can always fix that and come up with a better term. The key point is the distinction in roles and functionalities of these two entities and which we seem to agree. Home DPA is clearly the routing anchor and access DPA is entity that is providing some mobility support and it is also the first-hop router.  We also need to highlight that the functional role is always in the context of a mobility session. The Access DPA may assume the role of Home DPA for one specific MN's session, while it may offer the Access DPA function to another mobility session.

> If we bring in offload at an Access DPA, the Access DPA provides a different IP address to the MN and becomes the Home DPA for traffic using that IP. The role of the original Home DPA may be solely to determine which traffic to offload at the Access DPA.

When we discuss offload at the Access DPA, we should qualify this and state that this  offload is for certain IP flows for a session anchored on a remote Home DPA. While there may be another session anchored on the same Access DPA for that MN (with the access DPA acting as a Home DPA for that local session), but that session will have not relation to the Home DPA of the first session and so making sure your last sentence above did not suggest that. Its strictly the UE choice on address selection for local offload.

On the aspect of session migration across Home DPA's you had a comment in one of your earlier emails.  I see session migration as a tool used in very specific scenarios. When we migrate a session from Home-DPA-1 to Home-DPA-2, truly the session is completely migrated to the new Home DPA; even the routing infra is updated and that allows us to completely forget the previous Home-DPA where the session was previously hosted. For a mobility session, at a point of time, we have states in the Controller, Home DPA and Access DPA (optionally) and that's about it. Home DPA may have been changed, Access DPA may have been changed as well, but the state is always present in these three entities.

Regards
Sri

Date: Wednesday, July 16, 2014 2:31 PM

Sri,
please see inline.

Marco,

Yes, that’s close to the model I had in mind. Remain anchored at the DPA, which preforms mobility

more as locator (access gateway). It’s not necessarily an anchor in terms of mobility management, unless we talk

With all this (the Access DPA becoming a Home DPA..) I am wondering if the Access DPA deserves the
term Anchor. Also according to your description we only have Home DPAs, which bind an MN’s IP and
perform mobility management. The Access-thing is not an anchor until it performs offload, which
makes a Home DPA out of it. Isn’t it more a Data Plane Access Gateway until it becomes a real anchor?

marco

---

From: <[email-masked]>
Date: Thu, 17 Jul 2014 09:48:07 +0000

Hi,

Just to be sure that we are on the same page....

De : dmm [mailto:[email-masked]] De la part de Sri Gundavelli (sgundave)
Envoyé : jeudi 17 juillet 2014 06:37
À : Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin
Cc : [email-masked]
Objet : Re: [DMM] demand for DMM traffic steering

Hi Marco,

> If we bring in offload at an Access DPA, the Access DPA provides a different IP address to the MN and becomes the Home DPA for traffic using that IP. The role of the original Home DPA may be solely…

When we discuss offload at the Access DPA, we should qualify this and state that this  offload is for certain IP flows for a session anchored on a remote Home DPA. While there may be another session anchored on the same Access DPA for that MN (with the access DPA acting as a Home DPA for that local session),

[PS]  Access DPA and Home DPA should be considered as different network functions and not be confused with network entities. Using the term Anchor in Access DPA is not a minor issue IMHO, because it implicitly assimilates anchoring and traffic redirection function. Actually, we should talk about DPA, i.e. the node where IP address are topologically correct and data plane redirection  (DPR): the termination of the traffic redirection in the access network. Now, let's consider the example above: the UE initiates a first IP flow , flow#1,using the address obtained from the DPA of its current access (DPA#1), i.e. using the local address...  Here, no mobility support, no DPR coming into play... . Then the UE attaches to a new access, i.e. changes the first-hop router, and obtain an IP address from the DPA of the new access ( DPA#2). Flow#1 remains anchored to DPA#1 and dataplane is updated to the DPR of the new access. The DPR may, or may not, be supported by the first-hop router of the new access. The DPR may, or may not be collocated with the DPA function. Then the UE intiates a second flow, flow#2, with address obtained from DPA#2 as source address. The UE is thus served by two  DPAs, each handling their own mobility sessions; mobility functions are DPA#1 and DPR for flow#1 and only  DPA#2 for flow#2. What I want to stress here is 1) a UE can be served by more than one home DPA and 2) the DPR function comes into play only when mobility support is required, i.e. when the UE attaches to a new first-hop router.

but that session will have not relation to the Home DPA of the first session and so making sure your last sentence above did not suggest that. Its strictly the UE choice on address selection for local offload.

[PS] exactly, but the term « offload » is not appropriate IMHO. Here, we are more talking about "Dynamic mobility" where the UE uses either anchored or local address , depending on the mobility situation.

Regards
Sri

Sri,
please see inline.

Marco,

marco

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Thu, 17 Jul 2014 10:05:01 +0000

Hi Sri,

Regarding the architecture... transport network may have their own controller, and, so, I'm not sure the mobility controller should have direct interface to transport network rressource.  I rather see an iteraction between mobility and transpoirt network conttroller... something like that:

Pierrick

De : dmm [mailto:[email-masked]] De la part de Sri Gundavelli (sgundave)
Envoyé : mercredi 16 juillet 2014 15:18
À : Hirschman, Brent B [CTO]; Marco Liebsch; Alper Yegin
Cc : [email-masked]
Objet : Re: [DMM] demand for DMM traffic steering

Brent - Agree. We need to capture this discussion. We can agree on a common terminology.

Regards
Sri

Brent Hirschman
Tech Dev Strategist III
Sprint Corporation
6220 Sprint Parkway
Overland Park, KS 66251
Office - 913-762-6736
Mobile - 913-593-6221

Marco,

Sri

marco

Alper,

Regards
Sri

Sri,

Alper

Sri

Sri and Marco,

Alper

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 17 Jul 2014 15:30:30 +0000

I am only about functions, not picky about terms. But with certain terms there is some expectation of
the function behind. We need to be clear about the roles of both, access and home DPA for
mobility management and assess their role in driving the different DMM scenarios.

marco

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Donnerstag, 17. Juli 2014 06:37
To: Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin
Cc: [email-masked]
Subject: Re: [DMM] demand for DMM traffic steering

Hi Marco,

Regards
Sri

Sri,
please see inline.

Marco,

marco

---

From: Alper Yegin <[email-masked]>
Date: Thu, 17 Jul 2014 20:59:45 +0300

Intense reading… :-) Lot of abstractions, which I can only follow by relating to specific solutions.

In my understanding, what Sri is describing is about "how to apply UP/CP separation to various DMM solutions".
In the examples I see a number of DMM solutions defined with UP/CP separation using Sri's terminology (e.g., per-flow mobility, access network anchoring, host-specific route based solutions, etc).

So, it's not a solution by itself, but it's an approach that can be applied to various solution techniques to SDNize them. 
And that indeed has value.

Alper

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 17 Jul 2014 18:13:30 +0000

Understood. If there is agreement on the functional roles, the terms can be worked out.

Sri

Date: Thursday, July 17, 2014 8:30 AM

marco

Hi Marco,

Regards
Sri

Sri,
please see inline.

Marco,

marco

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 17 Jul 2014 18:21:27 +0000

I do not know your definition of approach vs solution, but one can argue
DMM itself is about a deployment model and an approach. I always insisted
its less of a protocol work and more about a tying many aspects. So, what
we have been discussing is a solution approach which has the essential
properties of CP/DP separation, aspect of optimized/stateless data plane,
application specific gateway allocations .. etc and that at the end is an
approach for realizing DMM.

Sri

On 7/17/14 10:59 AM, "Alper Yegin" <[email-masked]> wrote:

>Intense readingŠ :-) Lot of abstractions, which I can only follow by
>relating to specific solutions.
>
>In the examples I see a number of DMM solutions defined with UP/CP
>separation using Sri's terminology (e.g., per-flow mobility, access
>network anchoring, host-specific route based solutions, etc).
>
>So, it's not a solution by itself, but it's an approach that can be
>applied to various solution techniques to SDNize them.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 17 Jul 2014 18:40:44 +0000

Hi Pierrick,

The transport network controller below has a specific role, it could be building loop-free topology, or its performing some hich CPU computations. But, that controller has no mobility awareness. From the point of view of the MC, the transport controller is managing the forwarding state for non-mobile prefixes. When there is a Controller to Controller interface, potentially MC when it wants to realize a Routing Update, it can interface with  the Transport controller. But,  we don't have reflect those aspects. We can just state the requirement and that is the MC's ability to route infra. How that is done, using a MC to TC interface, or some thing else is out of scope for DMM, IMO.

Regards
Sri

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 17, 2014 3:05 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, "Hirschman, Brent B [CTO]" <[email-masked]<mailto:[email-masked]>>, Marco Liebsch <[email-masked]<mailto:[email-masked]>>, Alper Yegin <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [DMM] demand for DMM traffic steering

Hi Sri,

Regarding the architecture… transport network may have their own controller, and, so, I’m not sure the mobility controller should have direct interface to transport network rressource.  I rather see an iteraction between mobility and transpoirt network conttroller… something like that:

Pierrick

Cc : [email-masked]<mailto:[email-masked]>

Regards
Sri

Brent Hirschman
Tech Dev Strategist III
Sprint Corporation
6220 Sprint Parkway
Overland Park, KS 66251
Office – 913-762-6736
Mobile – 913-593-6221

Marco,

Sri

marco

Alper,

Regards
Sri

Sri,

Alper

Sri

Sri and Marco,

Alper

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 17 Jul 2014 18:59:14 +0000

Hi Pierrick,

> Using the term Anchor in Access DPA is not a minor issue IMHO, because it implicitly assimilates anchoring and traffic redirection function.

I'm fine with the removal of the "Anchor" term from the Access DPA. Access Gateway, Data Plane Redirection function ..(except Locator or any terms which ties the architecture to a specific protocol) is fine to me.

> Now, let’s consider the example above: the UE initiates a first IP flow , flow#1,using the address obtained from the DPA of its current access (DPA#1), i.e. using the local address…  Here, no mobility support, no DPR coming into play… . Then the UE attaches to a new access, i.e. changes the first-hop router, and obtain an IP address from the DPA of the new access ( DPA#2). Flow#1 remains anchored to DPA#1 and dataplane is updated to the DPR of the new access. The DPR may, or may not, be supported by the first-hop router of the new access. The DPR may, or may not be collocated with the DPA function. Then the UE intiates a second flow, flow#2, with address obtained from DPA#2 as source address. The UE is thus served by two  DPAs, each handling their own mobility sessions; mobility functions are DPA#1 and DPR for flow#1 and only  DPA#2 for flow#2. What I want to stress here is 1) a UE can be served by more than one home DPA and 2) the DPR function comes into play only when mobility support is required, i.e. when the UE attaches to a new first-hop router.

Sure. One conclusions:
#1: Agree. A UE can be served by more than two home DPA's. I thought this is the same example I gave as well. This is where the gateway selection on Application basis comes into picture.
#2. Agree. I said earlier,  "While there may be another session anchored on the same Access DPA for that MN (with the access DPA acting as a Home DPA for that local session), but that session will have not relation to the Home DPA of the first session and ..". Access DPS function is not needed when the access gateway where to MN is attached too serves as its Home DPA.

But, while I agree with the conclusions I'm not following this comment. "The DPR may, or may not, be supported by the first-hop router of the new access. The DPR may, or may not be collocated with the DPA function."
We do need some function in the access gateway which can ensure the traffic for the first flow reaches its home. That interface could be Routing infra, Open Flow .. but some magic needs to happen there.

Regards
Sri

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 17, 2014 2:48 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, Marco Liebsch <[email-masked]<mailto:[email-masked]>>, "Hirschman, Brent B [CTO]" <[email-masked]<mailto:[email-masked]>>, Alper Yegin <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [DMM] demand for DMM traffic steering

Hi,

Just to be sure that we are on the same page….

Hi Marco,

[PS]  Access DPA and Home DPA should be considered as different network functions and not be confused with network entities. Using the term Anchor in Access DPA is not a minor issue IMHO, because it implicitly assimilates anchoring and traffic redirection function. Actually, we should talk about DPA, i.e. the node where IP address are topologically correct and data plane redirection  (DPR): the termination of the traffic redirection in the access network. Now, let’s consider the example above: the UE initiates a first IP flow , flow#1,using the address obtained from the DPA of its current access (DPA#1), i.e. using the local address…  Here, no mobility support, no DPR coming into play… . Then the UE attaches to a new access, i.e. changes the first-hop router, and obtain an IP address from the DPA of the new access ( DPA#2). Flow#1 remains anchored to DPA#1 and dataplane is updated to the DPR of the new access. The DPR may, or may not, be supported by the first-hop router of the new access. The DPR may, or may not be collocated with the DPA function. Then the UE intiates a second flow, flow#2, with address obtained from DPA#2 as source address. The UE is thus served by two  DPAs, each handling their own mobility sessions; mobility functions are DPA#1 and DPR for flow#1 and only  DPA#2 for flow#2. What I want to stress here is 1) a UE can be served by more than one home DPA and 2) the DPR function comes into play only when mobility support is required, i.e. when the UE attaches to a new first-hop router.

[PS] exactly, but the term « offload » is not appropriate IMHO. Here, we are more talking about “Dynamic mobility” where the UE uses either anchored or local address , depending on the mobility situation.

Regards
Sri

Sri,
please see inline.

Marco,

marco

---

From: Alper Yegin <[email-masked]>
Date: Thu, 17 Jul 2014 22:39:55 +0300

Sri,

PMIP is a solution.
You can apply SDN approach to it by splitting CP and DP.

For example, a draft like draft-bernardos-dmm-pmip-03 talks about "access network anchoring".
And you can apply SDN to it (as you already mentioned jun your examples on this thread), or not.

Alper

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 17 Jul 2014 19:51:29 +0000

Alper,

There is no  mobility protocol here in this below deployment modek.  Mobility protocol based on GTP/PMIP comes into the second case when we introduce the access and the home network based separation. In a flat model, its just a SDN interface between the CP and DP functions. But, the way we perform gateway selection, allocate application specific gateways, migrate a data plane session, allow UE the gateway indicators ..it meets every single  DMM requirement that we have discussed in this group and with the side-affect of realizing CP/DP separation.

Sri

From: Alper Yegin <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 17, 2014 12:39 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: Marco Liebsch <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] demand for DMM traffic steering

Sri,

PMIP is a solution.

Alper

Sri

On 7/17/14 10:59 AM, "Alper Yegin" <[email-masked]<mailto:[email-masked]>> wrote:

In my understanding, what Sri is describing is about "how to apply UP/CP
separation to various DMM solutions".
In the examples I see a number of DMM solutions defined with UP/CP
separation using Sri's terminology (e.g., per-flow mobility, access
network anchoring, host-specific route based solutions, etc).

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 17 Jul 2014 23:06:14 +0300

Sri,

You SDNize a solution, then co-locate two entities, and voila the mobility protocol vanishes, and all that's left is OpenFlow.
That's why there's no mobility protocol in that picture.

It'd really be good if we see your solution documented, it's not easy to fully grasp it in a Q&A style. 

(I'm saying this to save us energy. If we read your I-D, we can all see how it meets the requirements. Otherwise, we are going to have to ask about them and have lengthy discussions to understand things).

Alper

On Jul 17, 2014, at 10:51 PM, Sri Gundavelli (sgundave) wrote:

> Cc: Marco Liebsch <[email-masked]>, "[email-masked]" <[email-masked]>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 17 Jul 2014 20:23:27 +0000

Alper,

What we broadly agreed in Nov/Mar IETF's (based on offline discussion) to go with a design group approach. Approach of Individual I-D's, comparing them, selecting the best will go no where, IMO. There are like dozen proposal on the table.

With that goal in mind we have had several conf calls (with smaller group of folks) in Jan time frame.  What we discussed there and in f2f meetings was summarized in IETF 89 WG slides.  Off course, that does not give it a WG status, but the goal is to come to some agreement on the approach and then document the approach. Fair comment on lack of details and that its at a high-level. The discussion is purposely kept at a high-level and we need to work out the details. We should have more formal design meetings and if we converge, we should then write a I-D(s).

Sri

Date: Thursday, July 17, 2014 1:06 PM

Sri,

Alper

Alper,

Sri

Sri,

PMIP is a solution.

Alper

Sri

Alper

---

From: <[email-masked]>
Date: Fri, 18 Jul 2014 06:07:17 +0000

Hi Sri, Hi all,

Agree with Sri that the discussions were kept on a high level.

Please note that the following draft tried to provide the work items that were discussed

http://www.ietf.org/id/draft-liebsch-dmm-framework-analysis-03.txt

I thought that we had agreed on these work items, but apparently we need to spend more time on this!

Best regards,

Georgios

________________________________
Van: dmm [[email-masked]] namens Sri Gundavelli (sgundave) [[email-masked]]
Verzonden: donderdag 17 juli 2014 22:23
Aan: Alper Yegin
CC: [email-masked]
Onderwerp: Re: [DMM] demand for DMM traffic steering

Alper,

Sri

Sri,

Alper

Alper,

Sri

Sri,

PMIP is a solution.

Alper

Sri

Alper

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 18 Jul 2014 13:16:42 +0000

Hi Georgios,

Agree. We need to have more discussions.

Regards
Sri

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 17, 2014 11:07 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [DMM] demand for DMM traffic steering

Hi Sri, Hi all,

Best regards,

Georgios

________________________________
Van: dmm [[email-masked]<mailto:[email-masked]>] namens Sri Gundavelli (sgundave) [[email-masked]<mailto:[email-masked]>]
Verzonden: donderdag 17 juli 2014 22:23
Aan: Alper Yegin
CC: [email-masked]<mailto:[email-masked]>
Onderwerp: Re: [DMM] demand for DMM traffic steering

Alper,

Sri

Sri,

Alper

Alper,

Sri

Sri,

PMIP is a solution.

Alper

Sri

Alper

---

From: Alper Yegin <[email-masked]>
Date: Sat, 19 Jul 2014 11:17:19 +0300

I agree that the discussions were kept at a high level.
But as I noted then and now, I disagree with still keeping the discussions at high level… It's still hovering at 10k feet... 
If we want to make real progress, we need to start bringing the discussion to low level, closer to solutions.

The requirements and gap analysis documents are not strong enough to steer the discussion in any way.
Framework documents and what Sri is showing are still very high level.

That's why I approached this from the other angle: Categorization of the solutions.

The approach I'm proposing is:

1. Discuss the categorization. 

Whether we agree to necessity of each category. 
Each category would produce WG I-D(s).

(Here we can use all of our requirements, gap analysis, framework thoughts to make sure nothing is missing).

2. Once we agree on the categories, then we discuss how to handle the candidate I-Ds in each category.

In a given category, there are various relationships among I-Ds.
Some are complementary, some are competing. Some have different applicability.
We need to sort that out.

So, this is a divide-and-conquer approach, which also lays out how things would come together.

I think this is more progressive than still talking about high-level principles (which normally would have finished with the charter + requirements +  gap analysis, but we seem to be stuck in a rip current).

Alper

---

From: Alper Yegin <[email-masked]>
Date: Sat, 19 Jul 2014 11:23:01 +0300

Btw, in addition to nailing down the grand plan, it'd also be good if Jouni&Dapeng can share the objective of this week's meeting.
What exactly we want to achieve, how we want to do it, etc. Let's announce the objectives, so that we can all work towards that.

Alper

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 20 Jul 2014 02:12:18 +0300

Ain't that quite visible from the agenda:

1.1) have a look at the re-chartering text that it is roughly
    acceptable for everyone in the room. We can even do some
    minor online editing if there is something that requires
    immediate attention. The text has not been changed since
    14th Jun.

1.2) have the initial discussion how to proceed after IETF90.

2) lenghty powerpoint marathon.. of many I-Ds that we have
    already heard a presentation before, so concentrate on
    possible updates and how the I-D fits under the current
    re-charter milestones.

3) on Friday conclude the next steps and the working procedues
    for carrying out the stuff. Decision making point here. (we
    probably need to add some minutes for the concluding
    discussions, so the longer presentations slots are subject
    to some adjustment)

- Jouni

7/19/2014 11:23 AM, Alper Yegin kirjoitti:
>
> Btw, in addition to nailing down the grand plan, it'd also be good if
> Jouni&Dapeng can share the objective of this week's meeting.
> What exactly we want to achieve, how we want to do it, etc. Let's
> announce the objectives, so that we can all work towards that.
>
> Alper
>
>
>
>> But as I noted then and now, I disagree with still keeping the
>> discussions at high level… It's still hovering at 10k feet...
>> If we want to make real progress, we need to start bringing the
>> discussion to low level, closer to solutions.
>>
>> (Here we can use all of our requirements, gap analysis, framework
>> thoughts to make sure nothing is missing).
>>
>>
>>
>> I think this is more progressive than still talking about high-level
>> principles (which normally would have finished with the charter +
>> requirements +  gap analysis, but we seem to be stuck in a rip current).
>>
>> Alper
>>
>>
>>
>>
>>
>> *
>> *
>>
>>
>>
>>
>>
>>
>>
>>
>> On Jul 18, 2014, at 9:07 AM, <[email-masked]
>> <mailto:[email-masked]>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>> Hi Sri, Hi all,
>>>
>>> *Van:*dmm [[email-masked] <mailto:[email-masked]>] namens
>>> Sri Gundavelli (sgundave) [[email-masked]
>>> <mailto:[email-masked]>]
>>> *Verzonden:*donderdag 17 juli 2014 22:23
>>> *Aan:*Alper Yegin
>>> *CC:[email-masked] <mailto:[email-masked]>
>>> *Onderwerp:*Re: [DMM] demand for DMM traffic steering
>>>
>>> Alper,
>>>
>>> What we broadly agreed in Nov/Mar IETF's (based on offline
>>> discussion) to go with a design group approach. Approach of
>>> Individual I-D's, comparing them, selecting the best will go no
>>> where, IMO. There are like dozen proposal on the table.
>>>
>>> With that goal in mind we have had several conf calls (with smaller
>>> group of folks) in Jan time frame.  What we discussed there and in
>>> f2f meetings was summarized in IETF 89 WG slides.  Off course, that
>>> does not give it a WG status, but the goal is to come to some
>>> agreement on the approach and then document the approach. Fair
>>> comment on lack of details and that its at a high-level. The
>>> discussion is purposely kept at a high-level and we need to work out
>>> the details. We should have more formal design meetings and if we
>>> converge, we should then write a I-D(s).
>>>
>>> Sri
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> From:Alper Yegin <[email-masked] <mailto:[email-masked]>>
>>> Date:Thursday, July 17, 2014 1:06 PM
>>> To:Sri Gundavelli <[email-masked] <mailto:[email-masked]>>
>>> Cc:Marco Liebsch <[email-masked]
>>> <mailto:[email-masked]>>, "[email-masked]
>>> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>>> Subject:Re: [DMM] demand for DMM traffic steering
>>>
>>> Sri,
>>>
>>> You SDNize a solution, then co-locate two entities, and voila the
>>> mobility protocol vanishes, and all that's left is OpenFlow.
>>> (I'm saying this to save us energy. If we read your I-D, we can all
>>> see how it meets the requirements. Otherwise, we are going to have to
>>> ask about them and have lengthy discussions to understand things).
>>>
>>> Alper
>>>
>>>
>>>
>>>
>>>> There is no  mobility protocol here in this below deployment modek.
>>>>  Mobility protocol based on GTP/PMIP comes into the second case when
>>>> we introduce the access and the home network based separation. In a
>>>> flat model, its just a SDN interface between the CP and DP
>>>> functions. But, the way we perform gateway selection, allocate
>>>> application specific gateways, migrate a data plane session, allow
>>>> UE the gateway indicators ..it meets every single  DMM requirement
>>>> that we have discussed in this group and with the side-affect of
>>>> realizing CP/DP separation.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Sri
>>>>
>>>>
>>>> From:Alper Yegin <[email-masked] <mailto:[email-masked]>>
>>>> Date:Thursday, July 17, 2014 12:39 PM
>>>> To:Sri Gundavelli <[email-masked] <mailto:[email-masked]>>
>>>> Cc:Marco Liebsch <[email-masked]
>>>> <mailto:[email-masked]>>, "[email-masked]
>>>> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>>>> Subject:Re: [DMM] demand for DMM traffic steering
>>>>
>>>> Sri,
>>>>
>>>> PMIP is a solution.
>>> [email-masked] <mailto:[email-masked]>

---

From: Alper Yegin <[email-masked]>
Date: Mon, 21 Jul 2014 17:47:45 +0300

Hi Jouni,

>   immediate attention. The text has not been changed since

Hopefully, folks who have any comments on the charter text bring that up on the ML in advance of the meeting, so that we can resolve them without using meeting cycles.

> 1.2) have the initial discussion how to proceed after IETF90.

I don't see that on the agenda.

And, can we have the chairs share their thoughts on the plan over the email, so that we can have rounds of discussion on it before the Thu&Fri meetings.
Ideally, those meetings should be where we agree to the plan, not where we hear about them and start thinking&discussing...

>   discussions, so the longer presentations slots are subject

Thanks.

Alper

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 21 Jul 2014 11:10:35 -0400

Hi Jouni,

>   immediate attention. The text has not been changed since

It seems a bit late to comment on the text. The charter text looks fine but I have one comment on para 3:
"Routing based proposals must not propagate routing updates outside the IGP routing domain."

That sounds pretty old-fashion operation because even in an operator's domain we uses multiple ASes that 
independent each other in IGP point of view. So I suggest that using a word of "administrative domain" defined in RFC3753, instead of using "IGP routing domain", such like:

"Routing based proposals must not propagate routing updates outside the administrative domain."

>   possible updates and how the I-D fits under the current

Ack.

>   discussions, so the longer presentations slots are subject

Maybe I have limited time for Friday discussion due to my flight schedule...
--satoru