The DMM charter mentions: … allow for setting up IP networks so that traffic is distributed in an “optimal way”…
So I think that yes it’s a standardization issue and such cases should be considered in the DMM requirements. Best regards, Hassan From: [email protected] [mailto:[email protected]] On Behalf Of Jong-Hyouk Lee Sent: Tuesday, April 23, 2013 11:00 AM To: Moses, Danny Cc: [email protected]; [email protected] Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 Hello Moses On Mon, Apr 22, 2013 at 5:34 PM, Moses, Danny <[email protected]<mailto:[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]<mailto:[email protected]>] Sent: Monday, April 22, 2013 18:13 To: Moses, Danny Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[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]> > [mailto:[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]<mailto:[email protected]>; > [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > [email protected]<mailto:[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/ _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
