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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
