Re: draft-yegin-ip-mobility-orchestrator-00.txt
Jouni Korhonen <[email protected]>
| Newsgroups | gmane.ietf.nemo |
|---|---|
| Message-ID | <[email protected]> |
Alper, 7/16/2014 9:40 AM, Alper Yegin kirjoitti: > Hi Jouni, > > Thank you for the review and feedback. > Please see below. > >> >> Alper, >> >> I had a quick read on the document. There are few places that I need clarification for my own education.. since I have a feeling that the text does not say everyting it assumes a priori. Furthermore, I got some more editorial comments. >> >> Section 3. says: >> >> Solutions operating above the IP layer include MPTCP, SCTP, SIP, and >> application-specific ones. Availability of these protocols cannot be >> >> I would add references to SCTP and SIP specifications that actually add the handover functionality to the listed protocols. Also, there could be more protocols to add like DCCP.. >> > > OK. > >> During the handovers are multiradio cases ruled out or also applicable or even assumed? I cannot see that clearly from the motivation or solution part. >> > > Just like for any of our base IETF protocols, we cannot assume multiple radios exist on a given node. > So, this solution works even for single-radio nodes. Ok.. I get confused by Figure 1 saying the sub-IP mobility is PMIPv6. AFAIR what is in figure is somewhat stretching what PMIPv6 does now. That is also what I meant about assumptions that are not said. >> Section 4.1. says: >> >> data-path optimization. On the other hand, above-IP solutions >> provide data-path optimization but fail to provide seamless >> handovers. The ideal solution would be based on coordianted >> >> I do not agree this fully. "Above-IP solution" allow seamless handovers in cases where you can have multiple radios on simultaneously. >> > > That's right. But we are providing a solution for the general case where there's only one connected radio. > We can add "multi-radio" considerations (as a special case) in the next version of the draft. > >> In Figure 2. and the related text: >> >> What is unclear to me is s-GW would keep the IP1 when the MN attaches to t-GW. What is the background assumption here? Is MN attached to both GWs simultaneously? >> > > > The MN has a single radio connection. But, it can maintain its previous IP address with the help of a tunnel between the s-GW and the MN or t-GW. > This is what we call "access network anchoring". I might be a good idea to clarify that a handover from s-GW to t-GW specifically with a single radio does not cause s-GW to think the MN is not under its control anymore.. even if the s-GW notices that the MN has lost the radio connectivity. Same also on the MN side.. even if the radio connectivity to the s-GW was lost, it does not imply discarding the IP from the interface.. - Jouni > > Alper > > > > >> - Jouni >> >> >> 7/4/2014 10:10 AM, Alper Yegin kirjoitti: >>> Hello DMMers, >>> >>> We have a new I-D for your reading and discussion. >>> >>> Title : IP Mobility Orchestrator >>> Authors : Alper Yegin >>> Jungshin Park >>> Kisuk Kweon >>> Jinsung Lee >>> Filename : draft-yegin-ip-mobility-orchestrator-00.txt >>> Pages : 13 >>> Date : 2014-07-03 >>> >>> Abstract: >>> Host stacks can support mobility at multiple layers. Mobility >>> protocols operating at different layers constitute alternate >>> solutions with various pros and cons, and they can also have adverse >>> affects on each other when used simultaneously. Optimal results in >>> terms of seamless handover and data-path optimization can be achieved >>> when execution of these protocols are coordinated. >>> >>> We'll also be submitting an IPR statement to IETF. >>> >>> https://datatracker.ietf.org/doc/draft-yegin-ip-mobility-orchestrator/ >>> >>> Please review this I-D and share your comments. >>> >>> Thanks, >>> >>> Alper >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> dmm mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/dmm >>> >