Re: ticket #38

Hi Anthony,

I agree on the changed REQ1 title from distributed deployment to distributed
processing, in the sense that the main points in DMM lies on how effectively
DMM can distribute workload processing concentrated at single anchor.

If my sense is right, looking at the text, "~ so that traffic does not need
to traverse ... avoid non-optimal routes." doesn't seem to fit in well with
the title.
If we say "distributed processing", it has a meaning for load balancing,
which can be implemented in a centralized mobility management.

In conclusion, "distributed processing" and "optimal routes" come to me as
two different subjects. The latter can be achieved through the former or in
CMM. My opinion is not to get back to the previous title, but we need to
distinguish them clearly.

Regards,
Seil

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of h chan
Sent: Friday, August 02, 2013 9:24 AM
To: Brian Haberman; [email protected]
Subject: Re: [DMM] ticket #38

I am uploading version 07 with the following:

   REQ1:  Distributed processing

          IP mobility, network access and routing solutions provided by
          DMM MUST enable distributed processing for mobility management
          so that traffic does not need to traverse centrally deployed
          mobility anchors and thereby avoid non-optimal routes.

(deleted IP session)

   REQ7:  Multicast considerations

          DMM SHOULD consider multicast early so that solutions can be
          developed not only to provide IP mobility support when it is
          needed, but also to avoid network inefficiency issues in
          multicast traffic delivery (such as duplicate multicast
          subscriptions towards the downstream tunnel entities).  The
          multicast solutions should therefore avoid restricting the
          management of all IP multicast traffic to a single host
          through a dedicated (tunnel) interface on multicast-capable
          access routers.

(deleted IP multicast session)

H Anthony Chan

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Brian
Haberman
Sent: Thursday, August 01, 2013 2:35 PM
To: [email protected]
Subject: Re: [DMM] ticket #38

I agree with Charlie's request to move away from the term "session".  It
really does not have much meaning in UDP-based applications.  However, the
term "flow" does have some issues as well.  Are we using the term "flow" the
way it is defined in RFC 5101?  If not, then it needs to be defined in this
draft.

Regards,
Brian

On 8/1/13 8:09 AM, h chan wrote:
> Charles,
> Is the following change from "IP multicast sessions" to "multicast flows"
okay?
>
> REQ7: Multicast:
> Version 06: DMM SHOULD consider multicast early so that solutions can 
> be developed not only to provide IP mobility to keep IP multicast sessions
when it is needed, but also to avoid network inefficiency issues in
multicast traffic delivery (such as duplicate multicast subscriptions
towards the downstream tunnel entities). The multicast solutions should
therefore avoid restricting the management of all IP multicast traffic to a
single host through a dedicated (tunnel) interface on multicast-capable
access routers.
>
> REQ7: Multicast:
> Version 07: DMM SHOULD consider multicast early so that solutions can 
> be developed not only to provide IP mobility to keep multicast flows when
it is needed, but also to avoid network inefficiency issues in multicast
traffic delivery (such as duplicate multicast subscriptions towards the
downstream tunnel entities). The multicast solutions should therefore avoid
restricting the management of all IP multicast traffic to a single host
through a dedicated (tunnel) interface on multicast-capable access routers.
>
> H Anthony Chan
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of 
> Charles E. Perkins
> Sent: Saturday, April 27, 2013 2:19 AM
> To: [email protected]
> Subject: [DMM] Editorial suggestions for
> draft-ietf-dmm-requirements-03
>
> Hello folks,
>
> Here are some editorial suggestions for the document.
>
> Check for missing articles.  For instance:
> "Gateway selection mechanism"  -->  "A gateway selection mechanism"
>
> "is also taking the"  -->  "also takes"
>
> Delete "However" before "assigning".
>
> Delete "Issues such as"
>
> Delete "When demand exceeds capacity,"  or else explain why the benefits
are unavailable otherwise.
>
> "In particular, there is an increase in direct communications among
>      peers in the same geographical area."
>             --> there has always been such locality... in fact maybe less
>                   now than previously.  Otherwise, please provide a
citation.
>
> Delete "While deploying"
>
> "today's mobile networks, service providers face"  -->
>              "Today's mobile networks present service providers with"
>
> Delete "more often than not,"
>
> Delete "Therefore it is not uncommon to observe that"
>
> "ever-increasing" -->  "unnecessary"
>
> "provided"  -->  "managed"
>
> "non-optimal"  -->  "unnecessary"
>
> Delete "Given this motivational background in this section,"
>
> "address these problems":  at this point in the document, the
>                   problems have not been identified.  As suggested
earlier,
>                   there should be a section devoted to listing the
problems,
>                   and then a cross reference to that section could go
here.
>
> "changing IP address"  -->  "locator IP address"
>
> Insert "The" before "Gateway GPRS Support Node"
>
> "respectively, act"  -->  "all act"
>
> "SAE"  -->  "EPC"
>
> "closeby"  -->  "nearby"
>
> Center figure 2.  (and might as well center figure 1 too)
>
> "future flat IP-based"  -->  "flat IP-based"
>                   (unwise to predict the future)
>
> "states the requirements as follows" -->
>                                                  "identifies the following
requirements"
>
> "Distributed deployment"  -->  "Distributed processing"
>                   ... also in "REQ1"
>
> "of IP sessions"  -->  "of some flows"
>
> "an optimal manner"  -->  "to avoid known bottlenecks"
>
> "This requirement addresses problems PS1, PS2, PS3, and PS4 in the
>      following."
>                   ...  the following ?what?
>
> "each MN therein" .... the MNs are not "in" the tunnel, and they are
>                                                   not "in" the mobility
anchor.
>
> "Centralized anchoring"  -->  "Centralized anchoring designs"
>
> "Distributing
>            the tunnel maintenance function and the mobility context
>            maintenance function among different network entities can
>            increase scalability."
>                   -->  only when the signaling protocol is properly
designed.
>
> "is to be inline"  -->  "conforms"
>
> "may need to interoperate with a network or mobile hosts/
>             routers that do not support DMM protocols."
>                   ... this is technically infeasible.
> Suggested replacement:
> "may need to co-exist with a network or mobile hosts/
>             routers that do not support DMM protocols."
>
> Delete "The motivations of this requirement are"
>
> --
> Regards,
> Charlie P.
>
> _______________________________________________
> dmm mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmm
> _______________________________________________
> dmm mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmm
>

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