Alper,
Hmm, I already read it in a way myself I said below but that seems to be
only me. I'll try to reformulate the text..
- Jouni
6/9/2014 4:24 PM, Alper Yegin kirjoitti:
So, Jouni,
Is this saying "Some solutions' applicability may be limited to administrative domains (i.e.,
not Internet-wide)", and the point is "DMM WG can accept such solutions"?
Whatever the point we are trying to make, we better spell it out.
Alper
On Jun 9, 2014, at 9:35 AM, Jouni wrote:
On Jun 6, 2014, at 6:52 PM, Alper Yegin wrote:
Hi John,
My reading of that sentence is different.
To me it says "We cannot assume that the solutions we are developing would be
available on all networks across the Internet".
The highlighted text intend to say:
unless the mobile node is made explicitly aware (by the network)
of the fact that the prefix/address it got will guarantee IP session
continuity, the mobile node cannot assume it to remain unchanged
infinitely when doing handovers and such.. the prefix/address may
remain unchanged e.g. within a limited are e.g. as long as the
mobile node remains within one administrated network domain.
- JOuni
While I'd agree with that statement, I don't know what it really means for our
solution design.
Some of our solutions may not be present in a network, hence the MN cannot use
them. OK…. and??
In my reading, it does not say the following: "Network cannot always provide IP
session continuity, hence we need to define solutions that can deal with this".
(e.g., using MPTCP, or restarting flows, or some other magic, etc.).
I don't think the intent of that sentence is this. And therefore, I don't think that
sentence is related to "anchor re-selection".
Alper
On Jun 6, 2014, at 5:56 PM, John Kaippallimalil wrote:
Hi Alper, All:
Towards the end of the charter, there is a paragraph that states:
"Although the maintenance of stable home address(es) and/or prefix(es)
and upper level sessions is a desirable goal when mobile hosts/routers
change their point of attachment to the Internet, it is not a strict
requirement. Mobile hosts/routers should not assume that IP
addressing including home address(es) and/or home network prefix(es)
remain the same throughout the entire upper level session lifetime,
or that support for mobility functions is provided on the network side
in all conditions, unless these properties are specifically indicated
to the mobile node and its applications from the network."
I suppose this clarifies that the “anchor re-selection” can apply to a single
session also?
BR,
John
-----Original Message-----
From: dmm [mailto:[email protected]] On Behalf Of Alper Yegin
Sent: Friday, June 06, 2014 9:38 AM
To: Jouni Korhonen
Cc: [email protected]
Subject: Re: [DMM] draft charter text updates in github..
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.
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
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.
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
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
