Subject: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

From: Jouni Korhonen <[email-masked]>
Date: Wed, 10 Apr 2013 10:19:04 +0300

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

---

From: Stig Venaas <[email-masked]>
Date: Wed, 10 Apr 2013 11:06:56 -0700

> reviews (that are more than one liners). The more the better, though.

I believe the document is ready as is.

I responded too late to the first last call, so I'm now responding a
second time.

Stig

> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 15 Apr 2013 23:18:32 +0300

Hi,

My WGLC comments of the I-D as a chair, not the document co-author. I will
also put them one by one into the issue tracker.

- Jouni

1) Abstract

   Management (DMM) in IPv6 deployments.  The traditionally hierarchical
   structure of cellular networks has led to deployment models which are
   in practice centralized.  Mobility management with logically

Why are we only concerned about cellular networks? Could this be generalized?
Next sentences then start talking about mobile networks. Use consistent
language.

2) Abstract

   when needed, and so on.  Distributed mobility management must be
   secure and compatible with existing network deployments and end
   hosts.

I would argue a DMM mechanisms, unless completely done on the network side,
cannot be compatible with existing end host.. It can be backward 
compatible, which means there is a way to allow mixing DMM aware and
legacy hosts in a case the DMM solution would require even a configuration
change in the end host.

3) Warnings from automated IDnits (parsed):

  == Unused Reference: 'I-D.ietf-netext-pd-pmip' is defined on line 580, but
     no explicit reference was found in the text

  == Unused Reference: 'RFC3963' is defined on line 648, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC6224' is defined on line 663, but no explicit
     reference was found in the text

  == The document seems to lack the recommended RFC 2119 boilerplate, even if
     it appears to use RFC 2119 keywords -- however, there's a paragraph with
     a matching beginning. Boilerplate error?

   (ED: maybe putting RFC2119 language into 'front' section using
    <note title="Requirements"> ... </note>)

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

4) Section 1

      a centralized mobility anchor providing global reachability and an
      always-on experience to the user;

      extensions to the base protocols to optimize handover performance
      while users roam across wireless cells; and

      extensions to enable the use of heterogeneous wireless interfaces
      for multi-mode terminals (e.g. smartphones).

o Make this to a bulleted list.

5) Section 1

   The presence of the centralized mobility anchor allows a mobile node
   to remain reachable when it is not connected to its home domain.  The

o "home domain" strikes out, which might not be obvious unless you are
  familiar with mobile (cellular) lingo. Give a reference to a document
  that a reader can read & get familiar with "home domains" and such.

6) Section 1

   and scalability, which require costly network dimensioning and
                                                 
o Ins't distribution dimensioning as well?

7) Section 1

   Moreover, the availability of multi-mode devices and the possibility
   of using several network interfaces simultaneously have motivated the
   development of even more protocol extensions to add more capabilities
   and to combine IP multicasting to the base protocol.  In the end,
   deployment is further complicated with the multitude of extensions.

o While "multi-mode" is correct, within IETF I would say "multiple
  interface host" is better.
o I do not understand how "to combine IP multicasting to the base protocol"
  relates to the paragraph.
o What is the "base protocol" here?

8) Section 1 

   mobile/fixed Internet Service Providers network requires taking into

o Service Providers network (ISP)

9) Section 1 

   strategies such as selective traffic offload (e.g. 3GPP work items
   LIPA/SIPTO [TS.23829]) through alternative access networks (e.g.

o I would replace [TS.23829] with [TS.23.401] since both LIPA/SIPTO are
  part of those document these days and the TR is just a technical
  report.

8) Section 1

   in a truly flat mobile architecture would anchor the traffic closer
   to the point of attachment of the user, overcoming the suboptimal
   route stretch of a centralized mobility scheme.

o This statement is more or less from the IP layer point of view. The
  actual layer-2 aggregation can make the claim of "overcoming route
  stretch" more challenging than it sounds.

9) Section 1

   considerable periods of time [Paper-Locating.User] .  Therefore it is

o misplaced '.'

10) Section 1

   with application intelligence suggest that mobility can be provided
   selectively, thus simplifying the context maintained in the different
   nodes of the mobile network.

o "..mobility could be provided.."
o I would argue that having "simple IP" and "Mobile IP" selectively does
  not simplify the context in the network, it actually makes the network
  side more complex to implement. However, I would agree that it would
  _reduce_ the amount of context maintained in the network.

11) Section 1

   The DMM charter addresses two complementary aspects of mobility
   management procedures: the distribution of mobility anchors towards a
   more flat network and the dynamic activation/deactivation of mobility
   protocol support as an enabler to distributed mobility management.
   The former aims at positioning mobility anchors (HA, LMA) closer to
   the user; ideally, mobility agents could be collocated with the
   management support -- thus reducing the amount of state information
   that must be maintained in various mobility agents of the mobile
   network.  The key idea is that dynamic mobility management relaxes
   some of the constraints of previously-standardized mobility
   management solutions and, by doing so, it can avoid the establishment
   of non-optimal tunnels between two topologically distant anchors.

o expand DMM on the first use (excluding the abstract expansion here).
o "..anchors (HA, LMA).." -> "..anchors (e.g., HA, LMA).."
o The last sentence start discussion about tunnels. They are now mentioned
  for the first time. Where the use of tunnels originated at this point?
  It should be clarified at least with a reference.
o The last sentence states "non-optimal tunnels between two topologically
  distant anchors". Where does that originates? Which protocols we are
  implicitly referring to?

12) Section 2.1

   (3GPP) UMTS networks, CDMA networks, and 3GPP Evolved Packet System
   (EPS) networks employ centralized mobility management too.  In
   particular, Gateway GPRS Support Node (GGSN) and Serving GPRS Support
   Node (SGSN) in the 3GPP UMTS hierarchical network, and the Packet
   data network Gateway (P-GW) and Serving Gateway (S-GW) in the 3GPP
   EPS network, respectively, act as anchors in a hierarchy.

o It is not really UMTS networks, .. rather say GPRS networks.
o Packet Data Network Gateway (P-GW)
o Since in 3GPP example SGSNs and SGWs are taken into anchoring
  discussion, then in GPRS case the text should also discuss RNC, which
  like SGW is the L2 anchor point for base stations.
o The text should be more clear when talking about anchoring that it
  concerns IP layer and specifically user plane traffic. For example,
  3GPP GPRS is rather hierarchical at L2 and mobility is handled at
  every level of hierarchy rather independently.
o Figure 1 is incomplete in case of GPRS. RNC should be in the picture
  as well.
o Figure 1 should change UMTS -> 3G GPRS if RNC is in picture, otherwise
  GPRS is just fine.

13) Section 3.2

  former case only the data plane is distributed.  Fully distributed
   mobility management implies that both the data plane and the control
   plane are distributed.  These different approaches are described in

o Data and control plane separation is not really something we have
  practiced so far in IETF, at least not with the mobility protocols
  developed within IETF. I would give a pointer to further reading to
  architectures that have that separation and mention also IETF developed
  mobility protocols do not have similar concept so far.

14) Section 4.1

   REQ1:  Distributed deployment

o This requirement must imho state why route optimization (MIPv6) or
  localized routing (PMIPv6) as of today are not adequate/enough. The
  requirement text itself is OK but the question above needs an answer.

15) Section 4.2

          example, when, upon change of point of attachment to the
          Internet, an application flow cannot cope with a change in the

o s/Internet/network

   PS5:  Wasting resources to provide mobility support to nodes that do
         not need such support

o s/Wasting/Unnecessarily reserving

         the tunnel, keep alive, etc.) is not turned off for peer-to-

o s/keep alive/keep alive signaling

         keep alives, etc.) wastes network resources for no application

o s/keep alives/keep alive signaling

16) Section 4.5

o Earlier lists were indexed using (a), (b) etc.. here different style
  (1), (2) is used. Choose one style.

17) Section 4.5

   PS7:  (Related problem) Complicated deployment with too many MIP
         variants and extensions

         Deployment is complicated with many variants and extensions of
         MIP.  When introducing new functions which may add to the
         complexity, existing solutions are more vulnerable to break.

o I would argue this "related problem" could be removed. I see REQ5 as
  a requirement for backward compatibility, not a MIP flavour complexity
  issue.

18) Section 4.6

          the mobility support provided by the DMM solution; signaling
          message protection in terms of authentication, encryption,
          etc.; data integrity and confidentiality; opt-in or opt-out
          data confidentiality to signaling messages depending on
          network environments or user requirements.

o Get rid of "etc". It does not really fit in a middle of a list.
o Some rewording needed. The use of semicolon is confusing.

19) Section 4.6

o The security discussed in "motivation" part seems to be mostly about
  the first hop / on-link security. Why not saying that then instead
  of listing a job lot of different threats..

          their traffic.  As signaling messages may travel over the
          Internet, end-to-end security could be required.

o "could" is rather weak.. I would say MUST. Also, e2e security
  between what? That needs to be stated as well.

20) Section 4.7

4.7.  Flexible multicast distribution

   REQ7:  DMM should enable multicast solutions in flexible distribution
          scenario.  This flexibility enables different IP multicast
          flows with respect to a mobile host to be managed (e.g.,
          subscribed, received and/or transmitted) using multiple
          endpoints.

o What is "flexible distribution scenario"? That is not mentioned earlier
  or defined.
o I would reword the section title to something else like plain
  "Multicast" or "Multicast considerations".
o "..using multiple endpoint." is supposed to mean what? I kind of
  understand that as an aggregation or what does it intend to say?

21) Section 4.7

          problems described in PS1 and PS6.

o For readability I would add references to relevant Sections as
  well e.g. "..describer in Section 4.1 PS1 and in Section .."

22) Section 5

   legitimate mobile host/router to access the DMM service; Second, end-
   to-end security that protects signaling messages for the DMM service.

o e2e security between what? Between nodes that participate in the DMM
  protocol as a whole or bilaterally between the end host and some xyz
  functional entity?

23) Section 5

   It is necessary to provide sufficient defense against possible
   security attacks, or to adopt existing security mechanisms and
   protocols to provide sufficient security protections.  For instance,
   EAP-based authentication can be used for access network security,
   while IPsec can be used for end-to-end security.

o EAP-based security does not necessarily address on-link / first
  hop threats. You gain access, and then can fool around.. does not
  sound too promising, unless the security considerations can scope
  the used link type better i.e. in p2p links this might be sufficient
  but not in all.

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 17 Apr 2013 10:22:03 +0300

Folks,

One week left of the WGLC#2.

- Jouni & Julien

---

From: "KIM, BYOUNG-JO J (BYOUNG-JO)" <[email-masked]>
Date: Wed, 17 Apr 2013 15:44:49 -0400

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/

---

From: <[email-masked]>
Date: Fri, 19 Apr 2013 04:05:49 +0000

Hi all,

I am happy with the current version of the DMM draft!

So I think that the draft can proceed with the further IETF review process!

Best regards,

Georgios

________________________________
Van: [email-masked] [[email-masked]] namens Jouni Korhonen [[email-masked]]
Verzonden: woensdag 17 april 2013 9:22
To: [email-masked]
Onderwerp: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

Folks,

- Jouni & Julien

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Fri, 19 Apr 2013 10:13:48 +0200

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-masked]> wrote:

> >> 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:
>
> >> 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:
> 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:
>
> >> 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

-- 
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/

---

From: "KIM, BYOUNG-JO J (BYOUNG-JO)" <[email-masked]>
Date: Fri, 19 Apr 2013 10:01:04 -0400

I wouldn't attempt to rewrite the whole 4.6 REQ6, but I feel it too generic covering many typical security topics that may not be needed.

e.g.,
"DMM protocol solutions MUST consider security aspects, including confidentiality and integrity."

should read

"DMM protocol solutions MUST consider security risks introduced by the DMM service into a network."

Another example: This discussion below is probably not necessary before understanding what kind of risk DMM adds.
"opt-in or opt-out data confidentiality to signaling messages depending on network environments or user requirements."

I don't wanna appear pedantic (I guess that admits it already), but, something like this
"Mutual authentication and authorization between a
          mobile host/router and an access router providing the DMM
          service to the mobile host/router are required to prevent
          potential attacks in the access network of the DMM service."

is discussing solutions already.

Of course we don't know either way yet, but DMM may only need indirect or direct proof of possession of past and new IP addresses, rather than full AAA, to serve its purpose safely.

I hope this helps.

Bests.

J.

Byoung-Jo "J" Kim
AT&T Labs - Research
http://sites.google.com/site/macsbug/

On Apr 19, 2013, at 4:13 AM, Jong-Hyouk Lee wrote:

> 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-masked]> wrote:
> Hi.
>

---

From: "Moses, Danny" <[email-masked]>
Date: Mon, 22 Apr 2013 13:38:56 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Jong-Hyouk Lee
Sent: Friday, April 19, 2013 11:14
To: KIM, BYOUNG-JO J (BYOUNG-JO)
Cc: [email-masked]; [email-masked]
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

Hello, Byoung-Jo

Cheers.

On Wed, Apr 17, 2013 at 9:44 PM, KIM, BYOUNG-JO J (BYOUNG-JO) <[email-masked]<mailto:[email-masked]>> wrote:
Hi.

===================
Comment 1:

====================
Comment 2:

=====================
Comment 3:

====================
Comment 4:

===================

Bests.

Byoung-Jo "J" Kim
AT&T Labs - Research

On Apr 10, 2013, at 3:19 AM, Jouni Korhonen wrote:

> [email-masked]<mailto:[email-masked]>

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm

#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.

---

From: "KIM, BYOUNG-JO J (BYOUNG-JO)" <[email-masked]>
Date: Mon, 22 Apr 2013 11:13:26 -0400

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

---

From: "Moses, Danny" <[email-masked]>
Date: Mon, 22 Apr 2013 15:34:03 +0000

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-masked]] 
Sent: Monday, April 22, 2013 18:13
To: Moses, Danny
Cc: [email-masked]; [email-masked]; Jong-Hyouk Lee
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

J.

Byoung-Jo "J" Kim
AT&T Labs - Research

On Apr 22, 2013, at 9:38 AM, Moses, Danny wrote:

> > 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.
> >
> RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living 
> somewhere between /dev/null and /dev/random
>

---

From: Sérgio <[email-masked]>
Date: Mon, 22 Apr 2013 23:00:03 +0100

Hi,

Below are my comments regarding multicast-related text, as one of the 
co-authors.

> also put them one by one into the issue tracker.
(...)
> o What is the "base protocol" here?

### Comments on 7) ###
SF: In previous version, we tried to motivate for IP multicast 
considerations within the Introduction by touching down previous text 
while addressing the justifiability of DMM. But seeing "to combine IP 
multicasting .." again, it doesn't seem to be perfectly aligned with 
sub-concluding sentence on the availability of multi-mode terminals. 
Additionally, "Base Protocol" was meant to refer to any mobility 
protocol to which multicast support was designed or added as an 
afterthought. So, our revised text is as follows:

-->"Moreover, the availability of multi-mode devices and the possibility 
of using several network interfaces simultaneously have motivated the 
development of even more protocol extensions to add more capabilities 
and to combine IP multicasting to the base protocol. In the end, 
deployment is further complicated with the multitude of extensions.
As an effective transport method for multimedia data delivery, IP 
multicast support, including optimizations, has been introduced but by 
"patching-up" procedures, after completing the design of the reference 
mobility protocol(s), leading to network inefficiency and non-optimal 
routing."
>    understand that as an aggregation or what does it intend to say?
### Comments on 20) ###

SF: Besides the revision of the sub-section title, we also revised REQ7 
and motivation parts to give a better description.

--> "4.7. Multicast Considerations

DMM should enable multicast solutions in flexible distribution scenario. 
This flexibility pertains to the preservation of IP multicast nature 
from the perspective of a mobility entity and transmission of multicast 
packets to/from various multicast-enabled entities. Therefore, this 
flexibility enables different IP multicast flows with respect to a 
mobile host to be managed (e.g., subscribed, received and/or 
transmitted) using multiple endpoints multicast-enabled entities."

Additionally, we revised "motivation" part as follows:

--> "Motivation: The motivation of this requirement is to consider 
multicast early in the design process so that solutions can be developed 
to overcome performance issues in multicast distribution scenario avoid 
network inefficiency issues in multicast traffic delivery. The multicast 
solution may should therefore avoid having multicast-capable access 
routers being restricted to manage restricting the management of all IP 
multicast traffic relative to a host via a single endpoint, which would 
lead to the problems described in PS1 and PS6 through a dedicated 
interface on multicast-capable routers.

>    well e.g. "..describer in Section 4.1 PS1 and in Section .."
### Comments on 21) ###

SF_ Following your suggestion:
--> "This requirement addresses the problems PS1 in Section 4.1. and PS8 
in Section 4.7."

Best regards,
Sérgio

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Tue, 23 Apr 2013 11:00:26 +0200

Hello Moses

On Mon, Apr 22, 2013 at 5:34 PM, Moses, Danny <[email-masked]> wrote:

> 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).
>

> 1. How long should tunnels be maintained assuming flows can last for a

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
>
> 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.
>
> 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.
>
> 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)
>
> > 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
> >
> > 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
> > 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

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Wed, 24 Apr 2013 10:18:23 +0000

|"DMM protocol solutions MUST consider security aspects, including
|confidentiality and integrity."
|
|should read
|
|"DMM protocol solutions MUST consider security risks introduced by the
|DMM service into a network."

I think this is a reasonable suggestion and I second it, although for some this may be considered obvious. In the newly suggested text, I would also s/the DMM service/DMM

Best regards,

Kostas

---

From: <[email-masked]>
Date: Wed, 24 Apr 2013 12:47:00 +0000

Hello,

I also support this suggestion; we only need to consider the new security risks, if any, introduced by DMM.

Regarding the "DMM service" term, it hasn't been defined in the document and it's only used in the security requirement (section 4.6). It's not really clear what this means, even if someone argue that this is obvious for DMM guys, I don't think it's really the right terminology. DMM is rather a new architecture, scheme, protocol.. or let us simply just say DMM.

I second Konstantinos in replacing "the DMM service" by "DMM" in all the security requirement section.

Best regards,
Hassan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Konstantinos Pentikousis
Sent: Wednesday, April 24, 2013 12:18 PM
To: KIM, BYOUNG-JO J (BYOUNG-JO)
Cc: [email-masked]; [email-masked]
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

Best regards,

Kostas

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Wed, 24 Apr 2013 12:53:42 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Jong-Hyouk Lee
Sent: Tuesday, April 23, 2013 11:00 AM
To: Moses, Danny
Cc: [email-masked]; [email-masked]
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-masked]<mailto:[email-masked]>> wrote:
Thanks for the clarification.

It is not the standardization issue even if we may mention it ("session duration" and "session tunneling required") in the DMM requirement document.

The transparency requirement must be addressed in the DMM requirement document, sure.

Cheers.

Regards,
        /Danny

-----Original Message-----
From: KIM, BYOUNG-JO J (BYOUNG-JO) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, April 22, 2013 18:13
To: Moses, Danny
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Jong-Hyouk Lee
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

J.

Byoung-Jo "J" Kim
AT&T Labs - Research

On Apr 22, 2013, at 9:38 AM, Moses, Danny wrote:

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> Jong-Hyouk Lee
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Wed, 24 Apr 2013 17:17:07 +0000

| I am happy with the current version of the DMM draft! 
| So I think that the draft can proceed with the further IETF review process!
| 
| Best regards,
| Georgios
 
I second Georgios' assessment. I think that most of the comments related to editorial aspects, and thus it's time to move this draft forward in the process.

Best regards,

Kostas

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 24 Apr 2013 14:14:30 -0700

Hello folks,

I have many editorial comments which I will submit later today.

However, I think the draft has a major organizational problem. Namely,
the "problem statements", instead of being properly collected together
in an initial section, are sprinkled in along with various statements of
requirements.

I remember there was previously a problem statement draft that
enumerated the PSs in the current requirements draft.  I think it is
O.K. (perhaps not optimal, but O.K.) for the problem statements to
be in the requirements draft, but not as currently situated.

This, along with the various other editorial clarifications that are
needed, lead me to believe that the draft is not yet ready, but I do
not think that there are major problems, and that the next draft
probably could be ready for advancement.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 24 Apr 2013 17:24:10 -0700

Hello again folks,

I can't type in all the editorial suggestions right now, but at least
I wanted to provide some overall comments that cause the
document to seem quite inaccurate in many of its claims.
Here are my general comments.

- The requirements need to be distinguished from the desirable features.
   For instance, section 4.7 describes a desirable feature, not a 
requirement.
   Moreover, the desirable feature may be unattainable.  This is important,
   because if feature is *required*, a solution not providing the *required*
   feature "must" be considered incomplete and rejected.

- The problem statement clauses should be located in an initial section.
   Each problem statement should have a motivation.

- There is no problem statement supporting sections 4.4 or 4.6

- There is no motivation for section 4.4

- There is nothing specific to DMM in sections 4.4 or 4.6

- Section 5 should cross-reference section 4.6, and they should both
   be rewritten to eliminate redundant extra verbiage of which there is
   too much.

- PS7 claims that deployment (of "something":  existing IETF solutions?)
   is too complicated.  Compared to what???  3GPP solutions?? Dozens
   of incompatible clunky slow portal authentication design botches?
   This point strikes me as basically wrong, but it can be rescued if a
   target level of deployment complexity is described.

- REQ3 claims that we should target IPv6 because of tools available for IPv6
   that are not available for IPv4.  Please identify at least one.

- Section 1 claims that user traffic patterns have shifted to become
   more localized.  This is probably false, but I can imagine several
   ways to change it so that it becomes true.  It is important for this
   purpose to clarify what is intended by "peer communications".

- What is an "IP session"?  Wasn't IP supposed to be connectionless?
   I strongly suggest not trying to define such a thing.  Perhaps it
   was intended to indicate a "flow" instead.

- It is claimed that a centralized architecture requires more resources
   than a distributed architecture.  This is usually false.  For instance,
   if a centralized node requires 100 units, and 100 distributed nodes each
   require 1.03 units, the distributed architecture requires 3 more units
   overall.  Even so, the additional expense of the distributed architecture
   would often be a bargain for reasons of redundancy, resiliency, etc.

I will do the editorial suggestions tomorrow.  Also I can volunteer to
rewrite various parts if extra effort is needed.

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: Alper Yegin <[email-masked]>
Date: Fri, 26 Apr 2013 10:56:27 +0300

Hi Charlie,

>  overall.  

This would be true for tasks that can be performed either on the distributed node or on the central node.
But the essential task for DMM systems, IP forwarding, is not of that nature.
In centralized architecture, that task needs to be performed *both* at the edge node and also at the central node (and in fact even in between) before the packets hit the Internet/mobile device.

> Even so, the additional expense of the distributed architecture

Alper

---

From: "Seil Jeon" <[email-masked]>
Date: Fri, 26 Apr 2013 14:18:26 +0100

Hi Charles,

Actually, in realizing DMM-based mobility management, as you know, they may
exist various ways or more requirements for DMM protocol deign tackling the
issues raised from CMM. Given the requirements defined in the document is
confining, in their ways, explicitly or implicitly the protocol design for
further steps.
It means that proposed solutions should satisfy or consider the
requirements, or they will not be DMM solution in DMM WG at least.

If you see the mail posted by Sergio a few days ago, the multicast part
title was changed with 'Multicast Considerations' for right meaning. With
the meaning, I think it would go together with the other requirements. Have
a look, please.

Regards,
Seil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Charles E. Perkins
Sent: Thursday, April 25, 2013 1:24 AM
To: [email-masked]
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

Hello again folks,

I can't type in all the editorial suggestions right now, but at least I
wanted to provide some overall comments that cause the document to seem
quite inaccurate in many of its claims.
Here are my general comments.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 26 Apr 2013 17:13:26 -0700

Hello Seil,

You suggest that if a feature is not listed as a requirement, it cannot be
considered during the evaluation of solution proposals.  This is not true.
Given the choice of two proposals, the one that meets the requirements
and offers the best other features will invariably be chosen.

The real danger is in disqualifying good proposals because they fail to
offer some feature that should not have been made into a requirement.
There is no harm in listing desirable features (like multicast) that would
enhance the value of a solution that meets the requirements.

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 26 Apr 2013 17:44:00 -0700

Hello Alper,

I agree with your point, but it means that the total cost of
the distributed solution is even more expensive.... right?

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: Alper Yegin <[email-masked]>
Date: Mon, 29 Apr 2013 15:29:20 +0300

Hi Charlie,

No, it should be less.

Distributed solution: Take IP traffic directly from access router to the Internet.
Centralized solution: Take IP traffic from access router to a core router to the Internet.

The latter suggests more CAPEX and OPEX.

Alper

---

From: "Seil Jeon" <[email-masked]>
Date: Tue, 30 Apr 2013 11:52:15 +0100

Hi Charlie,

Honestly, I don't know whether how it would be a feature or not. But I know
that the current multicast part is one of the requirements/considerations
the DMM should take into account. Actually, we need to think of the reason
why it is important. Existing approaches were a "patching-up" style that
first, base multicast support design has been made on the reference
protocol, then optimizations and extensions have been followed, thus leading
to the unnecessities to the reference protocol and the inefficiencies to the
network. I think this approach has been O.K. until now because IP mobility
support itself and enhancement for unicast has been first. But now I believe
we're in the slightly different stage when contemplating the ultimate goals
and expected effects by the DMM. So, I think we need to consider the
requirement reflecting such a concern at the initial stage. And current
multicast requirement does not prevent to appear 'good proposals' but only
provides the minimum guidelines of IP multicast deployment in the DMM we
want to define.

Best Regards,
Seil

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]] 
Sent: Saturday, April 27, 2013 1:13 AM
To: Seil Jeon
Cc: [email-masked]
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

Hello Seil,

You suggest that if a feature is not listed as a requirement, it cannot be
considered during the evaluation of solution proposals.  This is not true.
Given the choice of two proposals, the one that meets the requirements and
offers the best other features will invariably be chosen.

Regards,
Charlie P.

On 4/26/2013 6:18 AM, Seil Jeon wrote:
> Hi Charles,
>
> Actually, in realizing DMM-based mobility management, as you know, 
> they may exist various ways or more requirements for DMM protocol 
> deign tackling the issues raised from CMM. Given the requirements 
> defined in the document is confining, in their ways, explicitly or 
> implicitly the protocol design for further steps.
> If you see the mail posted by Sergio a few days ago, the multicast 
> part title was changed with 'Multicast Considerations' for right 
> meaning. With the meaning, I think it would go together with the other 
> requirements. Have a look, please.
>
>
> Regards,
> Seil
>
>
> I wanted to provide some overall comments that cause the document to 
> seem quite inaccurate in many of its claims.

--
Regards,
Charlie P.