Re: [DMM] interims i.e. teleconferences..

2014-07-30 Thread Carlos Jesús Bernardos Cano
Hi Jouni, all,

I don't have major comments to the charter (though I'll try to perform a
careful reading later on). However, I'm very interested in participate
in the work ahead on DMM, and therefore I'd like to participate in the
telcos where the structuring will be discussed.

I'll be off on holidays from August 11th to September, 4th, and I guess
I will not be the only one in a similar situation (at least among the
folks in Europe). Therefore, I'd like to request resuming the work on
the structuring in mid September, when all people are back and now
concentrate in the charter (it might be also good to start discussing on
work items after getting the charter approved by the IESG). If we have
waited for some years to get here, I guess we can wait a couple more
weeks :D.

Thanks!

Carlos

On Wed, 2014-07-30 at 11:37 +0300, Jouni Korhonen wrote:
> Folks,
> 
> 14th or 15th Aug are the next possible dates for an interim telco (1-2h 
> duration). To accommodate east and west, I think 16:00 CET+1 is doable 
> (late in Japan, early in US). Next time we'll shift the time to be less 
> convenient for Europeans.
> 
> Speak up now if the date does not fit and you think your presense is 
> required.
> 
> Agenda is rather simple. If we are still working on the charter, then 
> we'll work on that. If the charter has been shipped already, we 
> concentrate srtucturing the work as discussed in Toronto.
> 
> - Jouni & Dapeng
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm


[DMM] interims i.e. teleconferences..

2014-07-30 Thread Jouni Korhonen

Folks,

14th or 15th Aug are the next possible dates for an interim telco (1-2h 
duration). To accommodate east and west, I think 16:00 CET+1 is doable 
(late in Japan, early in US). Next time we'll shift the time to be less 
convenient for Europeans.


Speak up now if the date does not fit and you think your presense is 
required.


Agenda is rather simple. If we are still working on the charter, then 
we'll work on that. If the charter has been shipped already, we 
concentrate srtucturing the work as discussed in Toronto.


- Jouni & Dapeng

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm


Re: [DMM] regarding the re-chartering..

2014-07-30 Thread Jouni Korhonen

Folks,

A major rewrite of the charter is in github (and below). Thanks to 
Kostas providing excellent feedbask on the text. Comments are welcome.




Description of Working Group:

Mobility management solutions lie at the center of the wireless Internet
and enable mobile devices to partake in IP networks anytime and
anywhere. The IETF Distributed Mobility Management (DMM) working group
(WG) specifies solutions for IP networks so that traffic can be
expedited between mobile and correspondent nodes. DMM solutions aim for
transparency above the IP layer, including maintenance of active
transport level sessions when mobile hosts or mobile networks change
their point of attachment to the Internet.

Wireless network deployments have traditionally relied on hierarchical
schemes that often lead to centralized deployment models, where a small
number of mobility anchors manage both mobility and reachability for a
mobile node. The DMM WG will consider the latest developments in mobile
networking research and operational practice (i.e. flat network
architectures, the impact of virtualization, new deployment needs as
wireless access technologies evolve in the coming years) and will
describe how distributed mobility management addresses the new needs in
this area better than previously standardized solutions.

A topic of particular focus will be mobility anchoring in this new
context, and the DMM working group is chartered to work on
maintenance-oriented extensions of the Mobile IPv6 protocol family (RFC
5213, RFC 5844, RFC , RFC 5568, and RFC 6275) as well as new
approaches which capitalize on other protocols specified by the IETF.
When extending protocols that are not based on Mobile IP, DMM solutions
will be have to be reviewed by the corresponding WGs.

IPv6 is assumed to be present in both the mobile host/router and the
access networks. DMM solutions are primarily targeted at IPv6
deployments and are not required to support IPv4, in particular for the
case where private IPv4 addresses and/or NATs are used. DMM solutions
must maintain backward compatibility: If the network or the mobile
host/router does not support the distributed mobility management
protocol that should not prevent the mobile host/router gaining basic
access (i.e., nomadic) to the network.

Contrary to earlier IP mobility protocols, mobility management signaling
paths and end-user traffic forwarding paths may differ. Further,
mobility-related functions may be located in separate network nodes. DMM
solutions should not distinguish between physical or virtualized
networking functions. Whenever applicable, clarifications and additional
features/capabilities for specific networking function deployment
models, e.g. in virtualized environments, are in-scope and encouraged.
Solutions may also specify the selection between the care-of addresses
and home address(es)/prefix(es) for different application use cases.

Work items related to distributed mobility management include:

  o Distributed mobility management deployment models and scenarios:
describe the target high-level network architectures and
deployment models where distributed mobility management
protocol solutions could apply.

  o Enhanced mobility anchoring: define protocol solutions for a
gateway and mobility anchor assignment and mid-session mobility
anchor switching that go beyond what has been specified, for
example, in RFC 6097, 6463, and 5142. Traffic steering
associated with the anchor switch is also in-scope if deemed
appropriate.

  o Forwarding path and signaling management: the function
that handles mobility management signaling interacts with the
DMM network elements for managing the forwarding state
associated with a mobile node's IP traffic. These two functions
may or may not be collocated. Furthermore, the forwarding state
may also be distributed into multiple network elements instead
of a single network element (e.g., anchor). Protocol extensions
or new protocols will be specified to allow the above mentioned
forwarding path and signalling management.

  o Exposing mobility state to mobile nodes and network nodes:
define solutions that allow, for example, mobile nodes to select
either a care-of address or a home address depending on an
application' mobility needs. In order to enable this
functionality, the network-side control functions and other
networking nodes must also be able to exchange appropriate
control information, as well as to the mobile nodes and their
applications.

The working group may decide to extend the current milestones based on
the new information and knowledge gained during working on other
documents listed in the initial milestones. Possible new documents and
milestones must still fit in