Templin, Fred L | 23 Jul 08:21 2015
Picon

Comment on draft-moses-dmm-dhcp-ondemand-mobility

Hi,

Section 3.1 of this document says:

   "If a client receives an IA Address option from a server with the IPv6
   Continuity Service option in the IAaddr-options field, without
   initially requesting a specific service using this option, it must
   discard the received IPv6 address."

But, this might leave the server with stale state. Perhaps it should say:

  "...it should send a Decline message to the server and must discard
   the received IPv6 address."

Same comment applies to the similar block of text that appears in
Section 3.2.

Thanks - Fred
fred.l.templin@...
Meetecho Team | 22 Jul 17:00 2015

Meetecho recordings of DMM WG session

Dear all,

the full recording (synchronized video, audio, slides and jabber room) of the 
DMM WG session at IETF 93 is available at the following URL:
http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#DMM

In case of problems with the playout, just drop an e-mail to ietf-support@...

For the chair(s): please feel free to put the link to the recording in the minutes,
if you think this might be useful.

Cheers,
the Meetecho Team

_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
Dave Dolson | 21 Jul 01:51 2015

mobility and link state

Danny,

Although I’m new to this working group, today I watched you present at IETF on the subject of applications monitoring link state.

You asked for feedback on the mailing list… Maybe some of these ideas are useful:

 

Thinking as an application author,

-          I think some kind of signal about network loss is useful, rather than applications using arbitrary timeouts on transaction times. Example: when should a browser or database client give up on a request? The timeout approach is unsatisfactory for transactions that take a long time to run.

-          Having said that, the application should not have to know about links or layer2 health.

-          Links should be able to go up and down, without dropping a TCP connection, for example. I feel there is a strong tradition of this behavior. IP addresses should be able to move between interfaces (e.g., from a physical interface to a tunnel interface) without interruption of the socket.

-          but one thing that warrants an exception is when the address bound by the socket is no longer available on the host. I believe current behavior a socket will stay alive even when the IP address is no longer available on the host, presumably in the hope that the IP address will be assigned again.

 

-           The socket should only fail if the transaction is not going to finish. In mobility context this might mean that the loss of the IP address is likely permanent (what is “permanent”? --> need heuristics).

-          Typical applications will connect with “any” for the source address to bind to. When a host has multiple IP addresses (multi-homed), there is a complicated set of rules for choosing one (RFC 6724). Your thoughts on choosing best routes may fit in this framework. (Is RFC 5014 relevant here?)

 

So my proposal, which I think can be backwards compatible:

-          Add an ioctl or getsockopt so that the application can ask, “would there be a better choice of local address”, giving the application an opportunity to start another socket at the best opportunity (after the current transaction).

-          Add a socket option for the idea of “create socket error if local IP has been lost for X seconds”. I propose the timeout, allowing an IP address to be removed from one interface and added to another without socket error. This is better than an application timeout.

 

Consider the case of a database client using a persistent database connection for queries.

To handle the soft hand-over case a smart client would keep checking if the socket is optimal. If not, finish the current transaction on the existing socket and open a new socket for new transactions. The new socket presumably uses the newer and better local IP address.

 

-Dave

 

 

_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
Jouni Korhonen | 15 Jul 23:53 2015
Picon

Note takers, jabber scribe, etc

Folks,

For a fluent flow during the DMM WG meeting, it would be great to have 
someone to volunteer as a note taker, a jabber scribe etc. Let the 
chairs know if you are volunteering (I'll get you a cookie and coffee as 
a reward for your trouble ;) Otherwise I will have to "volunteer" 
someone at the begining of the meeting..

- Jouni & Dapeng
Dapeng Liu | 15 Jul 04:06 2015
Picon

DMM agenda update

Hello all,

We update the DMM agenda:


Please send slides to chairs as soon as possible if you have presentation on the agenda.

Thanks,
-- 
Dapeng & Jouni
_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
Z.W. Yan | 15 Jul 03:33 2015
Picon

New Version Notification for draft-yan-dmm-hnprenum-02.txt

Hi, all,
Based on the comments we collected on-line and off-line, we updated the draft of "HNP renumbering in PMIPv6".
 
Any comments from you are all welcome.
Thanks.
Zhiwei Yan
 
 
_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
Sri Gundavelli (sgundave | 10 Jul 03:30 2015
Picon

Re: RFC4283bis progress..

 I can review and provide comments. I think its ready for publication, may be after a minor edit.



From: dmm <dmm-bounces-EgrivxUAwEY@public.gmane.org> on behalf of jouni korhonen <jouni.nospam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Thursday, July 9, 2015 at 1:49 PM
To: "dmm-EgrivxUAwEY@public.gmane.org" <dmm <at> ietf.org>, Charlie Perkins <Charlie.Perkins-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Subject: [DMM] RFC4283bis progress..

Charlie, WG,

In last IETF and slightly after that there was discussion about missing MN-IDs in the current -00 version. Have these been or rather will these be addressed? I'd like to move this trivial document forward.

- Jouni & Dapeng
_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
jouni korhonen | 9 Jul 22:49 2015
Picon

RFC4283bis progress..

Charlie, WG,

In last IETF and slightly after that there was discussion about missing MN-IDs in the current -00 version. Have these been or rather will these be addressed? I'd like to move this trivial document forward.

- Jouni & Dapeng
_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
Jouni Korhonen | 8 Jul 21:14 2015
Picon

More on the agenda..

Folks,

We have had a flood of requests for presentation slots. Dapeng and I are 
still working on the agenda to see if we can grant everyone even a bit 
of time - and that amount of time still being meaningful. We are as 
usual going to give existing WG items longer slots than new work proposals.

As a rule of thumb - if your work has already been *discussed* on the 
mailing list -> better chances.

Jouni & Dapeng
John Kaippallimalil | 6 Jul 22:02 2015

Re: New Version Notification for draft-mccann-dmm-prefixcost-01.txt

Hi Folks,
We have a new version of draft-mccann-dmm-prefixcost available - changes include a reference to
draft-korhonen-dmm-prefix-properties (and not 6man)
http://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcost/ 

Would like to get some feedback /comments on the proposal.

- John

Abstract:
   In a network implementing Distributed Mobility Management, it has
   been agreed that Mobile Nodes (MNs) should exhibit agility in their
   use of IP addresses.  For example, an MN might use an old address for
   ongoing socket connections but use a new, locally assigned address
   for new socket connections.  Determining when to assign a new
   address, and when to release old addresses, is currently an open
   problem.  Making an optimal decision about address assignment and
   release must involve a tradeoff in the amount of signaling used to
   allocate the new addresses, the amount of utility that applications
   are deriving from the use of a previously assigned address, and the
   cost of maintaining an address that was assigned at a previous point
   of attachment.  As the MN moves farther and farther from the initial
   point where an address was assigned, more and more resources are used
   to redirect packets destined for that IP address to its current
   location.  The MN currently does not know the amount of resources
   used as this depends on mobility path and internal routing topology
   of the network(s) which are known only to the network operator.  This
   document provides a mechanism to communicate to the MN the cost of
   maintaining a given prefix at the MN's current point of attachment so
   that the MN can make better decisions about when to release old
   addresses and assign new ones.
jouni korhonen | 6 Jul 21:25 2015
Picon

New version of draft-korhonen-dmm-prefix-properties

Folks,

Now that the real protocol work has started we had resurrected one of the older drafts on prefix coloring and network-mobile node communication solutions.

https://tools.ietf.org/html/draft-korhonen-dmm-prefix-properties-04

- Jouni

Abstract This specification defines an extension to the IPv6 stateless address autoconfiguration procedure. New options with meta data are defined that describe the properties and other prefix class meta data associated with the prefix. The stateless address autoconfiguration procedure and end hosts can make use of the additional properties and class information when selecting source address prefixes for a particular uses and use cases. This specification updates RFC4862.
_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm

Gmane