Hello Moses
On Mon, Apr 22, 2013 at 5:34 PM, Moses, Danny <[email protected]> wrote: > Thanks for the clarification. > > Yes, there was a misunderstanding on my part. I thought you were implying > that sometime in the future, we should remove that requirement (hence my > reply about backwards compatibility). > > So actually we have two issues here: > Yes here we have the two issues, but we need to distinguish them: > 1. How long should tunnels be maintained assuming flows can last for a > long time (forever...) > It is not the standardization issue even if we may mention it ("session duration" and "session tunneling required") in the DMM requirement document. > 2. How strong is the transparency requirement in terms of finding > solutions that must not require any IP mobility revealing to upper-layer > protocols > The transparency requirement must be addressed in the DMM requirement document, sure. Cheers. > > As to the first issue, I think that dmm should behave in that sense line > PMIP. Whether there is one centralized MA or several distributed MAs should > not change the traffic flow (hence, alas, the tunnels must be maintained as > long as there are flows that require them). > > As to the second issue, as I mentioned in my previous note, I believe that > REQ2 should allow the ability of upper-layers notification for optimization > purposes only. > > Regards, > /Danny > > -----Original Message----- > From: KIM, BYOUNG-JO J (BYOUNG-JO) [mailto:[email protected]] > Sent: Monday, April 22, 2013 18:13 > To: Moses, Danny > Cc: [email protected]; [email protected]; Jong-Hyouk Lee > Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 > > I get the feeling we are of similar opinion, but I am afraid the wording > is not working for me. > > I observe many IP flows lasting many days in some networks. > I don't think you actually want to maintain their connections via tunnels > or what not for that long, if they have been moving about. > > In fact, these are (mostly) flows that can handle subnet changes behind > the scenes, since they are usually push notification, SIP signaling, or > chat server presence connections, that monitor and reconnect if underlying > network connections are broken. > > So, it's not infinity. Then there is some number. > > DMM should be a "temporary" help to keep packet losses low and give time > for apps to prepare a new connection, or hide rapid succession of subnet > changes for a limited time. > > That's what I think it should mean by backward compatibility. > > If you must hide subnet changes to all apps forever, then we cannot have > DMM. > Some apps would break, but I think most of them are not important now or > in the future, and if they wish to be used in mobile environment, they must > adapt. (and/or the OS) > > I would like the requirement to say it. > > J. > > Byoung-Jo "J" Kim > AT&T Labs - Research > http://sites.google.com/site/macsbug/ > > > On Apr 22, 2013, at 9:38 AM, Moses, Danny wrote: > > > Hi, > > > > Regarding the first comment about transparency to upper layers, I agree > that this is a very limiting requirement but also think it is a crucial one > for backwards compatibility. So I do not think we can lighten it by > defining a time limit. > > > > However, we can allow optimization features that rely on upper-layer > protocols (or applications) being aware of IP layer mobility as long as > these are for optimization only. This means that upper-layer > protocols/applications that are NOT aware of IP mobility will continue to > work correctly but without extra optimization that those which ARE aware > will utilize. > > > > In fact, I believe that we should modify the REQ2 to allow features that > are not transparent to upper layers as long as backwards compatibility is > maintained. > > > > Regards, > > /Danny > > > > From: [email protected] [mailto:[email protected]] On Behalf Of > > Jong-Hyouk Lee > > Sent: Friday, April 19, 2013 11:14 > > To: KIM, BYOUNG-JO J (BYOUNG-JO) > > Cc: [email protected]; [email protected] > > Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 > > > > Hello, Byoung-Jo > > > > Regarding your comments on the security text, for your comment 2, I do > not quite get you. Provide clear text expressing your concern then I will > review and try to reflect to the draft. For your comment 5, just you need > to be sure that the given text is about the general security consideration. > > > > Cheers. > > > > > > On Wed, Apr 17, 2013 at 9:44 PM, KIM, BYOUNG-JO J (BYOUNG-JO) < > [email protected]> wrote: > > Hi. > > > > Below are my comments on the draft-ietf-dmm-requirements-03. > > > > Overall, the draft has much to admire and agreeable on most points. > > Kudos to the authors. > > > > > > =================== > > Comment 1: > > > > REQ2: Transparency to Upper Layers when needed > > > > >> I would like to suggest that DMM must provide transparency to upper > layers for a limited time only when needed. Upper layer protocols or > applications that are unaware of IP layer mobility and IP address changes > cannot be supported indefinitely, without compromising the purpose of DMM. > How much time is of course another matter, but that can be discussed during > design or even dynamic. > > In time, applications and upper layer protocols will have to be updated > to handle IP address changes by reconnect or other means, as long as DMM > provides temporary shield from packet losses or other disruptions and buy > them time to make preparations. > > > > ==================== > > Comment 2: > > > > REQ6: Security considerations > > > > >> I think the requirements described here may give the impression that > DMM excludes ephemeral security for the purpose of routing to the correct > entities, but not necessarily tied to service authorizations or identities. > Also, protection requirements beyond what current ISPs deal with for their > access routers seem unnecessary. DMM's own security should be limited to > risks that DMM adds to the access network, not the whole access network > security. > > > > ===================== > > Comment 3: > > REQ7: DMM should enable multicast solutions in flexible distribution > scenario. > > > > >> I lack the necessary knowledge on multicast but this seems like a > feel-good statement without a point. I suggest to drop this requirement or > make a clearer statement like "DMM should allow multicast to survive IP > layer mobility without packet loss", or more modestly, "DMM should not > foreclose multicast support during IP layer mobility.", etc.. > > > > ==================== > > Comment 4: > > > > 5. Security Considerations > > Distributed mobility management (DMM) requires two kinds of security > > considerations: First, access network security that only allows a > > legitimate mobile host/router to access the DMM service; Second, end- > > to-end security that protects signaling messages for the DMM service. > > > > >> Related to my Comment 2, "access network security" is confusing here, > as it often means allowing access to the network to begin with. DMM must > assume that is already done at least in the lower layer or even IP layer. > It may or may not offer DMM service to anyone or only to authorized > devices/users. I think DMM must cover the situation where the service is > offered to anything that asks for it, while ensuring the packets are not > redirected to wrong directions. > > > > =================== > > > > Bests. > > > > Byoung-Jo "J" Kim > > AT&T Labs - Research > > https://sites.google.com/site/macsbug/ > > > > > > On Apr 10, 2013, at 3:19 AM, Jouni Korhonen wrote: > > > > > Folks, > > > > > > This mail starts a two week WGLC #2 for draft-ietf-dmm-requirements-03. > > > The issues, even editorials, must be recorded into the Issue > > > Tracker, otherwise they are likely to be neglected. We require > > > minimum three reviews (that are more than one liners). The more the > better, though. > > > > > > The WGLC ends on Wednesday 24rd April. > > > > > > - Jouni & Julien > > > _______________________________________________ > > > dmm mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/dmm > > > > _______________________________________________ > > dmm mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dmm > > > > > > > > -- > > RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living > > somewhere between /dev/null and /dev/random > > > > #email: jonghyouk (at) gmail (dot) com > > #webpage: http://sites.google.com/site/hurryon/ > > --------------------------------------------------------------------- > > A member of the Intel Corporation group of companies > > > > This e-mail and any attachments may contain confidential material for > > the sole use of the intended recipient(s). Any review or distribution > > by others is strictly prohibited. If you are not the intended > > recipient, please contact the sender and delete all copies. > > > > --------------------------------------------------------------------- > A member of the Intel Corporation group of companies > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > -- RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jonghyouk (at) gmail (dot) com #webpage: http://sites.google.com/site/hurryon/
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
