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:
1. How long should tunnels be maintained assuming flows can last for a long
time (forever...)
2. How strong is the transparency requirement in terms of finding solutions
that must not require any IP mobility revealing to upper-layer protocols
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.
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
