Hi Jouni, I can see it now…. A solution where IGP and PMIP are used hand-in-hand within a domain…. IGP is used between the border gateway and the LMA, PMIP is used between the LMA and MAG. This solution allows LMA switch.
I'd say, this is a valid solution that deserves consideration. But I'd also say that this goes into the same bin as several other solutions. In other words, it's already captured in the scope w/o any special designation (such as "anchor re-selection"). I recommend we recognize that this is a possible candidate solution, and not refer to "anchor re-selection" in the charter. If someone wants to keep that term in the charter, then we need to change it to something more representative of the intent, and then discuss why this type of a solution deserves a dedicated deliverable in the charter. Alper On Jun 9, 2014, at 5:19 PM, Jouni Korhonen wrote: > Alper, > > 6/9/2014 4:21 PM, Alper Yegin kirjoitti: >> 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? > > Yes. (except that retaining the IP address depends on the use case) > >> 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? > > Routing trick is probably needed, yes. If the current toolbox outside DMM is > not adequeate, DMM could well define, for example, an extension to some > popular IGP. > >> >> And, there needs to be context transfer between LMA1 and LMA2. Is that in >> scope of DMM? > > Context transfer is probably needed, yes. Whether that is in scope of DMM > depends.. the context is typically rather system / vendor specific, I would > lean towards context being outside DMM. If someone insists, defininig a set > of "mandatory" information elements could do. However, the value of such > document is debateable. > >> >> And there needs to be a tunnel update between MAG1 and LMAs. That's in >> scope? > > I would assume, in the example PMIP case, the current stuff there is, is not > enough. So for IETF defined protocols such as PMIP there would potentially be > enhancements required (or clarifying the use of existing mechanisms in a new > use case). > >> >> …. >> >> >> 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". > > Fine. > >> >> I wonder if this is proposed (perceived) as a "DMM solution", or something >> that would co-exist with DMM solutions… > > Good question. I rather see it myself as a transition solution to something > more DMMish, so "co-existing" would suite better. Others may have different > opinions. > > - Jouni > > >> >> 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
