Re: demand for DMM traffic steering

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
>
>
>
> From: Marco Liebsch <[email protected]
> <mailto:[email protected]>>
> Date: Wednesday, July 16, 2014 2:42 AM
> To: Sri Gundavelli <[email protected] <mailto:[email protected]>>,
> "Hirschman, Brent B [CTO]" <[email protected]
> <mailto:[email protected]>>, Alper Yegin <[email protected]
> <mailto:[email protected]>>
> Cc: "[email protected] <mailto:[email protected]>" <[email protected]
> <mailto:[email protected]>>
> 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.
>
> 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 protected]]
> *Sent:* Mittwoch, 16. Juli 2014 07:18
> *To:* Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin
> *Cc:* [email protected] <mailto:[email protected]>
> *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.
>
> 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 protected]
> <mailto:[email protected]>>
> *Date: *Tuesday, July 15, 2014 1:27 PM
> *To: *"Hirschman, Brent B [CTO]" <[email protected]
> <mailto:[email protected]>>, Sri Gundavelli <[email protected]
> <mailto:[email protected]>>, Alper Yegin <[email protected]
> <mailto:[email protected]>>
> *Cc: *"[email protected] <mailto:[email protected]>" <[email protected]
> <mailto:[email protected]>>
> *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
>
> *From:*Hirschman, Brent B [CTO] [mailto:[email protected]]
> *Sent:* Dienstag, 15. Juli 2014 21:10
> *To:* Sri Gundavelli (sgundave); Marco Liebsch; Alper Yegin
> *Cc:* [email protected] <mailto:[email protected]>
> *Subject:* RE: [DMM] demand for DMM traffic steering
>
> 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 protected]] *On Behalf Of *Sri Gundavelli
> (sgundave)
> *Sent:* Tuesday, July 15, 2014 1:33 PM
> *To:* Marco Liebsch; Alper Yegin
> *Cc:* [email protected] <mailto:[email protected]>
> *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 protected]
> <mailto:[email protected]>>
> *Date: *Tuesday, July 15, 2014 11:20 AM
> *To: *Sri Gundavelli <[email protected] <mailto:[email protected]>>,
> Alper Yegin <[email protected] <mailto:[email protected]>>
> *Cc: *"[email protected] <mailto:[email protected]>" <[email protected]
> <mailto:[email protected]>>
> *Subject: *RE: [DMM] demand for DMM traffic steering
>
> 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 protected]]
> *Sent:* Dienstag, 15. Juli 2014 16:09
> *To:* Alper Yegin
> *Cc:* Marco Liebsch; [email protected] <mailto:[email protected]>
> *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.
>
> 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
>
> *From: *Alper Yegin <[email protected] <mailto:[email protected]>>
> *Date: *Tuesday, July 15, 2014 4:01 AM
> *To: *Sri Gundavelli <[email protected] <mailto:[email protected]>>
> *Cc: *Marco Liebsch <[email protected]
> <mailto:[email protected]>>, "[email protected] <mailto:[email protected]>"
> <[email protected] <mailto:[email protected]>>
> *Subject: *Re: [DMM] demand for DMM traffic steering
>
> 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:
>
>
>
>
> Alper – That can be fixed.
>
> Sri
>
> *From: *Alper Yegin <[email protected] <mailto:[email protected]>>
> *Date: *Saturday, July 12, 2014 12:36 AM
> *To: *Sri Gundavelli <[email protected] <mailto:[email protected]>>
> *Cc: *Marco Liebsch <[email protected]
> <mailto:[email protected]>>, "[email protected] <mailto:[email protected]>"
> <[email protected] <mailto:[email protected]>>
> *Subject: *Re: [DMM] demand for DMM traffic steering
>
> Sri and Marco,
>
> Is any of what you are describing captured in the existing drafts? If
> so, please provide the pointers.
>
> 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.
>
>
>
> _______________________________________________
> dmm mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmm
>