Jouni, OK, let's go with the PMIP example….
Let's say there's an ongoing flow, Flow1, via MAG1 and LMA1. You are talking about switching LMA2 with LMA1, while maintaining MAG1 and not breaking Flow1 (i.e., retaining the same IP address), right? Assuming LMA1 and LMA2 are not on the same IP subnet, then there'd need to be some routing trick between the LMAs and the Internet, so that IP traffic is steered towards LMA2 instead of LMA1. I presume this trick is outside the scope of DMM. Correct? And, there needs to be context transfer between LMA1 and LMA2. Is that in scope of DMM? And there needs to be a tunnel update between MAG1 and LMAs. That's in scope? …. If we take a step back and look at this… This probably deserves to be called "LMA-switch", or more generically "IP anchor switch". Not really a mere "anchor re-selection". I wonder if this is proposed (perceived) as a "DMM solution", or something that would co-exist with DMM solutions… Alper On Jun 9, 2014, at 9:30 AM, Jouni wrote: > > On Jun 6, 2014, at 5:37 PM, Alper Yegin wrote: > >> Hello Jouni, DMM folks, >> >> We better clarify what "anchor re-selection" stands for. >> If it is about selecting different anchors for different IP flows, that's >> one thing. > > This we can do today.. all CMIP, PMIP, GTP allows that assuming > the new flow entails an allocation of a new home address / prefix. > Let's call this case1 > >> If it is about changing the IP anchor in the middle of an IP flow, that's >> another thing. And that other thing needs to be scoped out. A basic > > This is what we had in mind when writing the "anchor re-selection". > let's call this case2. So, which "other thing" you want to scope out? > Case 1 or 2? > >> understanding of a use case would be appreciated (just an explanation for >> discussion, I'm not asking for another I-D!), and identification of various >> aspects of that scenario which translate to work items for DMM WG. > > The "PMIP" use case I had in mind is a mechanism to move all or a > subset of mobility sessions from LMA1 to LMA2 for ongoing sessions. > Geo-redundancy or just a better "topological location" could be where > such is needed. Obviously this does not need to be PMIP specific but > when looking from exiting protocols point of view, it kind of was > obvious choice for an example. > > The re-selection involves for example making MAG (or equivalent node) > aware of the move, possibly moving the mobility state/context between > anchors and making sure traffic routing gets correct downstream to > the correct anchor (preferably no tunneling between anchors). > > - Jouni > > >> >> I won't be in the call today. So, consider this for a discussion. Follow up >> on the mailing list afterwards would be good. >> >> Cheers, >> >> Alper >> >> >> >> On Jun 6, 2014, at 2:47 PM, Jouni Korhonen wrote: >> >>> Folks, >>> >>> Minor changes.. >>> >>> https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt >>> >>> IMHO..the charter as it is today, would allow pretty much any solution from >>> legacy anchoring to herd of pigeons carrying IP.. ;-) >>> >>> I have put in editorial changes of my own and clear text proposals received >>> from others. >>> >>> - Jouni >>> >>> _______________________________________________ >>> dmm mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/dmm >> > _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
