Re: [DMM] Document Action: 'On Demand Mobility Management' to Informational RFC (draft-ietf-dmm-ondemand-mobility-18.txt)

[Moses, Danny]

Hi,
And also the chairs of DMM and Suresh for extensive support and useful guidance.

Thanks and regards,
Danny

-Original Message-
From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] 
Sent: Wednesday, August 07, 2019 17:29
To: draft-ietf-dmm-ondemand-mobil...@ietf.org
Cc: dmm@ietf.org
Subject: Re: Document Action: 'On Demand Mobility Management' to Informational 
RFC (draft-ietf-dmm-ondemand-mobility-18.txt)

Congrats Danny, Seil and all. Thanks for all your efforts.



Sri

On 8/6/19, 1:55 PM, "The IESG"  wrote:

>The IESG has approved the following document:
>- 'On Demand Mobility Management'
>  (draft-ietf-dmm-ondemand-mobility-18.txt) as Informational RFC
>
>This document is the product of the Distributed Mobility Management 
>Working Group.
>
>The IESG contact persons are Éric Vyncke and Suresh Krishnan.
>
>A URL of this Internet Draft is:
>https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/
>
>
>
>
>Technical Summary
>
>   This document describes a mechanism for taking the application needs 
>into account in selectively
>   providing IP session continuity and IP address reachability on a 
>per-socket basis.
>
>Working Group Summary
>
>  There were some debates in the working group regarding the
>  defined types of IP Addresses defined in this document, but those are 
>now resolved.
>
>Document Quality
>
>  This document has been discussed for a long time in the WG and has 
>received multiple reviews from within the WG as well as outside.
>
>Personnel
>
>   Who is the Document Shepherd for this document?  Sri Gundavelli
>   Responsible Area Director?  Suresh Krishnan

-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Mirja Kühlewind's No Objection on draft-ietf-dmm-ondemand-mobility-18: (with COMMENT)

[Moses, Danny]

Hi Again,
Regarding your clarification about mobility being better served by the 
transport layer versus the application layer.

This work is not about trying to find a better or more efficient way to handle 
mobility while preserving the transport connection. It is about enabling 
applications to indicate whether or not they need this service, which is 
provided automatically and transparently in some mobile network implementations 
(like cellular networks).

Take, for example, the a video browser app. Since it is buffering parts of the 
video, it can close an existing socket and open a new one with different 
attributes, without any user-experience degradation. This could be useful when, 
as a result of a host moving to a different place that has a different (closer) 
instance of the video server. A switch to the new video server instance 
requires that the video browser is aware of the mobility event and is able to 
locate a different server. If the IP connection is preserved (by tunneling or 
any other way), the video browser will stay connected to the original server 
and the quality-of-experience might be affected. This is an example for a 
Graceful-replacement service that is more appropriate than the Session-lasting 
service. 

Another question you had was to whether the word 'application' is always 
correct. I cannot commit to 'always', but this work was designed to enable 
applications to convey their service needs. A transport layer cannot know the 
abilities of the different applications to cope with source IP address changes, 
only applications know that. In addition, several applications can execute 
concurrently, each with different needs. So the flexibility of selecting the 
service type should be per-application, or even, per-socket, as application may 
use more than one socket. 

We tried to convey both these points in the document. If you think this is not 
clear, please help us improve the wording.

Thanks and regards,
Danny 



-Original Message-
From: Mirja Kühlewind via Datatracker [mailto:nore...@ietf.org] 
Sent: Thursday, August 01, 2019 16:03
To: The IESG 
Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; Dapeng Liu 
; Sri Gundavelli ; 
dmm-cha...@ietf.org; sgund...@cisco.com; dmm@ietf.org
Subject: Mirja Kühlewind's No Objection on draft-ietf-dmm-ondemand-mobility-18: 
(with COMMENT)

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dmm-ondemand-mobility-18: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/



--
COMMENT:
--

Thanks for addressing my discuss. Sorry for the long delay on my side!

Here is my old  comment still:

Please also note that address mobility is actually more a transport question 
that an application layer question. For TCP session-lasting addresses will 
always be more efficient if available while an application using TCP will 
always need to cover the case where an TCP connection fails or is interrupted 
and therefore the application needs to reconnect. However, in contrast QUIC 
supports IP address mobility and will survive changing IP addresses. I think 
that should be also clarified in the draft and it should be double-check if the 
use of the word application is always correct or if it should be replaced 
sometimes with e.g. transport system or a more general term.


-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Mirja Kühlewind's Discuss on draft-ietf-dmm-ondemand-mobility-16: (with DISCUSS and COMMENT)

[Moses, Danny]

Hi Mirja (and all other reviewers),
Thanks for your comments.

I read once more your comments about the removal of the Socket API definitions 
(from February 2019), and after more thought agree to remove it from the 
normative part of the document.
I believe that the important aspect of this work is to define the ability of 
applications to indicate the type of service they require in terms of session 
continuity and IP address reachability. The part that enhances the Socket APIs 
is our idea of implementation and not necessarily the only one. Once the 
concepts are defined, Socket API enhancements may better be defined in other 
forums.

So I am removing sections 3.5, 4 and 6 from the document (as you suggested in 
the email from February). 

I think it could be helpful to add an appendix that provide an example of an 
implementation in high-level. I reworded the text that was removed (section 
3.5) to become a description of an example (rather than a definition of a 
solution) and placed it as an appendix.

I believe this was the last open issue and that now the draft can be published.
Please consider the new version that I have posted: 
https://tools.ietf.org/pdf/draft-ietf-dmm-ondemand-mobility-18.pdf

Best regards, 

Danny

-Original Message-
From: Mirja Kuehlewind [mailto:i...@kuehlewind.net] 
Sent: Monday, July 29, 2019 19:57
To: Moses, Danny 
Cc: The IESG ; draft-ietf-dmm-ondemand-mobil...@ietf.org; 
sgund...@cisco.com; dmm-cha...@ietf.org; dmm@ietf.org; Dapeng Liu 

Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-dmm-ondemand-mobility-16: 
(with DISCUSS and COMMENT)

Hi Danny,

Sorry for my super late reply! Somehow your mail got sorted in the wrong folder 
and I therefore overlooked it.

Did you have a chance to talk more about this with other reviewers or other 
people in the working group?

I still think that it is not appropriate nor very useful to have the Socket API 
specified in the body of the draft (as the Linux community will not necessarily 
follow this). Therefore I still recommend to remove it or more it to the 
appendix and clearly indicated that this is an example implementation for 
illustrative purposes only. 

Further I think it would still be good to discuss pros and cons or different 
approaches to realise this interface rather than trying to impose one specific 
implementation (which may potentially not be adopted in practice).

Please see further inline below.

Thanks!
Mirja


> On 22. Feb 2019, at 11:49, Moses, Danny  wrote:
> 
> Hi Mirja,
> Thanks for your comments.
> 
> I would like to start with responding to your last proposal to remove all 
> socket API specifications from the document.
> 
> Yes, we could do that. However, this is a significant modification and I 
> would like some sort of ruff consensus from the rest of the reviewers for 
> such a significant change.
> 
> I must admit that this idea was brought up to me after the WGLC and I was not 
> sure whether this could be done without a broader discussion. During the work 
> on this document (which has been discussed in many dmm session over several 
> years), people felt that the Socket API info was important. Furthermore, 
> there were several discussions about whether to use additional flags in 
> setsockopt() or add a new function (which was added eventually). There were 
> also discussions about whether or not to add a pseudo code example to the 
> document and after it was added, a discussion about the example. 
> 
> My personal view is that the concept of introducing mobility service types 
> and enabling applications to request them on a per-socket basis, is the most 
> important aspect of this work. The socket extensions part is there to provide 
> guidance from IETF as to how this extension should be designed. The multiple 
> discussion we had about the socket extensions prove to me that some people 
> think they are valuable as well.
> 
> If the reviewers think that leaving the socket extensions specification in 
> the document is a show stopper, I will remove the text as you propose, but I 
> would like the opinions of more reviewers on that. 
> 
> 
> Response to the comment about the API approach:
> The comment indicates that according to section 3.2 Fixed IP address cannot 
> be configured on a per socket basis since the application needs the same IP 
> address for multiple socket connections. This, according to the comment, 
> contradicts the text in section 3.3 indicating that IP address type selection 
> is made on a per-socket granularity.
> 
> I would like to clarify this point.
> 
> IP address type selection should indeed be done on a per-socket basis. If an 
> application requires a socket with a Fixed address type, it will require the 
> same address whenever it re-opens this specific socket. But this does not 
> mean that the applic

Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt

[Moses, Danny]

Yes, now I see your point. Setsockopt() will trigger the exchange of packets 
between the mobile host and the network to allocate the desired prefix (if not 
already allocated), and connect() will be blocked until the prefix is allocated 
and the TCP handshaking is completed.

Some pros and cons that come to mind are:
Pros:
Setsockopt() is still non-blocking.
Non need to pass the address as a parameter. 
No need for defining a new function.

Conns:
It is not clear how the connect() should act if the desired address type is not 
allocated by the network. Should it still connect with the address available to 
the host or should it fail?
If it continues to connect, the application is not aware of the type of 
mobility service it will receive from the network.
If it should not connect, we are changing the definition of the behavior of 
connect(). Furthermore, applications that do not care about mobility service, 
will use connect() without setsockopt(). So now, connect() need to know whether 
or not setsockopt() was invoked for setting the desired mobility service type - 
also a new functionality of connect().
It will not work for UDP (were connect() is not invoked). However, this is not 
a strong conn, since we can define that as a default address type for UDP 
sockets should be 'non-persistent'. 

When the concern regarding the 'blocking' nature of setsockopt() was discussed 
in DMM, we provided several alternatives for resolution, and after some 
discussion, the one defined in the document was chosen.

Your alternative is also viable, but it is not clear to me that it is 
significantly better and is worth reopening the discussion once again in DMM. 
But, our correspondence is on the list and everyone is welcome to post an 
opinion.

Regards,
Danny



-Original Message-
From: Tom Herbert [mailto:t...@quantonium.net] 
Sent: Tuesday, March 05, 2019 18:26
To: Moses, Danny 
Cc: dmm 
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt

On Tue, Mar 5, 2019 at 2:29 AM Moses, Danny  wrote:
>
> Can you please provide a calling sequence of your proposal?
>

Something like:

s = socket(AF_INET6, SOCK_STREAM, 0) ;
setsockopt(s, IPPROTO_IP, PREFERRED_ADDRESS_TYPE,
IPV6_REQUIRE_SESSION_LASTING_IP)
if (connect(s, , sizeof(serverInfo)) < 0) {
   if (errno == EADDRNOTAVAIL) {
// Didn't get address for requested type
  }
  ...
}

// To get address local address that was selected...
getsockname(s, , );


> Thanks,
> Danny
>
> -Original Message-
> From: Tom Herbert [mailto:t...@quantonium.net]
> Sent: Monday, March 04, 2019 17:17
> To: Moses, Danny 
> Cc: dmm 
> Subject: Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt
>
> On Mon, Mar 4, 2019 at 4:25 AM Moses, Danny  wrote:
> >
> > Hi Tom,
> >
> > Fair question.
> >
> > I believe I mentioned that in one of my responses. The original definition 
> > was to use setsockopt() with new flags. However, some people raised the 
> > concern that this new feature changes the behavior of the function in a way 
> > that may confuse programmers and requested to use a new function (setsc()).
> >
> > The issue was due to the time it takes the function to process the request. 
> > In current Socket implementation, setsockopt() is a function that returns 
> > immediately to the caller. On the other hand, this new feature may trigger 
> > an exchange of packets between the IP stack in the mobile node and the 
> > network allocating the IP prefix. This exchange takes time and the function 
> > can return only after the exchange is completed. They insisted that we 
> > maintain the current 'immediate' return behavior of setsockopt() and 
> > introduce a new function that might 'block' the calling thread until it 
> > completes.
> >
> Hi Danny,
>
> It is unclear to me why address selection has to be done outside of binding 
> the socket. It seems like the required functionality of the draft could be 
> achieved by calling setsockopt to express desired address type and then 
> calling connect on the socket. Connect will bind an address with the 
> requested type and can obviously block if work needs to be done to find an 
> appropriate address. This simplifies the API and addresses an ambiguity in 
> the draft-- when setsc returns it is unclear if the address was somehow 
> reserved for the socket use (e.g.
> this becomes pertinent if we were to add an interface to bind a unique 
> address to a socket).
>
> Tom
>
> > Regards,
> > Danny
> >
> >
> >
> >
> > -Original Message-
> > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
> > Sent: Friday, February 22, 2019 22:08
> > To: dmm 
> > Subject: Re: [DMM] I-D Action: 
> &

Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt

[Moses, Danny]

Can you please provide a calling sequence of your proposal?

Thanks,
Danny

-Original Message-
From: Tom Herbert [mailto:t...@quantonium.net] 
Sent: Monday, March 04, 2019 17:17
To: Moses, Danny 
Cc: dmm 
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt

On Mon, Mar 4, 2019 at 4:25 AM Moses, Danny  wrote:
>
> Hi Tom,
>
> Fair question.
>
> I believe I mentioned that in one of my responses. The original definition 
> was to use setsockopt() with new flags. However, some people raised the 
> concern that this new feature changes the behavior of the function in a way 
> that may confuse programmers and requested to use a new function (setsc()).
>
> The issue was due to the time it takes the function to process the request. 
> In current Socket implementation, setsockopt() is a function that returns 
> immediately to the caller. On the other hand, this new feature may trigger an 
> exchange of packets between the IP stack in the mobile node and the network 
> allocating the IP prefix. This exchange takes time and the function can 
> return only after the exchange is completed. They insisted that we maintain 
> the current 'immediate' return behavior of setsockopt() and introduce a new 
> function that might 'block' the calling thread until it completes.
>
Hi Danny,

It is unclear to me why address selection has to be done outside of binding the 
socket. It seems like the required functionality of the draft could be achieved 
by calling setsockopt to express desired address type and then calling connect 
on the socket. Connect will bind an address with the requested type and can 
obviously block if work needs to be done to find an appropriate address. This 
simplifies the API and addresses an ambiguity in the draft-- when setsc returns 
it is unclear if the address was somehow reserved for the socket use (e.g.
this becomes pertinent if we were to add an interface to bind a unique address 
to a socket).

Tom

> Regards,
> Danny
>
>
>
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
> Sent: Friday, February 22, 2019 22:08
> To: dmm 
> Subject: Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt
>
> Out of curiosity, why is the new API being portrayed as a system call
> (setsc) instead of a socket option (the bar for adding a socket option is 
> much lower ).
>
> Tom
>
> On Fri, Feb 22, 2019 at 6:19 AM  wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> > This draft is a work item of the Distributed Mobility Management WG of the 
> > IETF.
> >
> > Title   : On Demand Mobility Management
> > Authors : Alper Yegin
> >   Danny Moses
> >   Seil Jeon
> > Filename: draft-ietf-dmm-ondemand-mobility-17.txt
> > Pages   : 18
> > Date: 2019-02-22
> >
> > Abstract:
> >Applications differ with respect to whether they need session
> >continuity and/or IP address reachability.  The network providing the
> >same type of service to any mobile host and any application running
> >on the host yields inefficiencies, as described in [RFC7333].  This
> >document defines a new concep of enabling applications to influence
> >the network's mobility services (session continuity and/or IP address
> >reachability) on a per-Socket basis, and suggests extensions to the
> >networking stack's API to accomodate this concept.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-17
> > https://datatracker.ietf.org/doc/html/draft-ietf-dmm-ondemand-mobili
> > ty
> > -17
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-ondemand-mobility-1
> > 7
> >
> >
> > Please note that it may take a couple of minutes from the time of 
> > submission until the htmlized version and diff are available at 
> > tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > ___
> > dmm mailing list
> > dmm@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmm
>
> ___
> dmm mailing list
> dmm@ietf.org
> https:/

Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt

[Moses, Danny]

Hi Tom,

Fair question.

I believe I mentioned that in one of my responses. The original definition was 
to use setsockopt() with new flags. However, some people raised the concern 
that this new feature changes the behavior of the function in a way that may 
confuse programmers and requested to use a new function (setsc()).

The issue was due to the time it takes the function to process the request. In 
current Socket implementation, setsockopt() is a function that returns 
immediately to the caller. On the other hand, this new feature may trigger an 
exchange of packets between the IP stack in the mobile node and the network 
allocating the IP prefix. This exchange takes time and the function can return 
only after the exchange is completed. They insisted that we maintain the 
current 'immediate' return behavior of setsockopt() and introduce a new 
function that might 'block' the calling thread until it completes.

Regards,
Danny




-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
Sent: Friday, February 22, 2019 22:08
To: dmm 
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt

Out of curiosity, why is the new API being portrayed as a system call
(setsc) instead of a socket option (the bar for adding a socket option is much 
lower ).

Tom

On Fri, Feb 22, 2019 at 6:19 AM  wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Distributed Mobility Management WG of the 
> IETF.
>
> Title   : On Demand Mobility Management
> Authors : Alper Yegin
>   Danny Moses
>   Seil Jeon
> Filename: draft-ietf-dmm-ondemand-mobility-17.txt
> Pages   : 18
> Date: 2019-02-22
>
> Abstract:
>Applications differ with respect to whether they need session
>continuity and/or IP address reachability.  The network providing the
>same type of service to any mobile host and any application running
>on the host yields inefficiencies, as described in [RFC7333].  This
>document defines a new concep of enabling applications to influence
>the network's mobility services (session continuity and/or IP address
>reachability) on a per-Socket basis, and suggests extensions to the
>networking stack's API to accomodate this concept.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-17
> https://datatracker.ietf.org/doc/html/draft-ietf-dmm-ondemand-mobility
> -17
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-ondemand-mobility-17
>
>
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 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
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Alissa Cooper's Discuss on draft-ietf-dmm-ondemand-mobility-16: (with DISCUSS and COMMENT)

[Moses, Danny]

Hi Alissa,

I have tried to figure out what is the cause for the confusion.

I think that the term ‘address type’ used in this document might be the cause, 
as you are trying to compare it with definitions of types of addresses in other 
RFCs.

Perhaps the term ‘address type’ is not the best term to define the type of 
mobile services this document is defining, but we could not find a better name 
for the term.

In this draft, we are not attempting to define new types of addresses in 
addition to the ones that were specified as part of IPv6 (Unicast, Multicast, 
Anycast, the different scopes etc.) and is not related to the address types 
defined in RFC 7721 (Public, Stable, Temporary etc.).

Yes, one might correlate between a ‘Fixed’ address and a ‘Stable’ address 
(‘Fixed’ sounds like ‘Stable’) or between a ‘Non-persistent’ IP address and a 
‘Temporary’ address (‘Non-persistent’ sound like something not stable…), but 
that is not the case.

RFC 7721 definitions relate to address within a specific IPv6 link. This 
document discusses the ability of a network to route packets to mobile nodes 
that move between different IPv6 links. This is totally different.

Quoting from RFC 7721:

   Stable address:
  An address that does not vary over time within the same IPv6 link.
  Note that [RFC4941<https://tools.ietf.org/html/rfc4941>] refers to these 
as "public" addresses, but
  "stable" is used here for reasons explained in Section 
4<https://tools.ietf.org/html/rfc7721#section-4>.

   Temporary address:
  An address that varies over time within the same IPv6 link.

Note the ‘within the same IPv6 link’ in the definition!

This document discusses the ability to reach a mobile node after it moved from 
one IPv6 link to a different one due to a mobility event. When the network 
allocates a ‘session-lasting IP address’ it guarantees to be able to route 
packets to that destination address even after the mobile node moves to a 
different IPv6 link (this is the essence of PMIP). When the network allocates a 
‘non-persistent IP address’, packets destined to that address will not reach 
the mobile node after it had moved to a new IPv6 link.

The ‘stableness’ or ‘temporary-ness’ of the addresses, are really the 
‘stableness’ or ‘temporary-ness’ of the network’s ability to route the packets 
after a mobility event, hence ‘session continuity’ or ‘address reachability’.

I might have used bad terminology, but this is what I meant by ‘orthogonal’. A 
‘Stable’ IP address can be used as either ‘Fixed’, ‘Session-lasting’, 
‘Non-persistent’ or even ‘Graceful replacement’ IP address as defined in this 
document. The fact that an address is ‘Stable’ in a specific IPv6 link, does 
not necessarily mean that it will be useful after a mobility event. This 
depends on the service provided by the mobile network.

In the Socket API, we used the term addressType for the argument that describes 
the mobility service that is provided by the network in association with the 
source IP address. We believe that from the programmer’s point of view this 
session continuity (and /or address reachability) service associated with the 
address could be perceived as an ‘address type’.

I hope this answer is clearer than the previous one and I hope I hit the issue 
that caused the confusion.

Regards,
Danny









-Original Message-
From: Alissa Cooper [mailto:ali...@cooperw.in]
Sent: Friday, February 22, 2019 19:10
To: Moses, Danny 
Cc: The IESG ; draft-ietf-dmm-ondemand-mobil...@ietf.org; 
dmm-cha...@ietf.org; dmm@ietf.org; Dapeng Liu 
Subject: Re: [DMM] Alissa Cooper's Discuss on 
draft-ietf-dmm-ondemand-mobility-16: (with DISCUSS and COMMENT)



Hi Danny,



> On Feb 22, 2019, at 9:06 AM, Moses, Danny 
> mailto:danny.mo...@intel.com>> wrote:

>

> Hi Alissa,

> Thanks for your comments.

>

> Following are me responses:

> DISCUSS (1): Normative requirements on "the IP stack" are too broad:

> I have checked all places that have normative requirements regarding "IP 
> stack" in the document. Please see my response per instance:

> Section 3.4 - On Demand Nature has several normative requirements on the "IP 
> stack". One example:

> "When an application requires a specific type of IP address and such an 
> address is not already configured on the host, the IP stack SHALL attempt to 
> configure one."

>

> This section describes the new On Demand feature and is part of section 3 
> which describes the Solution for On Demand mobility. As such, I believe it is 
> clear from the context that the normative requirements in this section are 
> for stacks that implement the On Demand features and believe there is no need 
> to be more specific in this place.



I disagree. At a minimum I think 3.4 needs to specify that its normative 
requirements apply only to implementations that suppo

[DMM] New version of draft-ietf-dmm-ondemand-mobility

[Moses, Danny]

Hi all,
I have upload a new version (17) of the draft.


Here is a summary of the changes to the draft after analyzing the different 
Last Call review and comments:

Changes from Rev-16 to Rev-17

1.  Remove the reference to section 4 of RFC7333 in the Abstract. Leave the 
reference to RFC7333.

2.  Reorder 2 paragraphs in the Introduction (section 1):

The original order was:

*The paragraph starting with: "Mobile IP is designed to provide..."

*The paragraph starting with: "In reality not every application..."

*The paragraph starting with: "Achieving session continuity and IP 
address reachability..."

The new order is:

*The paragraph starting with: "Mobile IP is designed to provide..."

*The paragraph starting with: "Achieving session continuity and IP 
address reachability..."

*The paragraph starting with: "In reality not every application..."

3.  Remove '(' and ')' from last paragraph of section 3.1

4.  Improve the normative requirements on "the IP stack" or "IP stacks":

*Section 5.1, replace 'MUST' with 'should'.

*Section 5.2, modify "New IP stacks" to "New IP stacks (that implement 
On Demand functionality).

5.  Improve the Security Threats description

Improve the Security Consideration section as recommended by Daniel Migault.




Changes from Rev-15 to Rev-16

1.  In the Abstract, add a reference to RFC 7333 which details the 
inefficiencies in current mobility services implementation which lead to the 
new work in DMM and specifically this document: Add to '...The network 
providing the same type of service to any mobile host and any application 
running on the host yields inefficiencies.' the text - ' as described in 
section 4 of RFC 7333.'

2.  Accepted the text change in section 1: replaced 'It should be noted 
that in' to 'In'.

3.  Align the style of the lists in section 1 and section 3 (using the 
style that was used in section 3).

4.  Add 'on demand' in section one: replace 'This document proposes a 
solution for applications running on mobile hosts to indicate whether they need 
session continuity...' with -

'This document proposes a solution for applications running on mobile hosts to 
indicate when establishing the network connection ('on demand') whether they 
need session continuity...'

5.  Maintain the order of type of addresses in section 3.3 (now 3.4 after 
adding a section before 3.1). Change:

'At any point of time, a mobile host may have a combination of IP addresses 
configured. Zero or more Non-persistent, zero or more Session-lasting, zero or 
more Fixed and zero or more Graceful-Replacement IP addresses...', to:

'At any point of time, a mobile host may have a combination of IP addresses 
configured. Zero or more Fixed, zero or more Session-lasting, zero or more 
Non-persistent and zero or more Graceful-Replacement IP addresses...'.

6.  Updated section 2 to the most updated format and added a reference to 
RFC 8174

7.  Corrected the typo in section 4.1: replaced 'secsc(' with 'setsc('

8.  Corrected the 'getsc()' typo in several places: replaced 'getsc()' with 
'setsc()'

9.  Clarified the process of requesting and assigning the desired mobile 
service to applications by adding a new section - 3.1 High-level Description.

10.   Maintain consistency. Replace all occurrences on 'on demand' and 
OnDemand' to 'On-Demand'. And all 'IP v6' to 'IPv6'

11.   Simplify the use-case described in section 5.4. Change:

'However, if an application sets a specific option using setsockopt() with one 
of the flags specified in [RFC5014] and also selects a source IP address using 
setsc() and bind() the IP address that was generated by setsc() and bound using 
bind() will be the one used by traffic generated using that socket and options 
set by setsockopt() will be ignored'

To:

'However, if an application erroneously performs a combination of (1) use 
setsockopt() to set a specific option (using one of the flags specified in 
[RFC5014]) and (2) selects a source IP address type using setsc() and bind(), 
the IP stack will fulfill the request specified by (2) and ignore the flags set 
by (1).'

12.   The only comments I am still debating on are:

a.  The IANA-related comment.

b.  The security-related comment

I would appreciate you inputs.

Regards,
Danny

-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Alissa Cooper's Discuss on draft-ietf-dmm-ondemand-mobility-16: (with DISCUSS and COMMENT)

[Moses, Danny]

Hi Alissa,
Thanks for your comments.

Following are me responses:
DISCUSS (1): Normative requirements on "the IP stack" are too broad:
I have checked all places that have normative requirements regarding "IP stack" 
in the document. Please see my response per instance:
Section 3.4 - On Demand Nature has several normative requirements on the "IP 
stack". One example:
"When an application requires a specific type of IP address and such an address 
is not already configured on the host, the IP stack SHALL attempt to configure 
one."

This section describes the new On Demand feature and is part of section 3 which 
describes the Solution for On Demand mobility. As such, I believe it is clear 
from the context that the normative requirements in this section are for stacks 
that implement the On Demand features and believe there is no need to be more 
specific in this place.

Section 5.2 - IP Stack in the Mobile Host
There are several normative requirements on New IP stacks. This section is part 
of section 5 that discusses backwards compatibility and as such we assumed that 
"New IP stacks" refer to IP stacks that implement On Demand functionality. 
Still, I can see how this might be confusing and thus, I will modify the text 
from: "New IP stacks" to "new IP stack (that implement On Demand 
functionality)" to be more precise.



DISCUSS (2): Intersection between definitions of address types and 
recommendations in this document and RFC 7721, RFC 4941 and RFC 8064.
We had similar comments and discussions in dmm. The On Demand document does not 
define new address types. It formalizes types of services that are associated 
with the mobility nature of a mobile host in a mobile network environment: 
Reachability and session continuity. It further defines an association between 
these services and a source IP address (or IP prefix). The motivation of 
associating between the service and the IP address is to enable a common 
understanding between the network and the application on the mobile host, with 
regards to reachability and session continuity provided as a mobile service by 
the mobile network.

This is completely orthogonal with the definition of address types in the RFCs 
mention in the comment or the definition of the different IPv6 address types.



COMMENT (1): What is a "very long time" in section 3.2
A "very long time" is so long that the address is guaranteed to be fixed even 
after the mobile host disconnects from the network and reconnects later on (and 
even when this occurs several times). It is much longer than a guarantee to be 
valid throughout the life-time of an opened socket (which is longer than and 
address with no guarantee at all).

We thought this is clear from the description of the other types of IP 
addresses. If not, we could change the order of the definition of addresses and 
have the Fixed address definition after the Session-lasting address definition. 

Do you recommend that we re-order the definitions?




COMMENT (2): Remove normative MUST in section 5.1
Ack. Will be removed in the next revision.




COMMENT (3): Required discussion on privacy and security implications in 
section 7
I have discussed the content of section 7 with Daniel Migault and ended up with 
a completely rewritten section. I hope the new version will satisfy your 
concerns.



Thanks for the review and comments,
Danny



-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alissa Cooper
Sent: Thursday, February 21, 2019 16:01
To: The IESG 
Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm-cha...@ietf.org; 
dmm@ietf.org; Dapeng Liu 
Subject: [DMM] Alissa Cooper's Discuss on draft-ietf-dmm-ondemand-mobility-16: 
(with DISCUSS and COMMENT)

Alissa Cooper has entered the following ballot position for
draft-ietf-dmm-ondemand-mobility-16: Discuss

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/



--
DISCUSS:
--

(1) There are a bunch of places in this document that place normative 
requirements on "the IP stack" or "IP stacks." This seems too broad to me -- 
aren't these meant to apply to IP stacks that implement the new API? It seems 
like RFC 5014 was more careful in its use of normative language and I think 
that care is warranted here as well.

(2) RFC 7721 defines a bunch of address types that are somewhat overlapping 
with the definitions here. RFC 4941 and RFC 8064 provide recommendations for 
configuration of different address types. How do 

Re: [DMM] Mirja Kühlewind's Discuss on draft-ietf-dmm-ondemand-mobility-16: (with DISCUSS and COMMENT)

[Moses, Danny]

Hi Mirja,
Thanks for your comments.

I would like to start with responding to your last proposal to remove all 
socket API specifications from the document.

Yes, we could do that. However, this is a significant modification and I would 
like some sort of ruff consensus from the rest of the reviewers for such a 
significant change.

I must admit that this idea was brought up to me after the WGLC and I was not 
sure whether this could be done without a broader discussion. During the work 
on this document (which has been discussed in many dmm session over several 
years), people felt that the Socket API info was important. Furthermore, there 
were several discussions about whether to use additional flags in setsockopt() 
or add a new function (which was added eventually). There were also discussions 
about whether or not to add a pseudo code example to the document and after it 
was added, a discussion about the example. 

My personal view is that the concept of introducing mobility service types and 
enabling applications to request them on a per-socket basis, is the most 
important aspect of this work. The socket extensions part is there to provide 
guidance from IETF as to how this extension should be designed. The multiple 
discussion we had about the socket extensions prove to me that some people 
think they are valuable as well.

If the reviewers think that leaving the socket extensions specification in the 
document is a show stopper, I will remove the text as you propose, but I would 
like the opinions of more reviewers on that. 


Response to the comment about the API approach:
The comment indicates that according to section 3.2 Fixed IP address cannot be 
configured on a per socket basis since the application needs the same IP 
address for multiple socket connections. This, according to the comment, 
contradicts the text in section 3.3 indicating that IP address type selection 
is made on a per-socket granularity.

I would like to clarify this point.

IP address type selection should indeed be done on a per-socket basis. If an 
application requires a socket with a Fixed address type, it will require the 
same address whenever it re-opens this specific socket. But this does not mean 
that the application requires the same Fixed source IP address for other 
sockets it uses (if any). It can use whatever source IP address type it needs 
according to the address reachability and/or session continuity requirements 
for the other sockets. 

Furthermore, when a mobile host deploys several applications with one of them 
requiring a Fixed source IP address, others may require different address types 
and this is supported when the address type is selected on a per-socket basis.


Response to the comment about adding flags to setsockopt() versus the new 
function setsc():
The original design was to use new flags for setsockopt(). However, during 
discussions in the dmm group, some people were concern with the fact that the 
new functionality may cause a ‘blocking’ behavior to setsockopt(). The reason 
for this ‘blocking’ behavior, as described in section 3.5, is due to the fact 
that in some cases, requesting a specific address type may trigger an 
interaction between the mobile host and the network requesting a prefix for 
this address. This interaction which involves exchange of packets may take some 
time, and the function can return only after the exchange of packets is 
completed.

The concern was that this changes the behavior of setsockopt() from a function 
that returns immediately, to a function that may block the invoking thread for 
a while, may confuse socket users.

Several options were presented to resolve this concern and the alternative that 
was selected by dmm was to leave setsockopt() in its non-‘blocking’ nature, and 
introduce a new function – ‘setsc()’ that has no legacy usage and may block the 
thread if the invocation triggers an exchange of packets between the TCP/IP 
stack in the mobile host and the network (as described in section 6.1).

I hope I managed to clarify this point.


Response to the comment about mobility being a transport question rather than 
an application layer question:
I am not sure I agree with this comment .I think that it does not take in 
account the extra cost and non-optimized routes used when networks provide 
session-lasting source IP addresses. But nevertheless, having a discussion 
about this point only strengthens the notion that the flexibility of being able 
to select service types on a per-socket basis is valuable.

/Danny




-Original Message-
From: Mirja Kühlewind [mailto:i...@kuehlewind.net] 
Sent: Wednesday, February 20, 2019 15:48
To: The IESG 
Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; Dapeng Liu 
; Sri Gundavelli ; 
dmm-cha...@ietf.org; sgund...@cisco.com; dmm@ietf.org
Subject: Mirja Kühlewind's Discuss on draft-ietf-dmm-ondemand-mobility-16: 
(with DISCUSS and COMMENT)

Mirja Kühlewind has entered the following ballot position 

Re: [DMM] Genart telechat review of draft-ietf-dmm-ondemand-mobility-16

[Moses, Danny]

Hi Russ,
Ack on both comments. Will be modified in the next revision.

Thanks,
Danny

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Russ Housley
Sent: Sunday, February 17, 2019 23:55
To: gen-...@ietf.org
Cc: draft-ietf-dmm-ondemand-mobility@ietf.org; i...@ietf.org; dmm@ietf.org
Subject: [DMM] Genart telechat review of draft-ietf-dmm-ondemand-mobility-16

Reviewer: Russ Housley
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at 
.

Document: draft-ietf-dmm-ondemand-mobility-16
Reviewer: Russ Housley
Review Date: 2019-02-17
IETF LC End Date: 2019-02-15
IESG Telechat date: 2019-02-21

Summary: Ready


Major Concerns:

None.


Minor Concerns:

None.


Nits:

In the Abstract: s/section 4 of [RFC7333]/RFC 7333/ (because references are not 
permitted in the Abstract).

In Section 3.1, last paragraph: drop the '(' and ')'.


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Rtgdir telechat review of draft-ietf-dmm-ondemand-mobility-15

[Moses, Danny]

Hi Jonathan,

Thanks for the review and comments.
Please see my response and actions below.


1.  Change ‘solution’ to ‘API’ in the Abstract.

I agree that ‘solution’ is misleading. The draft actually introduces the new 
concept of influencing the level of the network’s mobility service, and 
provides a suggestion for API implementation. So, I am changing the wording to:

‘…This document defines a new concept of enabling applications to influence the 
network’s mobility service (session continuity and/or IP address reachability) 
on a per-Socket basis, and suggests extensions to the networking stack’s API to 
accommodate this concept.’

2.  On a related point, is there any work you can refer to that provides a 
mechanism for implementing this API?

There are currently two other drafts; (1) defining extensions to DHCPv6 for 
requesting a specific service (and for the network to provide responses), and 
(2) defining extensions to Router Advertisement message through which the 
network can indicate the type of mobility service associated with a provisioned 
IP prefix.

3.  The boilerplate in section 2 is out of date.  Please see RFC 8174 for 
the latest boilerplate.

Yes, we have received this comment and the new revision will fix section 2.

4.  On page 6, I spotted a stray ")" in this sentence.

Thank you. Will be removed in the next release.



Thanks,

Danny









-Original Message-
From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: Friday, January 25, 2019 01:03
To: rtg-...@ietf.org
Cc: draft-ietf-dmm-ondemand-mobility@ietf.org; dmm@ietf.org; 
rtg-...@ietf.org; rtg-...@ietf.org
Subject: Rtgdir telechat review of draft-ietf-dmm-ondemand-mobility-15



Reviewer: Jonathan Hardwick

Review result: Has Nits



Hi there



I have done a routing directorate review of this draft.

https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/



The Routing Directorate seeks to review all routing or routing-related drafts 
as they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs.

For more information about the Routing Directorate, please see 
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir



Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.



Document: draft-ietf-dmm-ondemand-mobility-15

Reviewer: Jon Hardwick

Review Date: 24 Jan 2019

Intended Status: Informational



Comments

---



The document was easy to read and absorb.



I found this sentence from the abstract a bit misleading: "This document 
describes a solution for taking the application needs into account..."  The 
word "solution" made me expect that the document would go into detail about how 
an IP stack could request the different sorts of IP address from the network.

In fact, you are proposing an API.  I would recommend changing to "This 
document proposes an API that an application can use to inform the IP stack of 
its requirements for session continuity and/or IP address reachability".



On a related point, is there any work you can refer to that provides a 
mechanism for implementing this API?



The boilerplate in section 2 is out of date.  Please see RFC 8174 for the 
latest boilerplate.



On page 6, I spotted a stray ")" in this sentence:



   It is outside the scope of this specification to define how the host

   requests a specific type of prefix and how the network indicates the

   type of prefix in its advertisement or in its reply to a request).


-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WGLC on draft-ietf-dmm-distributed-mobility-anchoring-11

[Moses, Danny]

Hi,
I support WGLC for this draft.

Danny

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Wednesday, January 09, 2019 20:43
To: dmm@ietf.org
Subject: [DMM] WGLC on draft-ietf-dmm-distributed-mobility-anchoring-11

Folks - As we discussed in the WG meeting at IETF103, we are issuing WGLC on 
draft-ietf-dmm-distributed-mobility-anchoring-11.

The document went through several revisions and there were good amount of 
reviews on this document.  The authors have addressed all the comments and 
there are no open issues that we are tracking at this time. We believe the 
document is ready for IESG reviews and like to confirm the same from the 
working group.


The following message commences a two week WGLC for all feedback.

Document Link:
https://www.ietf.org/id/draft-ietf-dmm-distributed-mobility-anchoring-11.txt

The target status for this document is "Informational".

Please post any comments/concerns on the draft.

Thanks!
Dapeng & Sri

-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WGLC on draft-ietf-dmm-pmipv6-dlif-03

[Moses, Danny]

Hi,

I support WGLC for this draft.

Danny

From: Sri Gundavelli (sgundave) mailto:sgund...@cisco.com>>
Date: Wed, Jan 9, 2019 at 7:43 PM
Subject: [DMM] WGLC on draft-ietf-dmm-pmipv6-dlif-03
To: dmm@ietf.org mailto:dmm@ietf.org>>

Folks – As we discussed in the WG meeting at IETF103, we are issuing WGLC on 
https://www.ietf.org/id/draft-ietf-dmm-pmipv6-dlif-03.txt.

We have also made one key change to the document status, moving it from 
Standards Track to Experimental Track. We the chairs have talked to the authors 
and they are OK with this change. We are dong this as we are not sure about any 
potential vendor implementations and so we chose to keep this on experimental 
track.

The document went through several revisions and there were good amount of 
reviews on this document.  The authors have addressed all the comments and 
there are no open issues that we are tracking at this time. We believe the 
document is ready for IESG reviews and like to confirm the same from the 
working group.


The following message commences a two week WGLC for all feedback.

Document Link:
 
https://www.ietf.org/id/draft-ietf-dmm-pmipv6-dlif-03.txt

The target status for this document is “Experimental”.

Please post any comments/concerns on the draft.


Thanks!
Dapeng & Sri


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Genart last call review of draft-ietf-dmm-ondemand-mobility-15

[Moses, Danny]

Hi Russ,

Thank you for your comments and questions. Please see the responses to each 
issue.
I copied the comments and followed each one with a response for ease of review.


Minor Concerns:

Section 2: Please update the first paragraph to reference RFC 8174 in addition 
to RFC 2119, as follows: 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.
>>Response: Yes, I will apply the newer text and add a reference to RFC8174.


Nits:

Section 1: s/It should be noted that in/In/
>>Response: I will apply the change.


Section 1 uses one style for listing two properties, and then Section 3 uses 
another style for listing four types of IP address.  Please pick one style and 
use it in both places.
>>Response: I am changing the listing style in section 1 to the one used in 
>>section 3.


Section 4.1: s/secsc(/setsc(/  -- in a comment
>>Response: I will correct the typo in the comment


Questions:

Should getsc() also be described in Section 6?
>>Response: Actually, ‘getsc()’ is a typo. The draft proposes only one new API: 
>>‘setsc()’. I will correct all occurrences of ‘getsc()’ to ‘setsc()’.

Should anything be added to the Security Considerations about CGA?
>>Response: I do not think so. This draft does not deal with how source IP 
>>addresses are generated. Specifically, it does not change the way a source 
>>IPv6 addresses are constructed from a given source IPv6 prefix. It only 
>>specifies a way for applications to express their desire regarding the type 
>>of service provided by networks for mobility management.  







Thanks and regards,
Danny



-Original Message-
From: Russ Housley [mailto:hous...@vigilsec.com] 
Sent: Friday, January 04, 2019 00:58
To: gen-...@ietf.org
Cc: draft-ietf-dmm-ondemand-mobility@ietf.org; i...@ietf.org; dmm@ietf.org
Subject: Genart last call review of draft-ietf-dmm-ondemand-mobility-15

Reviewer: Russ Housley
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at 
.

Document: draft-ietf-dmm-ondemand-mobility-15
Reviewer: Russ Housley
Review Date: 2019-01-03
IETF LC End Date: 2019-01-16
IESG Telechat date: unknown

Summary: Almost Ready


Major Concerns:

None.


Minor Concerns:

Section 2: Please update the first paragraph to reference RFC 8174 in addition 
to RFC 2119, as follows: 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.


Nits:

Section 1: s/It should be noted that in/In/

Section 1 uses one style for listing two properties, and then Section 3 uses 
another style for listing four types of IP address.  Please pick one style and 
use it in both places.

Section 4.1: s/secsc(/setsc(/  -- in a comment


Questions:

Should getsc() also be described in Section 6?

Should anything be added to the Security Considerations about CGA?


-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] draft-ietf-dmm-pmipv6-dlif ready for WGLC in my opinion

[Moses, Danny]

Hi dmm-ers,

I would like to express my opinion after reading the previous version of 
draft-ietf-dmm-pmipv6-dlif and providing comments, that the draft is ready for 
WGLC. It is a needed concept for distributed anchoring and was implemented and 
demoed in IETF several years ago.

I am aware of the tendency of IETF to be extremely careful about the readiness 
of documents before publishing, but is some cases (and this is one of them), it 
comes with a very high cost in terms of continuously delaying work.

Clearly, more reviews are always welcome, but we have to set a time limit. I 
propose to initiate WGLC and by that also set a schedule for last reviews.

Thanks,
Danny
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] New version for draft-ietf-dmm-ondemand-mobility

[Moses, Danny]

Hi,

I have posted a new version for the draft-ietf-dmm-ondemand-mobility with 
changes addressing  the comments of the early review - as discussed in the last 
dmm session.

The changes include:

1.  Replacing 'IP session continuity' with 'session continuity' and related 
changes throughout the draft.

2.  Added section 4.2 Message flow example, with an example of a message 
flow showing the interaction between applications, the IP stack in the mobile 
host and the network, related to requesting IP addresses of specific session 
continuity types.

I hope this draft is more ready for IESG review.

Regards,
Danny
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Response to the early review of draft-dmm-ondemand-mobility

[Moses, Danny]

Hi Sri,

Thanks for the additional comments, they are in line with my views.
I will discuss with Brian an update the WG as you recommended.

Thanks,
Danny


From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: Wednesday, June 13, 2018 00:10
To: Moses, Danny ; dmm@ietf.org
Cc: Brian Haberman 
Subject: Re: [DMM] Response to the early review of draft-dmm-ondemand-mobility

Hi Danny,

You can discuss this with Brian directly (keeping the WG in the loop). You do 
not need consensus from the WG. If there is any objection from the WG on any of 
the issue resolutions, then it will become a WG issue.

Please see inline for additional comments.

Sri



From: dmm mailto:dmm-boun...@ietf.org>> on behalf of 
"Moses, Danny" mailto:danny.mo...@intel.com>>
Date: Sunday, June 10, 2018 at 4:21 AM
To: "dmm@ietf.org<mailto:dmm@ietf.org>" mailto:dmm@ietf.org>>
Subject: [DMM] Response to the early review of draft-dmm-ondemand-mobility

Hi all,

This is the initial draft of the response to the Brian Haberman's early review 
of draft-dmm-ondemand-mobility.

I would like to thank Brian for his review and provide the WG's response.
Please see the first draft of the response below and provide comments. I think 
that the first issue requires most of our attention. Assuming that most of the 
people will agree with my opinion that Brian is correct in his comment about 
the term 'IP session continuity', please help me in using a better term. I have 
provided some alternatives and am also open to more suggestions.

I have copied Brian's comments and provided a response to each one.

Thanks,
Danny

Response to the early review of  draft-dmm-ondemand-mobility:

Reviewer: Brian Haberman
Review result: Not Ready

This is an early review request for draft-ietf-dmm-ondemand-mobility.

I am having a hard time with the thrust of this document. The following issues 
really need to be addressed in some form...

1. Where is the concept of an IP session defined? Given that IP is 
connectionless, this term is really about IP address stability and its 
lifetime. A new term could/should be coined to reflect what is really needed.

Yes, this is a fare comment.
Most of the work that has been done in relation with mobility boils down to the 
stableness of the mobile node's source IP address (or source IP prefix). The 
implication to applications, is their ability or inability to maintain the 
transfer of packets with the corresponding node - which may be perceived this 
as a 'session'.
On the other hand, the term 'session' is overloaded and might not be accurate 
enough in this context.

I checked other RFCs:
RFC5944 uses the text: '...the ability to communicate...' or '... the ability 
to maintain transport and high-layer connections...'.
RFC4830 uses the text (under the definition of 'Global Mobility Management 
Protocol'): '...end-to-end routing of packets for the purpose of maintaining 
session continuity when management causes a topology change...'.
Since I would like to avoid getting into a debate on a new definition (which 
could take years and is probably on a wider scope than dmm), I would like to 
suggest some alternatives:

1.  Maintaining transport and higher-layer connections

2.  Continuity of IP connectivity

3.  Session continuity

4.  Source IP prefix validity

5.  Socket operation validity


We have the term, "Mobility Session" defined in MIP specs. But, I do not 
believe we have provided any explicit definition for the term "IP Session". RFC 
7847 (Logical Interface Support) uses the "IP Session" term, but with no 
explicit definition. I think providing some definition will help. I do not 
think it will take years to converge on a definition. If you can just state 
your assumption or technical requirements on what the expectations or from the 
stack, application or routing point of view, that should do it. You may want to 
propose some text to Brian.





2. The needs described in this document have a mix of the ID/Location split 
issues raised in a variety of other specifications. It would be good to clarify 
what is different here.

This document does not describe a need to perform ID/Location split, or defines 
a new way to maintain the validity of an IP prefix. It simply defines a new 
ability of applications in a host to influence the type of service provided by 
the mobile network.

Most current cellular network performs tunneling automatically to all 
provisioned IP prefixes regardless of whether or not this is needed. This 
document defines a way for applications to indicate to networks if such service 
is actually needed or not.
The benefit of providing this information to the network is saving unnecessary 
network resources (required for maintaining the validity of the source IP 
prefix) and enabling more optimized routes to packet transmitted and received 
by mobile nodes (as mentioned in the document).

I would 

[DMM] Response to the early review of draft-dmm-ondemand-mobility

[Moses, Danny]

Hi all,

This is the initial draft of the response to the Brian Haberman's early review 
of draft-dmm-ondemand-mobility.

I would like to thank Brian for his review and provide the WG's response.
Please see the first draft of the response below and provide comments. I think 
that the first issue requires most of our attention. Assuming that most of the 
people will agree with my opinion that Brian is correct in his comment about 
the term 'IP session continuity', please help me in using a better term. I have 
provided some alternatives and am also open to more suggestions.

I have copied Brian's comments and provided a response to each one.

Thanks,
Danny

Response to the early review of  draft-dmm-ondemand-mobility:

Reviewer: Brian Haberman
Review result: Not Ready

This is an early review request for draft-ietf-dmm-ondemand-mobility.

I am having a hard time with the thrust of this document. The following issues 
really need to be addressed in some form...

1. Where is the concept of an IP session defined? Given that IP is 
connectionless, this term is really about IP address stability and its 
lifetime. A new term could/should be coined to reflect what is really needed.

Yes, this is a fare comment.
Most of the work that has been done in relation with mobility boils down to the 
stableness of the mobile node's source IP address (or source IP prefix). The 
implication to applications, is their ability or inability to maintain the 
transfer of packets with the corresponding node - which may be perceived this 
as a 'session'.
On the other hand, the term 'session' is overloaded and might not be accurate 
enough in this context.

I checked other RFCs:
RFC5944 uses the text: '...the ability to communicate...' or '... the ability 
to maintain transport and high-layer connections...'.
RFC4830 uses the text (under the definition of 'Global Mobility Management 
Protocol'): '...end-to-end routing of packets for the purpose of maintaining 
session continuity when management causes a topology change...'.
Since I would like to avoid getting into a debate on a new definition (which 
could take years and is probably on a wider scope than dmm), I would like to 
suggest some alternatives:

1.  Maintaining transport and higher-layer connections

2.  Continuity of IP connectivity

3.  Session continuity

4.  Source IP prefix validity

5.  Socket operation validity



2. The needs described in this document have a mix of the ID/Location split 
issues raised in a variety of other specifications. It would be good to clarify 
what is different here.

This document does not describe a need to perform ID/Location split, or defines 
a new way to maintain the validity of an IP prefix. It simply defines a new 
ability of applications in a host to influence the type of service provided by 
the mobile network.

Most current cellular network performs tunneling automatically to all 
provisioned IP prefixes regardless of whether or not this is needed. This 
document defines a way for applications to indicate to networks if such service 
is actually needed or not.
The benefit of providing this information to the network is saving unnecessary 
network resources (required for maintaining the validity of the source IP 
prefix) and enabling more optimized routes to packet transmitted and received 
by mobile nodes (as mentioned in the document).

3. The draft only references host-based Mobile IP specifications. What are the 
implications when other solutions (e.g., PMIP) are employed?

Please clarify this point.
I checked once more and did not find any reference in the text to the 
host-based Mobile IP. Furthermore, the context of this document is about 
management of IP prefixes performed by the network (e.g. proxy...) and the 
ability of applications to indicate when such operation are not needed. It does 
not specify specific operations, but clearly, PMIP, GTP, ID/Location separation 
are examples of such operations.
The documents provides some pointers to RFC that define these operations, among 
them: RFC5563 - Proxy Mobile IPv4 and RFC 5213 - Proxy Mobile IPv6.
So what exactly is missing?

4. It is problematic that this document explicitly rules out of scope any 
discussion of how this API interacts with address assignment methods (e.g., 
DHCP). Clearly, there will need to be a way for this API to influence each of 
the address assignment methods available. Some of the classes of IP addresses 
described in this document require certain lifetime guarantees from the address 
assignment method. That needs to addressed since it will require changes to 
every assignment method.

There are two other documents in process in DMM that address the way 
applications convey the required service from the network and for the network 
to update the host of the assigned service:

-draft-moses-dmm-dhcp-ondemand-mobility - specifying extensions to 
DHCPv6, and

-draft-feng-dmm-ra-prefixtype - specifying extension to 

Re: [DMM] IETF102 - Call for agenda items

[Moses, Danny]

I agree that if we manage to resolve the comments prior to the meeting, the 
slot is not required.
However, I am not optimistic and believe that we most like will need the slot. 
So I propose to reserve the time for this topic.

I will post responses before the end of this week so the WG can review and 
provide feedback.

Thanks,
Danny

From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: Wednesday, June 06, 2018 22:56
To: Moses, Danny 
Cc: dmm@ietf.org
Subject: Re: IETF102 - Call for agenda items

Danny - Unless you are not able to resolve the comments that you have received 
from IESG, or if the WG disagrees with your resolutions, we may not need this 
slot.  I have not seen any responses from you guys yet for the review comments. 
I suggest you guys propose your text to the WG/reviewer on how you plan to 
resolve those comments, and lets decide if we need WG feedback. For now, I am 
putting this request on hold.


Sri



From: "Moses, Danny" mailto:danny.mo...@intel.com>>
Date: Wednesday, June 6, 2018 at 12:51 PM
To: Sri Gundavelli mailto:sgund...@cisco.com>>
Cc: "dmm@ietf.org<mailto:dmm@ietf.org>" mailto:dmm@ietf.org>>
Subject: RE: IETF102 - Call for agenda items


Hi,



Please assign a slot for the following:



Topic name: Response to early review of draft-ietf-dmm-ondemand-mobility-14

Presenter: Danny Moses

Time: 15 minutes

Draft Reference: draft-ietf-dmm-ondemand-mobility-14



Thanks,

Danny



-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Wednesday, June 06, 2018 18:04
To: dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] IETF102 - Call for agenda items



Folks - Gentle reminder. Please send your requests for agenda slots for IETF 
102. If you have already done so, you can ignore this. Please include the 
following information.





  ---

  Topic Name:

  Presenter Name:

  Time:

  Draft Reference:

---









Sri









>

>-Original Message-

>From: dmm [mailto:dmm-boun...@ietf.org<mailto:dmm-boun...@ietf..org>] On 
>Behalf Of Sri Gundavelli

>(sgundave)

>Sent: Thursday, May 3, 2018 5:32 PM

>To: dmm@ietf.org<mailto:dmm@ietf.org>

>Subject: [E] [DMM] IETF102 - Call for agenda items

>

>The DMM working group is planning to meet in IETF 102, week of 16th of

>July, 2018 at Montreal. We currently have requested for one meeting,

>which is a 2.5 hour slot.

>

>We realize in IETF101 we had many items with a fully packaged agenda,

>and could not allocate enough time for any of the topics. For this

>meeting, we want to avoid that problem by asking for an additional

>meeting slot, but we want to be sure there are enough items for

>discussion before we lock the resources.

>

>So, if you need a presentation slot, please send your request to the

>chairs (as a response to this email) with the following information. We

>still have time and so its not required that you need a published I-D,

>but do let us know in the next few days if you are planning to make a

>presentation.

>

>

>  ---

>>Topic Name:

>>Presenter Name:

>>Time:

>>Draft Reference: (Optional)

>>---

>

>Regards

>Dapeng & Sri

>>>

>>

>

>___

>dmm mailing list

>dmm@ietf.org<mailto:dmm@ietf.org>

>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailm

>an_

>listinfo_dmm=DwICAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=I

>diS

>ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=3YmCyVAo

>iC_

>ugQMmv8VcJoITk2D8QR4ZHgE34zzz0CY=AHrommWakT2klf1og05nny7we_JVQm8flSZ8

>ZZ7

>ASgw=



___

dmm mailing list

dmm@ietf.org<mailto:dmm@ietf.org>

https://www.ietf..org/mailman/listinfo/dmm<https://www.ietf.org/mailman/listinfo/dmm>

-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF102 - Call for agenda items

[Moses, Danny]

Hi,



Please assign a slot for the following:



Topic name: Response to early review of draft-ietf-dmm-ondemand-mobility-14

Presenter: Danny Moses

Time: 15 minutes

Draft Reference: draft-ietf-dmm-ondemand-mobility-14



Thanks,

Danny



-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Wednesday, June 06, 2018 18:04
To: dmm@ietf.org
Subject: Re: [DMM] IETF102 - Call for agenda items



Folks - Gentle reminder. Please send your requests for agenda slots for IETF 
102. If you have already done so, you can ignore this. Please include the 
following information.





  ---

  Topic Name:

  Presenter Name:

  Time:

  Draft Reference:

---









Sri









>

>-Original Message-

>From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli

>(sgundave)

>Sent: Thursday, May 3, 2018 5:32 PM

>To: dmm@ietf.org

>Subject: [E] [DMM] IETF102 - Call for agenda items

>

>The DMM working group is planning to meet in IETF 102, week of 16th of

>July, 2018 at Montreal. We currently have requested for one meeting,

>which is a 2.5 hour slot.

>

>We realize in IETF101 we had many items with a fully packaged agenda,

>and could not allocate enough time for any of the topics. For this

>meeting, we want to avoid that problem by asking for an additional

>meeting slot, but we want to be sure there are enough items for

>discussion before we lock the resources.

>

>So, if you need a presentation slot, please send your request to the

>chairs (as a response to this email) with the following information. We

>still have time and so its not required that you need a published I-D,

>but do let us know in the next few days if you are planning to make a

>presentation.

>

>

>  ---

>>Topic Name:

>>Presenter Name:

>>Time:

>>Draft Reference: (Optional)

>>---

>

>Regards

>Dapeng & Sri

>>>

>>

>

>___

>dmm mailing list

>dmm@ietf.org

>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailm

>an_

>listinfo_dmm=DwICAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=I

>diS

>ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=3YmCyVAo

>iC_

>ugQMmv8VcJoITk2D8QR4ZHgE34zzz0CY=AHrommWakT2klf1og05nny7we_JVQm8flSZ8

>ZZ7

>ASgw=



___

dmm mailing list

dmm@ietf.org

https://www.ietf.org/mailman/listinfo/dmm
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Call for adoption of draft-bernardos-dmm-pmipv6-dlif-01 as DMM WG document

[Moses, Danny]

Hi,

Adopting a draft as a WG draft does not mean that we accept it as is and plan 
not to improve it. It means that the WG agrees that it is something that we 
want to work on and that it aligns with the WG charter.

So the fact that there are some fixes in the pipeline is irrelevant, in my 
opinion,  to the decision whether to adopt a draft or not. Clearly all comments 
must be addressed before WGLC, but we are not there yet.

My recommendation is to adopt the draft and continue working on it as a WG 
draft.

Regards,
Danny

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of dirk.von-h...@telekom.de
Sent: Wednesday, March 28, 2018 14:40
To: sgund...@cisco.com; dmm@ietf.org
Subject: Re: [DMM] Call for adoption of draft-bernardos-dmm-pmipv6-dlif-01 as 
DMM WG document

Hi Sri,
recalling that there have been some reviews on this version -01 and the authors 
already replied and promised consideration in next version -02 before London I 
would recommend to have this call on the new -02 version.
Would this be possible to provide soon?
Other opinions?
Thanks!
Best Regards
Dirk
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Mittwoch, 28. März 2018 06:26
To: dmm@ietf.org
Subject: [DMM] Call for adoption of draft-bernardos-dmm-pmipv6-dlif-01 as DMM 
WG document

Folks:

During IETF 99 and IETF 100 we polled the room for their interest in taking up 
draft-bernardos-dmm-pmipv6-dlif- as a DMM working group document. In both those 
occasions there was good amount of support for taking up this work.. The chairs 
would like to confirm the same over the mailing list.  Please provide your 
feedback on the same.

This adoption call will end by 11th of April, 2018.

Pointer:
https://tools.ietf.org/html/draft-bernardos-dmm-pmipv6-dlif-01


Regards
Sri

-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Call for adoption of draft-bernardos-dmm-pmipv6-dlif-01 as DMM WG document

[Moses, Danny]

Hi,

I support making this draft a WG draft.

BR,
Danny

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Wednesday, March 28, 2018 07:26
To: dmm@ietf.org
Subject: [DMM] Call for adoption of draft-bernardos-dmm-pmipv6-dlif-01 as DMM 
WG document

Folks:

During IETF 99 and IETF 100 we polled the room for their interest in taking up 
draft-bernardos-dmm-pmipv6-dlif- as a DMM working group document. In both those 
occasions there was good amount of support for taking up this work.. The chairs 
would like to confirm the same over the mailing list.  Please provide your 
feedback on the same.

This adoption call will end by 11th of April, 2018.

Pointer:
https://tools.ietf.org/html/draft-bernardos-dmm-pmipv6-dlif-01


Regards
Sri

-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] New Liaison Statement, "LS on indicating service continuity usage of the additional IPv6 prefix in Router Advertisement"

[Moses, Danny]

Hi Alex,

As you know, I have written a draft that defines an extension to DHCPv6 for 
supporting OnDemand values (also for SSC modes - Service and Session 
Continuity) with prefix delegation. I discussed that with SA2 people and they 
are aware of that possibility. Currently, SA2 prefer the RA mobility extension 
and there was not enough support in the dmm WG for the DHCPv6 option. 

So, unfortunately I do not think we should advocate for an approach that is not 
supported by us (dmm).

Please also note that SSC modes is part of release 15. Please refer to TS 
23.501 and TS 23.502 for more technical details. Stage 2 of release 15 has been 
finalized in December 2017 and Stage 3 is scheduled for the summer of 2018 (I 
do not remember the exact date).

Unfortunately, we (IETF) are often too late in providing specifications in time 
for 3GPP releases. This is partially due to our tendency to drag our work (in 
my opinion). Just see how long the OnDemand work is taking us. Here we have a 
chance to provide a specification that will be gladly adopted by the Cellular 
world. If not in release 15, at least in release 16.

Let's meet the challenge and prove to ourselves that we can be useful in this 
case.

By the way, my personal view is that we should provide the extensions to both 
RA and DHCPv6. I accept that due to the fact that SA2 prefers RA, we should 
give it a higher priority.

Regards,
Danny   

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandre Petrescu
Sent: Friday, March 23, 2018 09:48
To: dmm@ietf.org
Subject: Re: [DMM] New Liaison Statement, "LS on indicating service continuity 
usage of the additional IPv6 prefix in Router Advertisement"



Le 22/03/2018 à 18:49, Liaison Statement Management Tool a écrit :
[...]

> SA2 would like to point out that among the four mechanisms for address 
> configuration delivery mentioned in your LS reply (i.e.
> DHCPv4, DHCPv6, IPv6 ND and IKEv2) only the IPv6 ND mechanisms, and in 
> particular the Router Advertisement message, seem to be applicable in 
> the 5G System architecture in the specific context of Multi-homed
> IPv6 PDU Sessions.
Please tell SA2 that current 4G cellular networks are specified to, and do use 
to some extent, DHCPv6 Prefix Delegation to assign a prefix to an end node like 
an IoT Router.

A /56 prefix delivered to the end node should have the same capabilities as an 
address. We also want that /56 prefix to be more stable, or less stable, etc.

I dont understand why 5G System architecture excludes DHCPv6 from the list of 
applicable address configuration delivery.

I understand why 5G System architectures prefers ND - it is for addresses.

Alex

> 
> 
> With respect to the following question in the IETF’s reply LS:
>  We also like to point out that, all though the LS statement 
> explicitly refers to both IPv4 and IPv6 address types, however it only 
> mentions about (RA) (IPv6
>  ND implied) as the mechanism for address property delivery. 
> It is to be noted that the approach of delivering coloring meta-data in RA 
> messages will most
>  likely be to limited to IPv6 address/prefix types and will 
> not be extended to IPv4 addresses. If this capability is required for IPv4, 
> we may have to possibly
>  extend DHCP protocol(s).
> 
>  We request 3GPP to clarify if the Ask is explicitly for 
> IPv6, or if its for both IPv4 and IPv6 address/prefix types.
> 
> 
> SA2 would like to clarify that the request is explicitly for IPv6. SA2 
> discussed the example documents that were referenced in your LS reply and 
> concluded that the following draft seems to be the most promising candidate 
> for the problem under discussion in this correspondence: 
> https://www.ietf.org/id/draft-feng-dmm-ra-prefixtype-01.txt.
> SA2 would like to kindly ask IETF DMM working group to keep SA2 updated of 
> the work on the subject of including property meta-data in IPv6 ND address 
> assignment procedures for potential use in the 5G System to indicate the 
> mobility property of additional IPv6 prefixes assigned as part of the 
> Multi-homed IPv6 PDU Session functionality.
> 
> 
> 2 Actions
> To IETF DMM working group:
>  ACTION: SA2 would like to kindly ask IETF DMM working group to keep SA2 
> updated of the work on the subject of including property meta-data in IPv6 ND 
> address assignment procedures for potential use in the 5G System to indicate 
> the mobility property of additional IPv6 prefixes assigned as part of the 
> Multi-homed IPv6 PDU Session functionality.
> 
> 
> 3 Dates of next TSG SA WG2 meetings
> TSG SA WG2 Meeting 12716 - 20 Apr 2018Sanya, CN
> TSG SA WG2 Meeting 127-Bis28 May – 1 Jun 2018 Newport Beach, US
> Attachments:
> 
>  S2-182967_was2844_LS_IETF_SSC3
>  
> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-03-22-3gpp-
> 

[DMM] New version to draft-ietf-dmm-ondemand-mobility - 14

[Moses, Danny]

Hi,

I update the draft with some minor editorial fixes, mainly to the pseudo code 
part. These are mainly breaking long lines so that they do not exceed the 72nd 
column.

You can continue addressing draft-ietf-dmm-ondemand-mobility-13 for WGLC review 
- there are no other modifications.

Thanks and regards,
Danny

-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Substantial comments on draft draft-ietf-dmm-ondemand-mobility

[Moses, Danny]

This message contains a list of substantial comments received for 
draft-ietf-dmm-ondemand-mobility. These comments were received on the DMM 
mailing list, during DMM WG session and via other email exchange. They are 
ordered from most resent to older ones:

*Provide on the mailing list, a list of use-cases for each address type

*Add the Graceful-replacement address type

*Select alternative for resolving the need to maintain the non-blocking 
nature of setsockopt() - add the setsc() function

*Do not use setsockopt() in a way that blocks the invoking thread until 
a prefix is allocated by the network.

*Add coding example to the draft

*Merge with I-D.sijeon-dmm-use-cases-api-source

*Remove the text indicating source IP address allocation by the 
network. Leave only source IP prefix allocation.

BR,
Danny
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule

[Moses, Danny]

I am OK with the current structure.

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Tuesday, November 28, 2017 23:45
To: Bertz, Lyle T [CTO] ; dmm@ietf.org
Subject: Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule

So, then I don't see the point of changing the current structure. Other 
opinions?

From: Bertz, Lyle T [CTO] [mailto:lyle.t.be...@sprint.com]
Sent: Dienstag, 28. November 2017 19:42
To: Marco Liebsch; dmm@ietf.org
Subject: RE: FPC: Move Descriptor-/Action-Value into Rule

I intentionally left out my opinion from the analysis.  I am against both as 
the reusability for a value of a Descriptor/Action (especially descriptor) does 
not meet the define once, use many objective for Descriptors.  The define once, 
use many for Rule re-use is already present in Policy.

From: Marco Liebsch [mailto:marco.lieb...@neclab.eu]
Sent: Tuesday, November 28, 2017 9:54 AM
To: Bertz, Lyle T [CTO] 
>; 
dmm@ietf.org
Subject: RE: FPC: Move Descriptor-/Action-Value into Rule

Hi Lyle,

I see the analysis you brought, thanks for that. My proposal #2 is not my 
preference as it was
only an attempt to extend and match what Satoru had in mind without losing the 
value in current
descriptors/actions. Maybe it did not help ;-)

I just see that an action value belongs to an actions type. Clearly there are 
types which don't require
a value, e.g. drop. Here value is void and re-usability is ensured, IMO.
But moving the value entirely out of action / descriptor I just saw 
shortcomings.

So, you brought examples and arguments against proposal #1 and proposal #2.
But I could not conclude if there are any preferences or alternative? Do we 
leave it as it is now?

marco


From: Bertz, Lyle T [CTO] [mailto:lyle.t.be...@sprint.com]
Sent: Montag, 20. November 2017 15:15
To: Marco Liebsch; dmm@ietf.org
Subject: RE: FPC: Move Descriptor-/Action-Value into Rule

Marco,

Thank you for the write up of both proposals.  Forgive the length of the 
response but I wanted to provide concrete examples based upon the existing data 
types.

Summary, see below for examples and details:

-  Satoru's Proposal (Proposal 1) - the use of only ID/Type could be 
replaced by making the Type a U-Key (similar to a registry or identity in 
YANG). In any arrangement though only the Type could be use.  The downside for 
Proposal 1 is reusability.

-  Marco's Proposal (Proposal 2) - To make sense the setting MUST not 
be in any of the existing Settings, i.e. it is a setting that MUST NOT be tied 
to the Mobility-Context, DPN Interface or the fact that a DPN was assigned to 
enforce a Rule.  Does such an example exist?

>> My Opinion <

I would not pursue Proposal 1 due to the loss of reusability which is a key 
benefit of entities under the Policy Model.
I would not pursue Proposal 2 if we cannot find clear examples that the 
settings can be placed in other settings locations.  I cannot think of an 
example at this time but I am just one person and hope the team can provide 
such examples.

Lyle

>> Detail <<<


Let's take a step back.   Consider the IPFilterRule (RFC 6733) to block inbound 
port 22 traffic (even from itself)
"deny in ip from any to assigned 22"



Recall that from 6733, "The keyword "assigned" is the address or set of 
addresses assigned to the terminal."

If I use a 'IPFilterRule' Descriptor Type (it is not in the spec; I am making 
up a new type here) and provide a value of descriptor "in ip from any to 
assigned 22"  you will note the only Setting to deal with here is 'assigned'.

In Satoru's proposal, we will call it Proposal 1, we could see a Descriptor 
example as
Descriptor-Definition
Descriptor-Id = 22
Descriptor-Type = IPFilterRule
Action-Definition
Action-Id = 11
Action-Type = deny (or drop)
Rule-Definition
Rule-Id = 21231
Descriptor-Match-Type = AND
Descriptor-Reference

Descriptor-Id-Reference = 22
Descriptor-Value = in ip from any to assigned 22
Action-Reference
Action-Id-Reference = 11

We see the tradeoffs clearly in this example, when the value is directly 
determined by the type as in the deny Action-Type, the Action Reference is 
quite small.  In the case of the Descriptor we see the value is still 
incomplete and the setting 'assigned' is applied.

For Marco's proposal, we will call it Proposal 2:
Descriptor-Definition
Descriptor-Id = 22
Descriptor-Type = IPFilterRule
Descriptor-Value = in ip from any to assigned 22
Action-Definition
Action-Id = 11
Action-Type = deny (or drop)
Rule-Definition
Rule-Id = 21231
Descriptor-Match-Type = AND

Re: [DMM] Call for adoption of draft-matsushima-spring-dmm-srv6-mobile-uplane-03 as DMM WG document

[Moses, Danny]

I support the adoption of this draft.

BR,
Danny

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Wednesday, November 15, 2017 02:21
To: dmm@ietf.org
Subject: Re: [DMM] Call for adoption of 
draft-matsushima-spring-dmm-srv6-mobile-uplane-03 as DMM WG document

Please also note that the document is just a starting point and requires 
significant amount of community efforts  and participation before it can become 
a standard. The document does not address most of the issues, but the proposal 
is promising enough and so would like to take it up right away. Please comment.

Dapping & Sri



From: dmm > on behalf of Sri 
Gundavelli >
Date: Tuesday, November 14, 2017 at 4:02 PM
To: "dmm@ietf.org" >
Subject: [DMM] Call for adoption of 
draft-matsushima-spring-dmm-srv6-mobile-uplane-03 as DMM WG document

Folks:

The following message commences a two week call for opinions on the adoption of 
draft-matsushima-spring-dmm-srv6-mobile-uplane-03 as a DMM Working document.

---
The DMM working group is considering adopting the draft, 
"draft-matsushima-spring-dmm-srv6-mobile-uplane-03" as a working group 
document. The chairs have polled the room for opinions during IETF100, and it 
was determined that there is good support for taking up this work. The chairs 
would like to confirm the same in the mailing list.  Please provide your 
feedback.


Document Link:
https://www.ietf.org/id/draft-matsushima-spring-dmm-srv6-mobile-uplane-03.txt

Slides:
https://datatracker.ietf.org/meeting/100/materials/slides-100-dmm-srv6-for-mobile-user-plane/

Background:
https://datatracker.ietf.org/meeting/100/materials/slides-100-dmm-mobile-data-plane-evolution-motivation-goals/
---

Regards
Dapping & Sri

-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Any comments on the new version of the OnDemand draft (draft-ietf-dmm-ondemand-mobility-12 )?

[Moses, Danny]

Hi everyone,
This is another reminder about the new version of 
draft-ietf-dmm-ondemand-mobility-12<https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/>.
To the best of my efforts, this is the last draft with all comments addressed.

Are we ready for WGLC? If not, is there anything else to be addressed?

Thanks,
Danny

From: Moses, Danny
Sent: Sunday, August 13, 2017 14:59
To: dmm@ietf.org
Subject: Any comments on the new version of the OnDemand draft 
(draft-ietf-dmm-ondemand-mobility-12 )?

Hi everyone,

Two weeks ago I posted a new version of 
draft-ietf-dmm-ondemand-mobility-12<https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/>
 including modifications addressing comments in the last DMM session. I also 
posted on this list text that describe the different session continuity 
services and use-cases for each one.

Are there any comments?
Is the draft ready for another round of WGLC? If not, what else should we 
address?

Thanks,
Danny
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Any comments on the new version of the OnDemand draft (draft-ietf-dmm-ondemand-mobility-12 )?

[Moses, Danny]

Hi everyone,

Two weeks ago I posted a new version of 
draft-ietf-dmm-ondemand-mobility-12
 including modifications addressing comments in the last DMM session. I also 
posted on this list text that describe the different session continuity 
services and use-cases for each one.

Are there any comments?
Is the draft ready for another round of WGLC? If not, what else should we 
address?

Thanks,
Danny
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] New draft of draft-moses-dmm-dhcp-ondemand-mobility after dhc WG review

[Moses, Danny]

AT IETF98 (Chicago) I was request by the WG to present the 
draft-moses-dmm-dhcp-ondemand-mobility draft to the dhc group and have them 
review the DHCPv6 aspects of this draft.

At IETF99 (Prague), I presented the draft  and receive very useful comments and 
correction.
The new draft includes all the changes as a result of that review.

I am including in this email, the list of comments that were raised and the 
actions taken to improve the draft.
I hope that after this important milestone was achieved, the draft will be 
adopted by the dmm WG.



The following comments/questions were raised regarding the DHCP OnDemand draft 
(draft-moses-dmm-dhcp-ondemand-mobility):


1.  Replace the status code name from NoAddrsAvail to NoPrefixAvail

2.  The description of the server's behavior in response to an unrecognized 
encapsulated option in section 3 is wrong - fix it.

3.  Clarify the correlation of the service types and the lifetime attribute 
(especially for Fixed address types).

4.  Correct the fields of the Anchor Preference option

5.  Remove the definition of the Anchor Preference option. It is not needed.

6.  Check capital letters for keywords (MUST, SHOULD, MAY)

7.  Fix section 2 - RFC8174 (wording was updated). See RFC8156 - for 
example.

8.  Draft does not mention the Confirm and Rebind messages which are 
relevant for mobility support.


Actions:

1.  Replace the status code from NoAddrsAvail to NoPrefixAvail:
Done.


2.  Correct description of server's behavior when receiving an unrecognized 
option:
Replaced the original text:
"A server that does not support this option will discard it as well as the 
IA_PD Prefix option that had this option encapsulated in one of its 
IAprefix-options field.

If a client does not receive the requested prefix, it must resend the request 
without the desired IPv6 Continuity Service option since it is not supported by 
the server. In this case, the requesting device
(host or router) cannot assume any IP continuity service behavior for that 
prefix."

With:
"A server that does not support this option will ignore it and respond without 
taking into account the desired session continuity service. The response will 
not include the Continuity Service option encapsulated in the IAprefix-options 
field of the IA_PD prefix option.

The missing Continuity Service option in the response serves as an indication 
to the client that this feature is not supported by the server. It MAY use the 
allocated prefix (knowing it does not necessarily support the desired 
Continuity service), or perform any other action."

3.  Clarify the correlation of the service types and the lifetime attribute:


Adding section 3.1 to clarify the correlation between Session continuity 
services and 'lifetime':
3.1 Correlation between Session Continuity Service and lifetime values
The values to be used in the Preferred-lifetime and Valid-lifetime fields in 
the IA Prefix Option are out of the scope of this specification and left to 
implementation. It is recommended to provide longer lifetime values for Fixed 
and Session-lasting prefixes compared to the lifetime values of Non-persistent 
and Graceful-replacement prefixes because the network has guaranteed their 
validity regardless of the link to which the host is attached.

For clients using Graceful-replacement services, the network MAY obsolete a 
Prefix and allocate a new one from time to time especially in a 
mobility-related event. On such occasions, the network SHOULD provide a 
graceful period (lifetime) in which the obsoleted prefix can still be used and 
a new (longer) lifetime with the new prefix.
It is not recommended to use 0xFF (infinity) values for the lifetime of 
Fixed prefixes. Even though they are fixed, it is still safer to Rebind 
periodically. The lifetime value can be relatively long to reduce message 
exchange overhead.

Section 18.2 of 3633bis - Client Behavior:
"A client uses the Solicit message to discover DHCP servers configured to 
assign leases or return other configuration parameters on the link to which the 
client is attached.

A client uses Request, Renew, Rebind, Release and Decline messages during the 
normal life cycle of addresses and delegated prefixes. When a client detects it 
may have moved to a new link, it uses Confirm if it only has addresses and 
Rebind if it has delegated prefixed (and addresses)..."

Section 3.1 also has some clarifications regarding the client's operation after 
moving to a new link:
"Section 18.2 - Client Behavior of ietf-dhc-rfc3315bis specifies that when a 
client detects it may have moved to a new link, it uses Rebind if it has 
delegated prefixes. It is worth clarifying that a client does not HAVE to 
Rebind the prefixes if they are Fixed or Session-lasting prefixes."


4.  Correct the fields of the Anchor Preference option:
Since the Anchor Preference option is not needed (see next comment) it has been 
removed from the 

[DMM] More info on the different OnDemand Session Continuity services

[Moses, Danny]

In IETF99 (Prague) we introduced the "Graceful-Replacement" session continuity 
service in addition to the services specified in previous versions as a result 
of 3GPP specifying SSC (Service and Session Continuity) mode 3.

This led to some questions at IETF 99 regarding this new service and the need 
for the other services.

I am sending this note (as promised in the DMM session), to refresh everyone's 
memory and to provide use-cases for each service type.

Session Continuity Services are associated with source IP prefixes assigned to 
mobile nodes by the network. The TCP/IP stack in the mobile node creates IP 
addresses using those prefixes and assigns them upon request to specific IP 
sockets. Applications on the mobile nodes request and receive source IP 
addresses with a specific Session Continuity service.

The draft specifies the following session continuity services (or "type of 
source IP addresses" as they are referred to) in section 3.1:

- Fixed IP Address
A Fixed IP address is an address with a guarantee to be valid for a very long 
time, regardless of whether it is being used in any packet to/from the mobile 
host, or whether or not the mobile host is
connected to the network, or whether it moves from one point-of-attachment to 
another (with a different IP prefix) while it is connected.

- Session-lasting IP Address
A session-lasting IP address is an address with a guarantee to be valid 
throughout the IP session(s) for which it was requested. It is guaranteed to be 
valid even after the mobile host had moved from one
point-of-attachment to another (with a different IP prefix).

- Non-persistent IP Address
This type of IP address does not provide IP session continuity nor IP address 
reachability. The IP address is created from an IP prefix that is obtained from 
the serving IP gateway and is not maintained across gateway changes. In other 
words, the IP prefix may be released and replaced by a new one when the IP 
gateway changes due to the movement of the mobile host forcing the creation of 
a new source
IP address with the updated allocated IP prefix.

- Graceful Replacement IP Address
In some cases, the network cannot guarantee the validity of the provided IP 
prefix throughout the duration of the IP session, but can provide a limited 
graceful period of time in which both the original
IP prefix and a new one are valid. This enables the application some 
flexibility in the transition from the existing source IP address to the new 
one.

This gracefulness is still better than the non-persistence type of address for 
applications that can handle a change in their source IP address but require 
that extra flexibility.

Some use-cases:
Servers require Fixed IP addresses for reachability:
A server that is connected to a mobile network requires that it be reachable by 
its clients. One of the common ways of achieving reachability is by advertising 
its source IP address via DNS. For this purpose it is very useful to have an IP 
address that never changes (even when the server is disconnected from the 
network for maintenance). A change of source IP address will require a DNS 
update to re-enable clients to reach it. This is a time-consuming process that 
is not desirable in many cases.

Real-time application require session-lasting addresses for contiguous 
connection:
A real-time application that requires constant connection to peers through the 
network requires the connection to be session-lasting. A change of the source 
IP address will cause the destination address of packets sent back to become 
obsolete and, as a result, will not reach their destination. Although this 
error could be detected by higher-layer protocols, the time to detect the loss 
and overcome it might be too large for some applications. A session-lasting 
source IP address guarantees that this event never occurs.

Common viewers use non-persistent addresses:
There are various non-real time applications that people use like: web browsing 
(for non-streaming activities) and email clients. These applications do not 
require any special service from the network and can recover from a socket 
error caused by a change of the source IP address with minimal effect on their 
user's experience. Non-persistent source IP addresses will do. Using such 
addresses is beneficial for these applications and networks. Applications do 
not suffer from their traffic having to be encapsulated, decapsulated and 
routed through non-optimal routes and through congested mobility anchors, and 
networks can save their precious resources and still provide good connectivity.

Video viewers use Graceful-replacement addresses:
The Graceful-replacement service is a compromise between session-lasting 
service and non-persistent service. They are the best fit for applications like 
video applications that can handle a short disconnect from their server if they 
accumulate enough content in local buffers. Although, in many cases, the 
session-lasting 

[DMM] New version of the OnDemand draft: draft-ietf-dmm-ondemand-mobility-12

[Moses, Danny]

In IETF99 (Prague) the following comments/questions were raised regarding the 
OnDemand draft:


1.  Need to clarify in the text that the setsc() API is blocking

2.  It is not clear from the text that the APIs are abstract

3.  How does this work merge with RFC5014?

4.  Request for a description of a use-case for 'Graceful-Replacement'

To address these, we have posted a new version of the draft (v12) that includes 
the following modifications:
Clarified the text describing setsc():
The following text was added at the end of section 6.1 - New APIs:
"setsc() may block the invoking thread if it triggers the TCP/IP stack to 
request a new IP prefix from the network  to construct the desired source IP 
address. If an IP prefix with the desired session continuity features already 
exists (was previously allocated to the mobile host) and the stack is not 
required to request a new one as a result of setting the 
IPV6_REQUIRE_SRC_ON_NET flag (defined below), setsc() may return immediately 
with the constructed IP address and will not block the thread. "

Clarifying that the code in the draft is abstract
We changed the word 'code' to 'pseudo-code' where code samples are provided in 
the text
In section 3.4 the original text: "(See code example in Section 4 below)" was 
replaced with: "(See pseudo-code example in Section 4 below)"
In section 4 the original text: "The following example shows the code for 
creating..." was replaced with: "The following example shows the pseudo-code 
for creating..."

Merging this work with RFC5014:
Added a new section - 5.4 Coexistence with rfc5014 - that describes the 
coexistence with source address selection defined in RFC5014:
"RFC5014 defines new flags that may be used with setsockopt() to influence 
source IP selection for a socket. The list of flags include: source home 
address, care-of address, temporary address, public address CGA 
(Cryptographically Created Address) and non-CGA. When applications require 
session continuity service and use setsc() and bind(), they should not set the 
flags specified in RFC5014.

However, if an application sets a specific option using setsockopt() with one 
of the flags specified in RFC5014 and also selects a source IP address using 
setsc() and bind() the IP address that was generated by setsc() and bound using 
bind() will be the one used by traffic generated using that socket and the 
options set by setsockopt() will be ignored.

If bind() was not invoked after setsc() by the application, the IP address 
generated by setsc() will not be used and traffic generated by the socket will 
use a source IP address that complies with the options selected by 
setsockopt()."

In my next email to the list, I will provide a description of the OnDemand 
session continuity services including 'Graceful-Replacement' to elaborate on 
the differences between them and use-cases for their need.

Thanks for the useful comments.

Danny

-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] OnDemand alternatives for blocking function call

[Moses, Danny]

Hi guys,

A week ago I sent a memo describing several alternatives to resolve the issue 
of the blocking nature of the call to request a session continuity service (see 
- https://mailarchive.ietf.org/arch/msg/dmm/u0PmcSeOSQM6W80WbP7joeZv_l0 ). This 
was according to the directive that was agreed during the face-to-face meeting 
in Chicago.

So far, there was no feedback from the WG. I would like to request again to 
review the alternatives and comment. I would like to update the draft as soon 
as possible and reach WGLC in the next face-to-face meeting in Prague.

Please review and comment.

Thanks,
Danny

-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] DMM Meeting Minutes

[Moses, Danny]

Hi,

Scanned through the minutes, especially the topics I am more involved in.
They look fine - no corrections from my side.

Thanks Marco for the effort.

Danny

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Wednesday, April 05, 2017 18:03
To: dmm 
Subject: [DMM] DMM Meeting Minutes

Attached is the meeting minutes from the Chicago WG meeting. Thanks to Marco 
Liebsch for capturing the notes.

Please let the chairs know if we need to make any corrections to the notes.

Sri




-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] DMM IETF 98 meeting

[Moses, Danny]

Hi,
Following is the info for the sessions I have requested:

Title: On Demand Mobility Management Socket Extensions
Description: Update on changes to the draft since IETF 97
Time: 15 minutes
Presenter: Danny Moses
Draft Reference: 
draft-ietf-dmm-ondemand-mobility-10
Title: On Demand DHCPv6 Extensions
Description: Update on  changes to the draft since IETF 97
Time: 10 minutes
Presenter: Danny Moses
Draft Reference: 
draft-moses-dmm-dhcp-ondemand-mobility-05
Thanks,
Danny



From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Wednesday, February 15, 2017 18:58
To: Dapeng Liu ; dmm 
Subject: Re: [DMM] DMM IETF 98 meeting

Gentle Reminder . Please send your requests for presentation slot by 2/23. 
Please include

Title:
Description:
Time:
Presenters:
Draft Reference (If exists):



Regards
Sri

From: Dapeng Liu >
Date: Monday, January 23, 2017 at 2:09 AM
To: dmm >
Cc: Sri Gundavelli >
Subject: DMM IETF 98 meeting

Hello all,

IETF 98 meeting is approaching. If you want to request a time slot, please send 
request to the chairs before 2017-02-23.


Thanks,
Dapeng & Sri
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] New version for the On-Demand draft: draft-ietf-dmm-ondemand-mobility-10

[Moses, Danny]

Hi,

I have uploaded a new version including the text changes and usage example 
according to the comments received on the list.
I am planning to discuss two final topics during IETF98 and hopefully we can 
resume WGLC and release the draft.

Any comments?

Thanks,
Danny
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] DMM IETF 98 meeting

[Moses, Danny]

Hi,

I would like two slots:

·15 minutes to discuss progress on the OnDemand Socket extensions 
(draft: draft-ietf-dmm-ondemand-mobility)

·10 minutes to discuss changes in the OnDemand extensions for DHCPv6 
(draft: draft-moses-dmm-dhcp-ondemand-mobility)

Thanks,
Danny

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dapeng Liu
Sent: Monday, January 23, 2017 12:09
To: dmm 
Subject: [DMM] DMM IETF 98 meeting

Hello all,

IETF 98 meeting is approaching. If you want to request a time slot, please send 
request to the chairs before 2017-02-23.


Thanks,
Dapeng & Sri
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Blocking vs non-blocking function behavior

[Moses, Danny]

Hi,

Another concern that was raised is regarding the blocking vs non-blocking 
behavior of the setsockopt() function with the new OnDemand feature.
Lorenzo, in one of his comments, suggested to consider adding a new function 
with a blocking nature, in order not to surprise application developers with a 
blocking behavior to setsockopt() - which is a non-blocking function.

I agree that this may surprise and confuse application developers. I would like 
to suggest two alternatives for a solution:

1.  Add a new function (setsockoptblocking()) which has a blocking behavior

2.  Add a new option type to setsockopt() - IPV6_MOBILITY_ON_DEMAND - and 
describe its possible blocking behavior

The advantage of adding a new function, is the clear separation of the 
behavior. Setsockopt() always returns immediately (does not cause packet 
exchange), and setsockoptblocking() may block execution if it requires packet 
exchange to be able to complete its functionality (for example, when it 
requires a new Session-lasting IP prefix from the network).

The disadvantage is the definition of a new function to the long list of 
existing functions - which adds to the complexity of the Socket API (which is 
already quite complicated).

Adding a new option to the setsockopt() may be a good compromise. We can 
document that the new option may cause a blocking effect. It also clearly 
separates the functionality of OnDemand support from the rest of the options.

I also want to point out that so far I did not see any clear separation between 
blocking and non-blocking functions in the Socket API. It's true that some 
functions have a blocking nature (like connect() in TCP) and some don't but the 
separation of functions did not take that in account. I believe that there are 
functions that may or may not block execution depending on different situations 
and that setsockopt() will not be the first one to do so. So our extension to 
the API is still consistent with the current design.

What do you think?

Danny
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Code sample for draft-ietf-dmm-ondemand-mobility

[Moses, Danny]

I am including a code sample that I plan to add to the draft. Please review the 
code below and comment.
There is another topic that we need to finalize regarding the blocking vs 
non-blocking nature of the setsockopt() function but I prefer to discuss it 
under a separate email to simplify the tracking of the info. Clearly, if we 
decide to make changes to the function (or add a new function), the code sample 
will be updates.

Danny


 Code Sample ---
#include 
#include 

ints ;  
  // Socket id
sockaddr_in6 serverAddress ;
// server info for connect()
uint32_t  flags = IPV6_REQUIRE_SESSION_LASTING_IP ;

 // For requesting a Session-Lasting source IP address

  // Create an IPv6 TCP socket
s = socket(AF_INET6, SOCK_STREAM, 0) ;
if (s!=0) {
  // Handle socket creation error
 // ...
  } // if socket creation failed
else {

// Socket creation is successful
 // The application cannot connect yet, since it wants to use a 
Session-Lasting source IP address
 // It needs to request the Session-Lasting source IP before 
connecting
   if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCE, (void *) 
flags, sizeof(flags)) == 0){

 // setting session continuity to Session Lasting is successful
// The application can connect to the server

// Set the desired server's port# and IP address
  serverAddress.sin6_port = serverPort ;
  serverAddress.sin6_addr = serverIpAddress ;

// Connect to the server
  if (connect(s, , 
sizeof(serverAddress)) == 0) {
 // connect successful (3-way 
handshake has been completed with Session-Lasting source address
 // Continue application 
functionality
 // ...
  }  // if connect() is successful
  else {
 // connect failed
 // ...
 // Application code that handles 
connect failure and closes the socket
 // ...
  } // if connect() failed

   }  // if the request of a Session-Lasting source address was 
successful
   else {
// application code that does not use 
Session-lasting IP address
// The application may either connect without 
the desired Session-lasting service, or close the socket
//...
   } // if the socket was successfully created but a 
Session-Lasting source address was not provided
}  // if socket was created successfully

  // The rest of the application's code
  // ...

- Code Sample -
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 --

[Moses, Danny]

OK, two is a crowd…

I am thinking of the appropriate example and will send a draft for review.

I think there might be a confusion regarding the HOME and CoA flags. Although 
they are also related to mobility and enable applications a selection between 
two types of source IP addresses, they are very different and should not be 
discussed in the context of OnDemand.

The HOME and CoA flags are defined to enable an application to select between a 
HOME address and a Care-of address. This is in the context of Mobile IP (no 
Proxy Mobile IP) in which the network allocates both a Home Address and a 
Care-of Address to the mobile host. These flags enable applications to select 
the type of IP session continuity in this context (where the host is one 
termination point of the tunnel).

The context of the OnDemand draft is PMIP (or any proxy-based architecture, 
like GTP). In this context, the mobile host does not have a Home Address and a 
Care-of-Address since the tunnel is terminated by a proxy agent. So an 
application cannot specify its preference regarding Home or CoA.

Danny


From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Monday, December 19, 2016 03:04
To: Dave Dolson <ddol...@sandvine.com>
Cc: Moses, Danny <danny.mo...@intel.com>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 --

rOn Fri, Dec 9, 2016 at 3:59 AM, Dave Dolson 
<ddol...@sandvine.com<mailto:ddol...@sandvine.com>> wrote:
5. Are there new errors from bind(), listen() or connect(), etc.?
E.g., socket option is FIXED, but user explicitly specified a COA address to 
bind to?

+1. An implementer would probably choose to return EADDRNOTAVAIL if an API 
requested a type of address that is not available, but the draft makes no 
mention of that.

The draft also fails to mention which of the APIs will result in a request to 
the network (which can block for a long period of time) and which will not. It 
will be quite unexpected to app developers if system calls such as bind() and 
setsockopt(), which always return immediately, can suddenly block for whole 
seconds. It would also be highly unexpected if connect() on a UDP socket took a 
long time since it currently returns immediately.

I don't think it's a good idea to overload these existing system calls with new 
"obtain an prefix from the network" semantics. It's better to add a new system 
call for that.
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 --

[Moses, Danny]

Hi,

I have fixed the two typos you indicated in the previous emails.
Please see my embedded reply.
I am waiting for you reply on my question below regarding the source code 
example comment before uploading rev 10.

Thanks for the useful comments,
Danny

From: Dave Dolson [mailto:ddol...@sandvine.com]
Sent: Thursday, December 08, 2016 21:00
To: Moses, Danny <danny.mo...@intel.com>
Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
Subject: WGLC for draft-ietf-dmm-ondemand-mobility-08 --

I'm just catching up on the recent drafts, so apologies if this has been 
covered...

1. It seems like RFC 6724 will need to be updated by dmm-ondemand-mobility.
I'm unclear on how the algorithm should be modified. Has anyone worked this out?
My sense is that Rule 4 needs to be modified to consider the new flags.
Either this document should spell out the new algorithm, or we plan for 
RFC6724bis.

DM>> This is probably true. I am adding an RFC6724 fix to my ToDo list which is 
quite long, so I hope someone else
Takes this work. If not, let's do this together in the future.

2. Regarding the language about IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_COA
with legacy applications, I think it would be right to continue to support 
these.
PREFER_SRC_HOME could ask the network for FIXED, but automatically fall back to 
another address.
I think this is useful so that the application doesn't have to handle 
EAI_REQUIREDIPNOTSUPPORTED and try again.
(This comment goes back to point 1.)
DM>> First, for backwards compatibility, we must support these flags and the 
draft does not suggest otherwise. I prefer not to mix the functionality of the 
legacy flags - IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_COA with the new flags 
defined in the OnDemand draft. The main reason is that the former flags are 
related to a MIP environment were the MN terminates the tunnel, while the 
OnDemand flags are related to a proxy MIP environment (PMIP or GTP - for 
example) were the MN is not aware of the mobility support.

3. I don't understand the need for IPV6_REQUIRE_NON-PERSISTENT_IP as an 
explicit flag.
I would think it works better to provide this behavior if neither of the other 
flags are set.
Literally it says, "I will not accept a FIXED or SESSION_LASTING IP". Is that 
useful?
It can be provided, but I don't think any app would use it. Maybe just for 
testing the network?
DM>> Actually, this flag is one of the main motivation for this work. It 
enables the application to explicitly request the network not to create a 
tunnel for the IP session and avoid the unnecessary overhead associated with 
the tunnel. Opening a socket without using any of these flags means that the 
application does not have a preference to the type of service it receives from 
the network and leave the decision of choosing the type of service to either 
the IP stack in the MN or the network. It is important to enable the 
application to explicitly request a non-persistent service (and to receive an 
error if this service is not supported).

4. Consider an appendix showing source code for clients and servers with 
different requirements.
E.g., I believe that the setsockopt() needs to be done after socket() but 
before bind(), connect(), send(), sendmsg(), sendmmsg(), sendto(),etc.
(After any packets are sent is too late.)
I think it would be useful to show this recipe.
DM>> Your description is correct. I am wondering what is better, to add a short 
paragraph describing when setsockopt() should be used (as you described) or 
adding source code example. I prefer the text to be short and clear, and 
whenever we add source code examples we either end up with a long example, or 
limit ourselves to some obvious example that does not address all alternatives. 
Will adding the clarification that you pointed out be sufficient?

5. Are there new errors from bind(), listen() or connect(), etc.?
E.g., socket option is FIXED, but user explicitly specified a COA address to 
bind to?
DM>> We considered this, but decided not to go there since we would have to 
think of all the possible erroneous combination and programmer might do. We 
therefore, decided to clearly state that such behavior would be ignored.



David Dolson
Senior Software Architect, Sandvine Inc.

-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 --

[Moses, Danny]

Oops,

Sorry but I missed this email. Sorry.

I will review the comments and if needed, will upload another version.
Hope to complete the work by tomorrow.

Regards,
Danny

From: Dave Dolson [mailto:ddol...@sandvine.com]
Sent: Thursday, December 08, 2016 21:00
To: Moses, Danny <danny.mo...@intel.com>
Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
Subject: WGLC for draft-ietf-dmm-ondemand-mobility-08 --

I'm just catching up on the recent drafts, so apologies if this has been 
covered...

1. It seems like RFC 6724 will need to be updated by dmm-ondemand-mobility.
I'm unclear on how the algorithm should be modified. Has anyone worked this out?
My sense is that Rule 4 needs to be modified to consider the new flags.
Either this document should spell out the new algorithm, or we plan for 
RFC6724bis.

2. Regarding the language about IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_COA
with legacy applications, I think it would be right to continue to support 
these.
PREFER_SRC_HOME could ask the network for FIXED, but automatically fall back to 
another address.
I think this is useful so that the application doesn't have to handle 
EAI_REQUIREDIPNOTSUPPORTED and try again.
(This comment goes back to point 1.)

3. I don't understand the need for IPV6_REQUIRE_NON-PERSISTENT_IP as an 
explicit flag.
I would think it works better to provide this behavior if neither of the other 
flags are set.
Literally it says, "I will not accept a FIXED or SESSION_LASTING IP". Is that 
useful?
It can be provided, but I don't think any app would use it. Maybe just for 
testing the network?

4. Consider an appendix showing source code for clients and servers with 
different requirements.
E.g., I believe that the setsockopt() needs to be done after socket() but 
before bind(), connect(), send(), sendmsg(), sendmmsg(), sendto(),etc.
(After any packets are sent is too late.)
I think it would be useful to show this recipe.

5. Are there new errors from bind(), listen() or connect(), etc.?
E.g., socket option is FIXED, but user explicitly specified a COA address to 
bind to?



David Dolson
Senior Software Architect, Sandvine Inc.

-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] New OnDemand version - 09

[Moses, Danny]

Hi,

I have uploaded a new version of the draft: 
draft-ietf-dmm-ondemand-mobility-09, addressing Lorenzo's comments (and fixing 
some typos).

I would like to ask to continue the WGLC process on the newer version.

Thanks,
Danny
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

[Moses, Danny]

Hi Lorenzo,

OK, I can accept the text you proposed. I might add a disclaimer indicating 
that the exact interaction between the MN’s IP stack and the network is outside 
the scope of this draft in order to avoid a new discussion by people who might 
object the term ‘prefix’.

Regarding your question about the IPV6_REQUIRED_SRC_ON_NET flag, I will let 
Seil discuss with you. I would like to point out, however, that in the last DMM 
session, the WG voted to merge the draft that defined this flag with the 
OnDemand draft which had completed WGLC several week ago. This is the reason 
for the new version 08 of the OnDemand draft. I was not in the room during the 
discussion, but understood from the chair that there was a strong consensus for 
this merge.

I will generate a version 09, which hopefully address you concerns.

Regards,
Danny

From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Tuesday, December 06, 2016 17:20
To: Moses, Danny <danny.mo...@intel.com>
Cc: Peter McCann <peter.mcc...@huawei.com>; jouni.nospam 
<jouni.nos...@gmail.com>; draft-ietf-dmm-ondemand-mobil...@ietf.org; 
dmm@ietf.org
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

Danny,

I don't think assigning addresses vs. assigning prefixes is a question only of 
mechanism.

For example, consider the IPV6_REQUIRE_SRC_ON_NET flag. If the network is 
following IP addressing best practices, I don't see a need for it. If a host 
already has an IPv6 address of the desired type, what's the point of sending a 
request to the network to obtain one? Is it so that the requesting app can 
obtain a new IP address with the desired properties, unique to that particular 
socket? But if so, the host should just create a new address for that socket, 
with the desired properties. The network should not be requiring that the host 
ask for individual IP addresses; it should be allowing the host to form more IP 
addresses without requesting them.

In any case: since the socket options defined in this draft are IPv6-only, it 
only needs to concern itself with IPv6, and we're really only left with one 
case: a prefix. If so, how about the following?


When the IP stack is required to use a source IP address of a specific type, it 
can perform one of the following: it can use an existing address with the 
desired type (if it has one), or it can create a new one from an existing 
prefix of the desired type. If the host does not already have an IPv6 prefix of 
the specific type, it can request one from the network.

Using an address from an existing prefix is faster but might yield a less 
optimal route (if a hand-off event occurred since its configuration), on the 
other hand, acquiring a new IP prefix from the network may take some time (due 
to signaling exchange with the network) and may fail due to network policies.


Cheers,
Lorenzo

On Tue, Dec 6, 2016 at 9:27 PM, Moses, Danny 
<danny.mo...@intel.com<mailto:danny.mo...@intel.com>> wrote:
Firstly, I agree that the only two examples of ‘resource’ type that may result 
with a creation of a source IP address are (i) an IP address and (ii) an IP 
prefix. I cannot think of any other magic, but perhaps some else can…

I am trying to avoid the term ‘prefix’ because it is not directly related to 
the Socket interface and I am trying to separate the definitions related to the 
Socket interface from the definitions related to the interaction between the MN 
and network.

If I mention prefixes, I will have to explain that the network may allocate IP 
addresses or IP sockets and that in cellular networks the recommended mechanism 
is to allocate /64 prefixes… I do not want to get into these details because 
they are not helpful for Socket API users.

However, I do intend to get into these details (and refer to the recommendation 
of RFC 7934) in the drafts that describe the extensions required to convey the 
IP service type between the IP stack in the MN and the network.

From: Lorenzo Colitti [mailto:lore...@google.com<mailto:lore...@google.com>]
Sent: Tuesday, December 06, 2016 13:43
To: Moses, Danny <danny.mo...@intel.com<mailto:danny.mo...@intel.com>>
Cc: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>; 
jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

On Mon, Dec 5, 2016 at 9:50 AM, Moses, Danny 
<danny.mo...@intel.com<mailto:danny.mo...@intel.com>> wrote:
I think it is important to describe that application developer can influence 
the type of service the IP session is receiving, while being vague about the 
mechanism of address allocation. Since you are concern with the draft using the 
term ‘address’ and I am concern with using the term ‘prefix’, I tried

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

[Moses, Danny]

Well, although the network allocates prefixes it could keep track of addresses 
that were constructed from those prefixes and initiate NUD on these addresses…

Personally, I don’t believe in designs that rely on MNs to volunteer to provide 
such information. The better approach is to have a finite lease time for 
prefixes (like DHCP does) and force the MN to request lease extensions – if 
they required.

Could that be a reasonable approach?

Danny

From: Peter McCann [mailto:peter.mcc...@huawei.com]
Sent: Monday, December 05, 2016 21:02
To: Moses, Danny <danny.mo...@intel.com>; Lorenzo Colitti <lore...@google.com>
Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
Subject: RE: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

In the prefixcost draft, we handwaved a solution that would keep soft state in 
the network and have the network initiate NUD when it hadn’t seen a given 
address being used by the MN for a while.  However, NUD only works on 
individual addresses not whole prefixes.  It might be good to have an explicit 
message from a MN that says “I am done using this prefix” but this problem is 
bigger than DMM.  I am not sure what is the right solution.

-Pete


From: Moses, Danny [mailto:danny.mo...@intel.com]
Sent: Monday, December 05, 2016 1:01 PM
To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>; 
Lorenzo Colitti <lore...@google.com<mailto:lore...@google.com>>
Cc: 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: RE: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

That is correct.

Do we need a draft about freeing addresses/prefixes?

Regards,
Danny

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Peter McCann
Sent: Monday, December 05, 2016 17:43
To: Lorenzo Colitti <lore...@google.com<mailto:lore...@google.com>>
Cc: 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

That may work for communicating the allocation state of the prefix to the MN, 
but too frequent advertisements may chew up precious wireless bandwidth.  Also, 
it doesn’t solve the problem of allowing the network to detect when the MN is 
done using the prefix.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Sunday, December 04, 2016 9:21 PM
To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>
Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

Agreed; if we want to support this sort of mobility it needs to be possible to 
tell a MN that its previous prefix is no longer valid.

From a technical perspective this can be done using router advertisements, 
except for the 2-hour rule in RFC 4862 section 5.3.3. That rule exists to 
prevent DOS attacks on shared links, so I think it would be reasonable to 
update RFC 4862 to say that less-than-2-hour valid lifetimes are acceptable if 
the link provides strong guarantees that there are no other nodes on link that 
can mount such an attack.

On Fri, Dec 2, 2016 at 12:36 PM, Peter McCann 
<peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote:
Agree, I am not arguing in favor of sharing a prefix between two or more MNs at 
the same time.  However, I think it is important to reclaim a prefix for use by 
another MN after the current MN has moved to a new attachment point and stopped 
using the prefix it got from the old attachment point.   It is also important 
to refrain from advertising the prefix to another MN until the current MN has 
stopped using it.  That is the network state I am talking about.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com<mailto:lore...@google.com>]
Sent: Friday, December 02, 2016 3:32 PM

To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>
Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

On the particular case of shared links: note that they have substantial 
scalability and performance issues. In order for shared links to work you have 
to engage in DAD proxying, ND snooping, client isolation and all sorts of 
unsavoury and L2/L3 magic that does not scale. Some of these issues are 
described in RFC 7934 section 9.3. On shared links, these forces act to reduce 
the number of IP addresses per host that the network can support a

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

[Moses, Danny]

That is correct.

Do we need a draft about freeing addresses/prefixes?

Regards,
Danny

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Peter McCann
Sent: Monday, December 05, 2016 17:43
To: Lorenzo Colitti 
Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

That may work for communicating the allocation state of the prefix to the MN, 
but too frequent advertisements may chew up precious wireless bandwidth.  Also, 
it doesn’t solve the problem of allowing the network to detect when the MN is 
done using the prefix.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Sunday, December 04, 2016 9:21 PM
To: Peter McCann >
Cc: jouni.nospam >; 
draft-ietf-dmm-ondemand-mobil...@ietf.org;
 dmm@ietf.org
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

Agreed; if we want to support this sort of mobility it needs to be possible to 
tell a MN that its previous prefix is no longer valid.

From a technical perspective this can be done using router advertisements, 
except for the 2-hour rule in RFC 4862 section 5.3.3. That rule exists to 
prevent DOS attacks on shared links, so I think it would be reasonable to 
update RFC 4862 to say that less-than-2-hour valid lifetimes are acceptable if 
the link provides strong guarantees that there are no other nodes on link that 
can mount such an attack.

On Fri, Dec 2, 2016 at 12:36 PM, Peter McCann 
> wrote:
Agree, I am not arguing in favor of sharing a prefix between two or more MNs at 
the same time.  However, I think it is important to reclaim a prefix for use by 
another MN after the current MN has moved to a new attachment point and stopped 
using the prefix it got from the old attachment point.   It is also important 
to refrain from advertising the prefix to another MN until the current MN has 
stopped using it.  That is the network state I am talking about.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Friday, December 02, 2016 3:32 PM

To: Peter McCann >
Cc: jouni.nospam >; 
draft-ietf-dmm-ondemand-mobil...@ietf.org;
 dmm@ietf.org
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

On the particular case of shared links: note that they have substantial 
scalability and performance issues. In order for shared links to work you have 
to engage in DAD proxying, ND snooping, client isolation and all sorts of 
unsavoury and L2/L3 magic that does not scale. Some of these issues are 
described in RFC 7934 section 9.3. On shared links, these forces act to reduce 
the number of IP addresses per host that the network can support and leads to 
the negative consequences in section 4 of the document, which is why they are 
not recommended.

For these and other reasons, on many public networks we're seeing a shift 
*away* from shared links - see, for example, 
draft-ietf-v6ops-unique-ipv6-prefix-per-host , and the current large 
deployments of that model in the form of Comcast community wifi.

For many years 3GPP networks have been providing those benefits by providing a 
full /64 to every host. I would hate to lose those benefits.

On Fri, Dec 2, 2016 at 12:12 PM, Peter McCann 
> wrote:
With a fixed access network the prefix can be assigned to the link and used by 
anyone who joins the link.

With a prefix offering mobility the prefix belongs to the mobile host and needs 
to move with it.  There aren’t enough prefixes (even in IPv6) to assign a 
permanent prefix to each UE for every topological attachment point that it 
might visit or start a session from.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Friday, December 02, 2016 3:09 PM
To: Peter McCann >
Cc: jouni.nospam >; 
draft-ietf-dmm-ondemand-mobil...@ietf.org;
 dmm@ietf.org

Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

But you have that problem with IP addresses as well, right? I don't see how 
"assigning a prefix with certain properties" requires more state in the network 
than "assigning an IP address with certain properties".

On Fri, Dec 2, 2016 at 12:00 PM, Peter McCann 
> wrote:
Providing any kind of mobility service for a prefix will require some state 
somewhere in the 

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

[Moses, Danny]

Hi Lorenzo,

The intent of this draft is to focus on the Socket API extensions and the 
interaction between applications and the IP stack running on the mobile host. 
Not to describe the interactions between the IP stack and the network.

My understanding is that as long as the draft maintains the above, your 
concerns should be satisfied.

I reviewed the draft once more and found (in addition to some typos which I’ll 
fix) a couple of places in section 3.4 – Conveying the Selection – that need to 
be modified in order to satisfy your concerns:


1. The paragraph before the definition of the IPV6_REQUIRE_SRC_ON_NET flag:
‘When the IP stack in required to assign a source IP address of a specified 
type, it can perform one of the following: It can assign a preconfigured 
address (if one exists) or request a new one from the network. Using an 
existing address is instantaneous but might yield a less optimal route (if a 
hand-off event occurs since its configuration), on the other hand, acquiring a 
new IP address from the network may take some time (due to signaling exchange 
with the network).’

I propose the following modifications:

i. Replace ‘… or request a new one from the 
network…’ to ‘… or configure a new one using new resources from the network…’

  ii. Replace ‘… acquiring a new IP address 
from the network may…’ with ‘… configuring a new one using new network 
resources may…’

The modified paragraph will be:

‘When the IP stack is required to assign a source IP address of a specific 
type, it can perform one of the following: It can assign a preconfigured 
address (if one exists) or configure a new one using new resources from the 
network. Using an existing address is instantaneous but might yield a less 
optimal route (if a hand-off event occurred since its configuration), on the 
other hand, configuring a new one using new network resources may take some 
time (due to signaling exchange with the network).’



2. The paragraph following the definition of the IPV6_REQUIRE_SRC_ON_NET:

‘If set, the IP stack will request a new IP address of the desired type from 
the current serving network…’

I propose the modify this to:

‘If set, the IP stack will request new resources from the network in order to 
configure a new IP address with the desired service type…’

Please also notice the disclaimer in section 3.3 – Granularity of Selection – 
that says:
‘It is outside the scope of this specification to define how the host requests 
a specific type of address (Fixed, Session-lasting or Non-persistent) and how 
the network indicates the type of address in its advertisement of addresses (or 
in its reply to an address request).’

I can modify that to ‘… type of address/prefix…’ but I prefer not to, since 
this draft focuses on Socket APIs (which deal with addresses – not prefixes). I 
hope you can accept this.

Do the above modifications fully address your concerns?

Thanks,

Danny


From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Monday, December 05, 2016 03:57
To: Moses, Danny <danny.mo...@intel.com>
Cc: Peter McCann <peter.mcc...@huawei.com>; jouni.nospam 
<jouni.nos...@gmail.com>; draft-ietf-dmm-ondemand-mobil...@ietf.org; 
dmm@ietf.org
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

Danny,

yes, there are two documents, but draft-ietf-dmm-ondemand-mobility is the one I 
am objecting to at the moment.

The reason is that it describes a practice where the application gets an IPv6 
address by issuing a request to the network, and RFC 7934 explicitly recommends 
against that. It doesn't matter whether the IPv6 address is requested and 
granted via DHCPv6, PCO options, HTTP requests, or smoke signals - the key 
point is that per RFC 7934, the network should not be handing out individual 
IPv6 addresses based on explicit requests by the host.

The best example of that practice is this text:

   In case an application
   requests one, the IP stack shall make an attempt to configure one by
   issuing a request to the network.  If the operation fails, the IP
   stack shall fail the associated socket request

but there are likely other examples elsewhere in the draft.

I would suggest rewording that text to say that the MN should pick an IP 
address out of a (/64 or shorter) prefix that has the desired properties. If 
there is not already a prefix assigned to it that has the desired properties, 
then it should request a prefix with the desired properties.

I agree that we do not need application developers to think in terms of 
prefixes, but we do need network protocol designers and implementers, and OS 
implementers, to design and implement the request machinery using prefixes and 
not individual IPv6 addresses.

Cheers,
Lorenzo

On Sun, Dec 4, 2016 at 1:13 AM, Moses, Danny 
<danny.mo...@intel.com<mailto:danny.mo...@intel.com>> wrote:
Hi guys,

I hope there isn’t a confusi

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

[Moses, Danny]

Hi guys,

I hope there isn’t a confusion between draft-ietf-ondemand-mobility and 
draft-moses-dmm-dhcp-ondemand-mobility.


·Draft-ietf-ondemand-mobility defines the ability of the network to 
provide different types of session continuity services and extends the Socket 
interface to enable application to influence the service they require for the 
newly established IP session. It does not specify how the session continuity 
requirements are conveyed to/from the network.


·Draft-moses-dmm-dhcp-ondemand-mobility is the draft that defines 
extensions to DHCPv6 in order to convey session-continuity service type to the 
network.

Lorenzo,
I the last F2F in Seoul, you expressed your concerns that the proposed DHCP 
extensions to enabling the specification of the service type in IP address 
requests, contradict the recommendations specified in RFC 7934. As I mentioned 
in the discussion, I am committed to fix the wording in that draft to resolve 
that contradiction.

But draft-ietf-ondemand-mobility discusses extensions to the Socket interface. 
Sockets are used by application developers to initiated IP sessions. I do not 
think application developers should be networking experts and should be aware 
of what is being allocated by cellular networks to mobile hosts (or UEs, in the 
3GPP jargon…). This draft does not indicate that each invocation of a socket 
API to initiation an IP session, results in a request to the network. It does 
not get into these resolutions intentionally. We are separating the description 
of what an application does, to what the mobile host’s IP stack does.

Therefore, I do not think we should confuse application writers with IP 
prefixes. All they need to know is how to influence the service that are 
getting, like their ability to choose between a reliable transport (TCP) or 
unreliable one (UDP).

I hope you agree with this separation.

Thanks and regards,
Danny

From: Peter McCann [mailto:peter.mcc...@huawei.com]
Sent: Friday, December 02, 2016 22:37
To: Lorenzo Colitti 
Cc: jouni.nospam ; 
draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
Subject: RE: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

Agree, I am not arguing in favor of sharing a prefix between two or more MNs at 
the same time.  However, I think it is important to reclaim a prefix for use by 
another MN after the current MN has moved to a new attachment point and stopped 
using the prefix it got from the old attachment point.   It is also important 
to refrain from advertising the prefix to another MN until the current MN has 
stopped using it.  That is the network state I am talking about.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Friday, December 02, 2016 3:32 PM
To: Peter McCann >
Cc: jouni.nospam >; 
draft-ietf-dmm-ondemand-mobil...@ietf.org;
 dmm@ietf.org
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

On the particular case of shared links: note that they have substantial 
scalability and performance issues. In order for shared links to work you have 
to engage in DAD proxying, ND snooping, client isolation and all sorts of 
unsavoury and L2/L3 magic that does not scale. Some of these issues are 
described in RFC 7934 section 9.3. On shared links, these forces act to reduce 
the number of IP addresses per host that the network can support and leads to 
the negative consequences in section 4 of the document, which is why they are 
not recommended.

For these and other reasons, on many public networks we're seeing a shift 
*away* from shared links - see, for example, 
draft-ietf-v6ops-unique-ipv6-prefix-per-host , and the current large 
deployments of that model in the form of Comcast community wifi.

For many years 3GPP networks have been providing those benefits by providing a 
full /64 to every host. I would hate to lose those benefits.

On Fri, Dec 2, 2016 at 12:12 PM, Peter McCann 
> wrote:
With a fixed access network the prefix can be assigned to the link and used by 
anyone who joins the link.

With a prefix offering mobility the prefix belongs to the mobile host and needs 
to move with it.  There aren’t enough prefixes (even in IPv6) to assign a 
permanent prefix to each UE for every topological attachment point that it 
might visit or start a session from.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Friday, December 02, 2016 3:09 PM
To: Peter McCann >
Cc: jouni.nospam >; 
draft-ietf-dmm-ondemand-mobil...@ietf.org;
 dmm@ietf.org

Subject: 

Re: [DMM] 答复: WGLC #1 for draft-ietf-dmm-distributed-mobility-anchoring-02

[Moses, Danny]

+1.

I have one comment/concern however: In section 3.1, there is a reference to 
I-D.ietf-dmm-deployment-models and to I-D.sijeon-dmm-deployment-models.
I don't think it is reasonable thT DMM should have two drafts describing 
deployment models and expect these drafts to be merged at some point of time 
(especially as some authors share these drafts). I would like to propose that 
the DMM WG will direct the authors to merge these drafts and that 
draft-ietf-dmm-distributed-mobility-anchoring will refer to the merged draft.

Thanks,
Danny 

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Weianni
Sent: Friday, December 02, 2016 04:22
To: jouni.nospam ; dmm@ietf.org
Cc: "刘大鹏(鹏成)" 
Subject: [DMM] 答复: WGLC #1 for draft-ietf-dmm-distributed-mobility-anchoring-02

I think this document has been well prepared, and support it.


BRs,
Anni
-邮件原件-
发件人: dmm [mailto:dmm-boun...@ietf.org] 代表 jouni.nospam
发送时间: 2016年11月14日 15:27
收件人: dmm@ietf.org
抄送: "刘大鹏(鹏成)"
主题: [DMM] WGLC #1 for draft-ietf-dmm-distributed-mobility-anchoring-02

Folks,

This mail starts 3 weeks WGLC #1 for 
draft-ietf-dmm-distributed-mobility-anchoring-03. The WGLC ends 12/4/2016 EOB 
pacific time. Express you support and concerns on the email list. We really 
need reviews on this document. If you have comments, please, use Issue Tracker 
to document those also in addition to sending them into the email list.

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
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Slides for the DHCPv6 extensions item

[Moses, Danny]

Hi Jouni and Dapeng,

Attached the presentation for the DHCPv6 extensions item in the DMM session.

Regards,
Danny
-
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.


Extensions to DHCP for OnDemand Mobility Support.pptx
Description: Extensions to DHCP for OnDemand Mobility Support.pptx
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] DMM agenda requests

[Moses, Danny]

Hi,

I would like a 5 minute slot to mention the last update on the 
draft-moses-dmm-dhcp-ondemand-mobility-04 I-D and ask for adoption.

Thanks,
Danny

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of jouni.nospam
Sent: Tuesday, October 25, 2016 07:49
To: dmm@ietf.org
Subject: Re: [DMM] DMM agenda requests

A friendly reminder. The agenda requests are due this Friday.

Jouni & Dapeng


> On Oct 12, 2016, at 1:07 PM, jouni.nospam  wrote:
> 
> Folks,
> 
> IETF 97 is getting closer and it is time to start the agenda planning.
> 
> Please, send the chairs your request for agenda time. As usual, include short 
> abstract, draft name, and time requested. Obviously, existing WG items will 
> have precedence. Individual items will be treated in fifo order.
> 
> As a reminder the state of play is:
> 
> Waiting for Proto Write-UP:
> * draft-ietf-dmm-4283mnids-02 
> * draft-ietf-dmm-hnprenum-03 
> * draft-ietf-dmm-lma-controlled-mag-params-02
> * draft-ietf-dmm-ondemand-mobility-07
> 
> In WG:
> * draft-ietf-dmm-deployment-models-00 
> * draft-ietf-dmm-distributed-mobility-anchoring-02 
> * draft-ietf-dmm-fpc-cpdp-04 
> 
> In WGLC:
> * draft-ietf-dmm-mag-multihoming-02 
> 
> Candidate for adoption:
> * draft-korhonen-netext-rfc5149bis-02 
> 
> 
> 
> - Jouni & Dapeng

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] New version of draft-moses-dhcp-ondemand-mobility

[Moses, Danny]

Hi all,

Several days ago I uploaded a new version of 
draft-moses-dhcp-ondemand-mobility. This version includes a fix to the 
IP-Prefix definition according to rfc7227 as directed by Suresh, and some other 
editorial changes including the new definition for the three IP-continuity 
services as defined in the draft-ietf-dmm-ondemand-mobility draft: Fixed, 
Session-lasting and Non-persistent.

I think that this draft is ready for WG adoption. Please review and comment.

Thanks,

Danny

-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] The DMM WG has placed draft-wt-dmm-deployment-models in state "Candidate for WG Adoption"

[Moses, Danny]

I support the WG adoption of this draft.

Danny

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of IETF Secretariat
Sent: Sunday, July 24, 2016 07:12
To: draft-wt-dmm-deployment-mod...@ietf.org; dmm-cha...@ietf.org; dmm@ietf.org
Subject: [DMM] The DMM WG has placed draft-wt-dmm-deployment-models in state 
"Candidate for WG Adoption"


The DMM WG has placed draft-wt-dmm-deployment-models in state Candidate for WG 
Adoption (entered by Jouni Korhonen)

The document is available at
https://datatracker.ietf.org/doc/draft-wt-dmm-deployment-models/


Comment:
As per IETF96 WG session there was strong support to adopt this document as a 
WG Item.

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] The DMM WG has placed draft-chan-dmm-distributed-mobility-anchoring in state "Candidate for WG Adoption"

[Moses, Danny]

I support the WG adoption if this draft.

Danny

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of IETF Secretariat
Sent: Sunday, July 24, 2016 07:12
To: dmm-cha...@ietf.org; 
draft-chan-dmm-distributed-mobility-anchor...@ietf.org; dmm@ietf.org
Subject: [DMM] The DMM WG has placed 
draft-chan-dmm-distributed-mobility-anchoring in state "Candidate for WG 
Adoption"


The DMM WG has placed draft-chan-dmm-distributed-mobility-anchoring in state 
Candidate for WG Adoption (entered by Jouni Korhonen)

The document is available at
https://datatracker.ietf.org/doc/draft-chan-dmm-distributed-mobility-anchoring/


Comment:
As per IETF96 WG session there was strong support to adopt this document as a 
WG Item.

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WGLC #1 for draft-ietf-dmm-mag-multihoming-01

[Moses, Danny]

I support version 02.
Danny

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni
Sent: Sunday, July 24, 2016 07:09
To: dmm@ietf.org; draft-ietf-dmm-mag-multihom...@ietf.org
Cc: "刘大鹏(鹏成)"
Subject: [DMM] WGLC #1 for draft-ietf-dmm-mag-multihoming-01

Folks,

As said during the WG meeting we’ll start the WGLC#1 for 
draft-ietf-dmm-mag-multihoming-01.

The WGLC starts:  7/23/2016
   ends:  8/7/2016

Please send your review comments, concerns and support to the list. Please, 
also make use of the Issue Tracker so that tracking down comments and their 
resolutions become easier.

Thanks,
Dapeng & Jouni


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] New version of the OnDemand Mobility draft

[Moses, Danny]

Hi Alex,

Thanks for the support.
I will issue a new version shortly.

Regards,
/Danny

-Original Message-
From: Alexandre Petrescu [mailto:alexandre.petre...@gmail.com] 
Sent: Tuesday, July 05, 2016 17:49
To: Moses, Danny
Cc: dmm@ietf.org; jouni.nos...@gmail.com; Seil Jeon
Subject: Re: [DMM] New version of the OnDemand Mobility draft

Hi Danny,

Le 03/07/2016 à 16:03, Moses, Danny a écrit :
> Hi Alex,
>
>
>
> From the standard point of view, IPv6 indeed provides two alternatives:
> Stateless and Stateful address assignment, and the text in the draft 
> does not mention this and might even be misleading to assume that the 
> network always assigns the source IP address - so I agree with your comment.
>
>
>
> The reason for that is that this draft is meant for application 
> developers who need to understand how they can influence the network 
> behavior through address type request. For them, the exact mechanism 
> of address assignment is a detail which might be confusing. Our 
> thinking was, that even in the stateless case the generated source IP 
> address comprises a network prefix that was assigned by some entity in 
> the network. So the text is still true for the Stateless case.
>
>
>
> If you still think that this is too misleading, I propose the 
> following
> change:
>
> 1.   Remove the text - 'assigned to the mobile host by the network'
> in the definition of both the Fixed IP address and Session-lasting IP 
> address.
>
> 2.   Add a comment indicating that the IP address may either be
> assigned to the mobile host by the network (Stateful address 
> assignment) or generated by the host using a Prefix that was assigned 
> by the network
> (stateless)
>
>
>
> As a result, the text in this section will become (new text in red):
>
>
>
>
>
>Three types of IP addresses are defined with respect to the mobility
>management.
>
>- Fixed IP Address
>
>A Fixed IP address is an address assigned to the mobile host by the
>network with a guarantee to be valid for a very long time, regardless
>of whether it is being used in any packets to/from the mobile host,
>or whether or not the mobile host is connected to the network, or
>whether it moves from one point-of-attachment to another (with a
>different subnet or IP prefix) while it is connected.
>
>Fixed IP address are required by applications that need both IP
>session continuity and IP address reachability.
>
>- Session-lasting IP Address
>
>A session-lasting IP address is an address assigned to the mobile
>host by the network with a guarantee to be valid through-out the IP
>session(s) for which it was requested.  It is guaranteed to be valid
>even after the mobile host had moved from one point-of-attachment to
>another (with a different subnet or IP prefix).
>
>Session-lasting IP addresses are required by applications that need
>IP session continuity but do not need IP address reachability.
>
>- Non-persistent IP Address
>
>This type of IP address provides neither IP session continuity nor IP
>address reachability.  The IP address is obtained from the serving IP
>gateway and it is not maintained across gateway changes.  In other
>words, the IP address may be released and replaced by a new IP address
>when the IP gateway changes due to the movement of the mobile host.
>
>Applications running as servers at a published IP address require a
>Fixed IP Address.  Long-standing applications (e.g., an SSH session)
>may also require this type of address.  Enterprise applications that
>connect to an enterprise network via virtual LAN require a Fixed IP
>Address.
>
>Applications with short-lived transient IP sessions can use Session-
>lasting IP Addresses.  For example: Web browsers.
>
>Applications with very short IP sessions, such as DNS client and
>instant messengers, can utilize Non-persistent IP Addresses.  Even
>though they could very well use a Fixed of Session-lasting IP
>Addresses, the transmission latency would be minimized when a Non-
>persistent IP Address is used.
>
>
>
>The network creates the desired guarantee (Fixed, Session-lasting 
> or
>
>Non-persistent) by either assigning an address (as part of a 
> stateful
>
>address generation), or by assigning the address prefix (as part of 
> a
>
>stateless address generation).
>
>
>
> Does this change addresses your concerns?

Yes, this change addresses my concerns.

Alex

>
>
>
> Thanks,
>
> /Danny
>
>
>
>
>
> -Original Message-
> From:

Re: [DMM] New version of the OnDemand Mobility draft

[Moses, Danny]

Hi Alex,



>From the standard point of view, IPv6 indeed provides two alternatives: 
>Stateless and Stateful address assignment, and the text in the draft does not 
>mention this and might even be misleading to assume that the network always 
>assigns the source IP address - so I agree with your comment.



The reason for that is that this draft is meant for application developers who 
need to understand how they can influence the network behavior through address 
type request. For them, the exact mechanism of address assignment is a detail 
which might be confusing. Our thinking was, that even in the stateless case the 
generated source IP address comprises a network prefix that was assigned by 
some entity in the network. So the text is still true for the Stateless case.



If you still think that this is too misleading, I propose the following change:

1.   Remove the text - 'assigned to the mobile host by the network' in the 
definition of both the Fixed IP address and Session-lasting IP address.

2.   Add a comment indicating that the IP address may either be assigned to 
the mobile host by the network (Stateful address assignment) or generated by 
the host using a Prefix that was assigned by the network (stateless)



As a result, the text in this section will become (new text in red):





   Three types of IP addresses are defined with respect to the mobility
   management.

   - Fixed IP Address

   A Fixed IP address is an address assigned to the mobile host by the
   network with a guarantee to be valid for a very long time, regardless
   of whether it is being used in any packets to/from the mobile host,
   or whether or not the mobile host is connected to the network, or
   whether it moves from one point-of-attachment to another (with a
   different subnet or IP prefix) while it is connected.

   Fixed IP address are required by applications that need both IP
   session continuity and IP address reachability.

   - Session-lasting IP Address

   A session-lasting IP address is an address assigned to the mobile
   host by the network with a guarantee to be valid through-out the IP
   session(s) for which it was requested.  It is guaranteed to be valid
   even after the mobile host had moved from one point-of-attachment to
   another (with a different subnet or IP prefix).

   Session-lasting IP addresses are required by applications that need
   IP session continuity but do not need IP address reachability.

   - Non-persistent IP Address

   This type of IP address provides neither IP session continuity nor IP
   address reachability.  The IP address is obtained from the serving IP
   gateway and it is not maintained across gateway changes.  In other
   words, the IP address may be released and replaced by a new IP address
   when the IP gateway changes due to the movement of the mobile host.

   Applications running as servers at a published IP address require a
   Fixed IP Address.  Long-standing applications (e.g., an SSH session)
   may also require this type of address.  Enterprise applications that
   connect to an enterprise network via virtual LAN require a Fixed IP
   Address.

   Applications with short-lived transient IP sessions can use Session-
   lasting IP Addresses.  For example: Web browsers.

   Applications with very short IP sessions, such as DNS client and
   instant messengers, can utilize Non-persistent IP Addresses.  Even
   though they could very well use a Fixed of Session-lasting IP
   Addresses, the transmission latency would be minimized when a Non-
   persistent IP Address is used.



   The network creates the desired guarantee (Fixed, Session-lasting or

   Non-persistent) by either assigning an address (as part of a stateful

   address generation), or by assigning the address prefix (as part of a

   stateless address generation).



Does this change addresses your concerns?



Thanks,

/Danny





-Original Message-
From: Alexandre Petrescu [mailto:alexandre.petre...@gmail.com]
Sent: Friday, July 01, 2016 09:41
To: jouni.nos...@gmail.com; Seil Jeon
Cc: Moses, Danny; dmm@ietf.org
Subject: Re: [DMM] New version of the OnDemand Mobility draft



My concern is partially addressed, yes.



There is still this text which can be improved:

>- Session-lasting IP Address

>

>A session-lasting IP address is an address assigned to the mobile

>host by the network [...]



A session-lasting IP address is an address formed in conjunction by the host 
and the network (SLAAC), or assigned by the network (DHCP) [...]



A session-lasting IP prefix is a prefix advertised to the mobile host by the 
network [...]



Alex





Le 30/06/2016 à 19:05, Jouni Korhonen a écrit :

> Seil, Alex,

>

> Have your concerns been addressed in the -06 revision?

>

> - Jouni

>

> 6/30/2016, 2:20 AM, Moses, Danny kirjoitti:

>>

>> Hi,

>>

>> I have posted a new version of t

Re: [DMM] IETF96 meeting - call for agenda items; was RE: IETF96 meeting - first call for agenda items

[Moses, Danny]

Hi,

I would like a 10 minute slot to give an update on the OnDemand effort.

Thanks,
/Danny

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Korhonen
Sent: Monday, June 27, 2016 17:47
To: dmm@ietf.org
Cc: 成 鹏
Subject: [DMM] IETF96 meeting - call for agenda items; was RE: IETF96 meeting - 
first call for agenda items

Kind reminder..

- Jouni & Dapeng

6/8/2016, 3:29 PM, Jouni Korhonen kirjoitti:
>
> Folks,
>
> IETF96 is approaching.. in order to build an agenda with appropriate 
> time allocation we would like to collect the agenda requests as soon 
> as possible.
>
> Working group I-Ds have a priority but won't be granted a slot unless 
> asked by the authors explicitly. DMM topics will have priority over 
> MIP maintenance topics.
>
> Name your I-D, requested time and if this is about a new work state 
> also the reasoning why it deserves meeting time.
>
> Please, avoid requesting slots for I-Ds with just a "trivial"
> incremental update to the previous version. People should be able to 
> do a diff themselves.
>
> - Jouni & Dapeng

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

[Moses, Danny]

Isn't the text clear enough without this addition.
Let me think about this a little more.

Thanks,
/Danny

From: Seil Jeon [mailto:seilj...@gmail.com]
Sent: Sunday, June 26, 2016 11:21
To: Moses, Danny
Cc: dmm@ietf.org
Subject: RE: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi Danny,

It aims to clarify what order the IP stack should follow among the cases; when 
an application does/doesn’t specify its requested type.

Regards,
Seil Jeon

From: Moses, Danny [mailto:danny.mo...@intel.com]
Sent: Sunday, June 26, 2016 4:44 PM
To: Seil Jeon
Cc: dmm@ietf.org<mailto:dmm@ietf.org>
Subject: RE: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi Seil,

Thanks for the correction.
The only fix I did not understand is the addition of 'by priority'. The rest of 
the fixes are fine.

I will wait a couple of days to let additional people respond, and release a 
new version towards the end of this week.

/Danny

From: Seil Jeon [mailto:seilj...@gmail.com]
Sent: Thursday, June 23, 2016 13:33
To: Moses, Danny
Cc: dmm@ietf.org<mailto:dmm@ietf.org>
Subject: RE: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi Danny,

Thanks for your revision. I mostly agree with your texts. But I put my small 
revision on your texts.
For the last sentence, I hope we leave some spaces for any enhancement.

If the network infrastructure supports On-Demand Mobility feature,
the IP stack should act according to follow the application request by 
priority; If the  application requests a specific address type, the stack 
should forward  this request to the network. If the application does not 
request a specific  address type, the IP stack must not request an address type 
and leave  it to the network's default behavior to choose the type of the 
allocated  IP address. If an IP address was already allocated to the host, the 
IP stack should uses this address and may not request a new ine one from the 
network.

Regards,
Seil Jeon

From: Moses, Danny [mailto:danny.mo...@intel.com]
Sent: Thursday, June 23, 2016 7:06 PM
To: Seil Jeon; dmm@ietf.org<mailto:dmm@ietf.org>
Cc: '"???(??)"'
Subject: RE: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi,

Thanks for the support.

I agree with your comment; the text might be misleading.
The general principle is to maintain the old behavior (prior to OnDemand 
support) when one entity is  legacy. According to this principle, if a legacy 
application is executed, it should experience the same behavior as if it would 
have been executed with a legacy IP stack and legacy network. The problem is 
however, that the behavior of the network in terms of IP address type 
allocation is not define.

So I am thinking of changing the text from �C
"New IP stacks must continue to support all legacy operations. If an
application does not use On-Demand Mobility feature, the IP stack
must respond in a legacy manner.

If the network infrastructure supports On-Demand Mobility feature,
the IP stack may still request specific types of source IP address
transparently to legacy applications. This may be useful for
environments in which both legacy and new applications are executed.

The definition of what type of addresses to request and how they are
assigned to legacy applications are outside of the scope of this
specification."

To (the red text is new, the strikethrough text will be deleted)�C
" New IP stacks must continue to support all legacy operations. If an
application does not use On-Demand Mobility feature, the IP stack
must respond in a legacy manner.

If the network infrastructure supports On-Demand Mobility feature,
the IP stack should act according to the application request: If the
application requests a specific address type, the stack should forward
this request to the network. If the application does not request a specific
address type, the IP stack must not request an address type and leave
it to the network's default behavior to choose the type of the allocated
IP address. If an address was already allocated to the host, the IP stack
should use this address and not request a new one from the network.
may still request specific types of source IP address
transparently to legacy applications. This may be useful for
environments in which both legacy and new applications are executed.

The definition of what type of addresses to request and how they are
assigned to legacy applications are outside of the scope of this
specification."

Is that OK?

Thanks,
/Danny

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Seil Jeon
Sent: Tuesday, June 21, 2016 12:52
To: dmm@ietf.org<mailto:dmm@ietf.org>
Cc: '"刘大鹏(鹏成)"'
Subject: Re: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi,

I have read and checked the updates in -03 version.
And I support this draft to move forward, if the following is clearly resolved.


"4.2. IP Stack in th

Re: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

[Moses, Danny]

Hi Seil,

Thanks for the correction.
The only fix I did not understand is the addition of 'by priority'. The rest of 
the fixes are fine.

I will wait a couple of days to let additional people respond, and release a 
new version towards the end of this week.

/Danny

From: Seil Jeon [mailto:seilj...@gmail.com]
Sent: Thursday, June 23, 2016 13:33
To: Moses, Danny
Cc: dmm@ietf.org
Subject: RE: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi Danny,

Thanks for your revision. I mostly agree with your texts. But I put my small 
revision on your texts.
For the last sentence, I hope we leave some spaces for any enhancement.

If the network infrastructure supports On-Demand Mobility feature,
the IP stack should act according to follow the application request by 
priority; If the  application requests a specific address type, the stack 
should forward  this request to the network. If the application does not 
request a specific  address type, the IP stack must not request an address type 
and leave  it to the network's default behavior to choose the type of the 
allocated  IP address. If an IP address was already allocated to the host, the 
IP stack should uses this address and may not request a new ine one from the 
network.

Regards,
Seil Jeon

From: Moses, Danny [mailto:danny.mo...@intel.com]
Sent: Thursday, June 23, 2016 7:06 PM
To: Seil Jeon; dmm@ietf.org<mailto:dmm@ietf.org>
Cc: '"???(??)"'
Subject: RE: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi,

Thanks for the support.

I agree with your comment; the text might be misleading.
The general principle is to maintain the old behavior (prior to OnDemand 
support) when one entity is  legacy. According to this principle, if a legacy 
application is executed, it should experience the same behavior as if it would 
have been executed with a legacy IP stack and legacy network. The problem is 
however, that the behavior of the network in terms of IP address type 
allocation is not define.

So I am thinking of changing the text from �C
"New IP stacks must continue to support all legacy operations. If an
application does not use On-Demand Mobility feature, the IP stack
must respond in a legacy manner.

If the network infrastructure supports On-Demand Mobility feature,
the IP stack may still request specific types of source IP address
transparently to legacy applications. This may be useful for
environments in which both legacy and new applications are executed.

The definition of what type of addresses to request and how they are
assigned to legacy applications are outside of the scope of this
specification."

To (the red text is new, the strikethrough text will be deleted)�C
" New IP stacks must continue to support all legacy operations. If an
application does not use On-Demand Mobility feature, the IP stack
must respond in a legacy manner.

If the network infrastructure supports On-Demand Mobility feature,
the IP stack should act according to the application request: If the
application requests a specific address type, the stack should forward
this request to the network. If the application does not request a specific
address type, the IP stack must not request an address type and leave
it to the network's default behavior to choose the type of the allocated
IP address. If an address was already allocated to the host, the IP stack
should use this address and not request a new one from the network.
may still request specific types of source IP address
transparently to legacy applications. This may be useful for
environments in which both legacy and new applications are executed.

The definition of what type of addresses to request and how they are
assigned to legacy applications are outside of the scope of this
specification."

Is that OK?

Thanks,
/Danny

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Seil Jeon
Sent: Tuesday, June 21, 2016 12:52
To: dmm@ietf.org<mailto:dmm@ietf.org>
Cc: '"刘大鹏(鹏成)"'
Subject: Re: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi,

I have read and checked the updates in -03 version.
And I support this draft to move forward, if the following is clearly resolved.


"4.2. IP Stack in the Mobile Host

...


If the network infrastructure supports On-Demand Mobility feature, the IP stack 
may still request specific types of source IP address  transparently to legacy 
applications."


As this draft is based on the application-driven API selection idea, if no 
explicit request is given by an application, the type should be selected by 
default, though the default behavior could be regulated by the network 
operator. My comment is putting "based on a default havior" in a proper place 
in the sentence would be exact, leaving no misunderstanding as if the IP stack 
has the selection capability of source IP address type, instead of the 
application.

One minor comment is [I-

Re: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

[Moses, Danny]

Hi,

Thanks for the support.

I agree with your comment; the text might be misleading.
The general principle is to maintain the old behavior (prior to OnDemand 
support) when one entity is  legacy. According to this principle, if a legacy 
application is executed, it should experience the same behavior as if it would 
have been executed with a legacy IP stack and legacy network. The problem is 
however, that the behavior of the network in terms of IP address type 
allocation is not define.

So I am thinking of changing the text from �C
"New IP stacks must continue to support all legacy operations. If an
application does not use On-Demand Mobility feature, the IP stack
must respond in a legacy manner.

If the network infrastructure supports On-Demand Mobility feature,
the IP stack may still request specific types of source IP address
transparently to legacy applications. This may be useful for
environments in which both legacy and new applications are executed.

The definition of what type of addresses to request and how they are
assigned to legacy applications are outside of the scope of this
specification."

To (the red text is new, the strikethrough text will be deleted)�C
" New IP stacks must continue to support all legacy operations. If an
application does not use On-Demand Mobility feature, the IP stack
must respond in a legacy manner.

If the network infrastructure supports On-Demand Mobility feature,
the IP stack should act according to the application request: If the
application requests a specific address type, the stack should forward
this request to the network. If the application does not request a specific
address type, the IP stack must not request an address type and leave
it to the network's default behavior to choose the type of the allocated
IP address. If an address was already allocated to the host, the IP stack
should use this address and not request a new one from the network.
may still request specific types of source IP address
transparently to legacy applications. This may be useful for
environments in which both legacy and new applications are executed.

The definition of what type of addresses to request and how they are
assigned to legacy applications are outside of the scope of this
specification."

Is that OK?

Thanks,
/Danny

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Seil Jeon
Sent: Tuesday, June 21, 2016 12:52
To: dmm@ietf.org
Cc: '"刘大鹏(鹏成)"'
Subject: Re: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi,

I have read and checked the updates in -03 version.
And I support this draft to move forward, if the following is clearly resolved.


"4.2. IP Stack in the Mobile Host

...


If the network infrastructure supports On-Demand Mobility feature, the IP stack 
may still request specific types of source IP address  transparently to legacy 
applications."


As this draft is based on the application-driven API selection idea, if no 
explicit request is given by an application, the type should be selected by 
default, though the default behavior could be regulated by the network 
operator. My comment is putting "based on a default havior" in a proper place 
in the sentence would be exact, leaving no misunderstanding as if the IP stack 
has the selection capability of source IP address type, instead of the 
application.

One minor comment is [I-D.ietf-dmm-requirements] in the reference should be 
replaced by RFC7333.


Regards,
Seil Jeon


-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni
Sent: Thursday, June 16, 2016 2:16 AM
To: dmm@ietf.org
Cc: "刘大鹏(鹏成)"
Subject: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Folks,

This email starts the WGLC #2 for draft-ietf-dmm-ondemand-mobility-05. Post 
your comment to the mailing list and also add your issues/correction 
requests/concerns etc into the Issue Tracker.

   WGLC #2 Starts: 6/15/2016
   WGLC #2 Ends: 6/29/2016 EOB PDT

Regards,
   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

-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] OnDemand draft: 3 address types discussion

[Moses, Danny]

Hi,

My newest answers are marked: Danny>>3

Regards,
/Danny



-Original Message-
From: Alexandre Petrescu [mailto:alexandre.petre...@gmail.com] 
Sent: Thursday, May 19, 2016 11:33
To: Moses, Danny; dmm@ietf.org
Subject: Re: [DMM] OnDemand draft: 3 address types discussion

[...]

> Danny >>2 I am not sure I understood your comment here. When I 
> referred to 'cost' I did not mean actual dollars. I was referring to  
> cost of infrastructure, cost in terms of non-optimal routes (which may 
> translate to latency in packet arrival), cost of overhead 
> (encapsulation overhead - for example) etc.

Hi Danny,

These costs - infra, non-optimal routes, latency in packet arrival - are
two: memory-CPU costs in the infra, and latency costs.

The memory and CPU cost in the infra, induced by triangular routing, can be 
characterized by the memory size and CPU cycles.  In triangular routing there 
is one more entry in the routing tables in memory at a 3rd point (instead of 
just at 2 points).  The CPU cycles - I dont know. How much is it?

The latency cost: again, as I explained previously - it is negligible - it is 3 
micro-seconds in triangular routing (compared to 2 micro-seconds w/o triangular 
routing), when the UE experiences a first hop of 50ms.

The encap/decap costs: there is memory, CPU and on-the wire costs.  What is the 
mem-CPU cost?

On the wire cost of encap/decap is very low: encap/decap is about 40bytes of 
additional header compared to 1200bytes which is the minimal MTU of IPv6.

> Clearly, all these are saved when there is no need for session-lasting 
> IP guarantee.

YEs, but is it worth the effort?  Or is it just like in flat-rate and 'fair 
use' concepts where we should not worry about the cost, but worry about the 
growth.

> So if the application does not need this guarantee and the network 
> supports the ability not to provide this guarantee, both sides gain.

If we worry about these costs - then yes.

> Do you have a concern here? Am I relating to it?

YEs, the concern is how much do we gain by modifying the network too _not_ 
provide the currently provided stable addresses?
Danny>>3
Well, you are showing some costs, but I am not sure you covered all of them. 
Nevertheless, there are quite a few people that think that the investment is 
worth the savings in latency, CPU and memory, especially with the increasing 
demands for resource in the future 5G installations. Our intent is to prepare 
the future access networks for the growing demand not just by increasing the 
pure bandwidth of the wire (or wireless medium), but also by improving other 
aspects (as described).
Clearly, there will never be consensus as to the appropriate features and we do 
not expect all operators to support them at once. But, unless better and 
competing ideas are introduced, we think they will gradually be used. Remember, 
even IPv4 is still very common, although IPv6 has been released ages ago.
--

[...]

> Danny >>2 As I mentioned, there are various costs, not just latency.
>  Regarding latency, I am not sure your data will be valid in DMM 
> deployments with multiple mobility anchors. One of the ideas which 
> relates to multiple mobility anchors is to place the anchors close to 
> the base-station (or even co-located in the base-station). This has 
> various advantages (not relevant to OnDemand), but also a disadvantage 
> in terms of routing traffic after a hand-off (since the  traffic needs 
> to flow through the original mobility anchor.

I dont understand: if we place a mobility anchor closer to the base station, 
the traffic after hand-off will no longer flow through the original mobility 
anchor, right?
Danny>>3
This is not correct. Packets generated by the Sockets that were opened before 
the hand-off must be routed through the original mobility anchor (hence the 
triangular routing you mentioned previously.  Packets generated by Sockets 
opened after the hand-off will be routed via the new mobility anchor (if the 
mobile host is triggered to request a new session-lasting IP address after the 
hand-off). 


> But the OnDemand draft does not mandate all future networks to support 
> it. We offer backwards compatibility of working with networks that 
> provide IP address continuity regardless of the application's request. 
> Operators who believe that the cost of providing this guarantee is 
> negligible, may decide not to implement this feature.

A-ha, but it's not related to our discussion.

[...]

> I can not agree that an application will require some kind of IP 
> address.
>
>
> Danny >>2 I do not understand what you cannot agree to. This whole 
> draft is about applications requesting specific types of IP address.
>  So are you saying that you cannot agree to the OnDemand c

Re: [DMM] OnDemand draft: 3 address types discussion

[Moses, Danny]

Hi Alex,

My replies in this email are marked with 'Danny >>2'.
Regards,
/Danny


-Original Message-
From: Alexandre Petrescu [mailto:alexandre.petre...@gmail.com] 
Sent: Wednesday, May 18, 2016 16:33
To: Moses, Danny; dmm@ietf.org
Subject: Re: [DMM] OnDemand draft: 3 address types discussion

Danny,

Thank you for the reply.

I agree with most comments.

I appreciate the effort you made to make a common understandable email.

But we may further need to better understand each other by email.  To that end, 
we would need to use a common way of citing each other.  There are many ways 
that each person believes is the best.  But there is only one way that is 
agreed by most.

Le 16/05/2016 à 11:58, Moses, Danny a écrit :
> Hi Alex,
>
>
> Thank you very much for the detailed review and comments. I have tried 
> to answer them, but if I was not able to be clear enough, I will be 
> happy to discuss this with you.
>
> I am removing parts of the previous exchange so that everyone can find 
> the open questions and answers more easily.
>
> Regards, /Danny
>
>
> --- Text removed from previous exchange-
>
> --
> --
>
>
>
>
>
>
>
>
>
> Alex > Yet, some questions arise:
>
> The apps which don't require a session-lasting IP address can 
> obviously work with a session-lasting IP address too.  So some of the 
> session-lasting IP addresses can be non-persistent IP addresses?
>
> Danny > True, applications that do not require a session-lasting IP 
> address can work correctly with a session-lasting IP address. But in 
> that case, the network will invest resources in guaranteeing this 
> without any real need and thus, these resources will be wasted.

Intuitively it can appear so: more state in routers maybe needed to maintain 
routes to an IP address which moves, rather than simply changing the IP 
address.  And that state may look more expensive.

On another hand, it may be that that 'cost' is artificial in the first place.  
Modem connections were first charged on a per-time basis - it was artificial; 
now there are flat rates.  Initial 4G subscriptions plans allowed only for 1Gb 
'fair use' - it was artificial; now there is 50Gb 'faire use' for same price as 
1Gb only 2 years ago.

Currently, some cellular operators only offer session-lasting IP addresses (do 
not offer non-persistent IP addresses).

Danny >>2
I am not sure I understood your comment here. When I referred to 'cost' I did 
not mean actual dollars. I was referring to cost of infrastructure, cost in 
terms of non-optimal routes (which may translate to latency in packet arrival), 
cost of overhead (encapsulation overhead - for example) etc.

Clearly, all these are saved when there is no need for session-lasting IP 
guarantee. So if the application does not need this guarantee and the network 
supports the ability not to provide this guarantee, both sides gain. 

Do you have a concern here? Am I relating to it?
-

> From the application side, its traffic may suffer from the treatment 
> associated with providing session-lasting characteristics (non-optimal 
> routing, encapsulation/decapsulation overhead which influences MTU, 
> etc).

Again, this may look so, intuitively speaking.  But I beg to differ.

If one looks at a cellular network from a latency perspective, one has to 
imagine the radio access link as very large, and the core network as very 
small.  That means that sub-optimal routing and encap/decap overheads are very 
small compared to the radio access.

On 4G, latency between the UE and the first IP hop is in the order of 50 
milli-seconds, whereas the Ethernet latency (supposedly used in the wired 
segment to the first IP hop) is in the order of 1 micro-second.

So, if instead of the optimal routing 1 micro-second the non-optimal routing is 
3 micro-seconds that is very small compared to the radio access latency.  That 
can not be considered as additional cost.

Danny >>2
As I mentioned, there are various costs, not just latency. 
Regarding latency, I am not sure your data will be valid in DMM deployments 
with multiple mobility anchors. One of the ideas which relates to multiple 
mobility anchors is to place the anchors close to the base-station (or even 
co-located in the base-station). This has various advantages (not relevant to 
OnDemand), but also a disadvantage in terms of routing traffic after a hand-off 
(since the traffic needs to flow through the original mobility anchor.

But the OnDemand draft does not mandate all future networks to support it. We 
offer backwards compatibility of working with networks that provide IP address 
continuity regardless of the application's request. Operators who believe that 
the cost of 

Re: [DMM] OnDemand draft: 3 address types discussion

[Moses, Danny]

Hi Alex,


Thank you very much for the detailed review and comments. I have tried to 
answer them, but if I was not able to be clear enough, I will be happy to 
discuss this with you.

I am removing parts of the previous exchange so that everyone can find the open 
questions and answers more easily.

Regards,
/Danny


--- Text removed from previous exchange-




Alex >
Yet, some questions arise:

The apps which don't require a session-lasting IP address can obviously work 
with a session-lasting IP address too.  So some of the session-lasting IP 
addresses can be non-persistent IP addresses?

Danny >
True, applications that do not require a session-lasting IP address can work 
correctly with a session-lasting IP address. But in that case, the network will 
invest resources in guaranteeing this without any real need and thus, these 
resources will be wasted. From the application side, its traffic may suffer 
from the treatment associated with providing session-lasting characteristics 
(non-optimal routing, encapsulation/decapsulation overhead which influences 
MTU, etc). Still, I believe that there will be cases when this is performed. 
One example is in cellular networks that automatically provide tunneling and do 
not support the ability to receive IP address type requests from the mobile 
node.

But, if an application requests a session-lasting IP address, and the network 
provides one, it should treat it as such - e.g. provide IP continuity guarantee 
throughout the lifetime of the session. The network cannot tell if the address 
is 'really' using the guarantee or not. 

I did not understand what you mean by 'So some of the session-lasting IP 
addresses can be non-persistent IP addresses?'. No, if the network provides a 
session-lasting IP address, it is committed to guarantee it (even if the 
application does not need the service).

Alex >
The apps which require a session-lasting IP address wish to introduce overhead 
in the network?

Danny >
Apps which require session-lasting IP addresses are apps that cannot recover 
from the event of source IP addresses becoming obsolete as a result of the 
mobile node moving to a LAN with a different IP prefix. This is why they 
request a session-lasting IP address. Not because they wish to introduce 
overhead - this is a by product...

Alex >
Mobile operators using GTP or PMIP do not provide non-persistent IP addresses?

Danny > 
Mobile operators using GTP or PMIP provide a guarantee that the source IP 
address they allocated to a mobile node will continue to exist (and be valid) 
as long as the mobile node is connected to the network (or as long as the DHCP 
lease condition are meat - if DHCP is used). This even a better guarantee than 
what we defined by 'session-lasting' IP address, because the GTP/PMIP source IP 
address is guaranteed regardless of the initiation/end of IP session. In our 
understanding, this extra guarantee is not really needed and in the DMM 
environment where they may be multiple mobility anchors might even introduce 
inefficient routing (which could be avoided in the newly introduced scheme).

To the best of my knowledge, mobile operators do not provide non-persistent IP 
addresses.

Alex>
> Basically, current implementations provide  a guarantee for the source 
> IP address to be valid throughout the time the mobile host is 
> connected to the mobile network. We concluded that mobile hosts do not 
> really require such a guarantee. It is sufficient to require a 
> guarantee of the IP address availability while there is/are an IP
> session(s) using this IP address and hence the more accurate 
> definition.

I dont understand.

Until here the app requirements where important.  Now we change to make the 
mobile host to be important(?)

Danny >
In current implementation a source IP address is allocated to the mobile host 
and is valid throughout the connection of the mobile host to the network. This 
is why I use the term 'mobile host' in the description that you quoted.

 We are introducing an new concept - 'OnDemand' - where each time an IP session 
is created (by an application running on the host), an application can request 
a specific source IP address for that session (with specific type). From the 
network's perspective, this address was allocated to a mobile host. This means 
that at any given time, a mobile host might have more than one source IP 
address allocated to in, and different IP sessions initiated by that host (by 
different applications running on that host) may be used in different packets 
being sent/received by it.

I can understand why this is confusing. If this explanation is not sufficient, 
I will be happy to discuss this point with you.

Alex >
> Furthermore, some WG members have shown cases in DMM where it is more 
> efficient for applications to request a new Session-lasting IP address 
> when 

Re: [DMM] OnDemand draft: 3 address types discussion

[Moses, Danny]

Come on Behcet, this note from you is really insulting.
IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_COA assumes the implementation of MIP 
where the mobile host is provisioned a Home Address and a Care-of Address.

But with PMIPv6 and 3GPP (GTP - to be more accurate), the mobile node is 
provisioned with a source IP address and the tunneling operation is performed 
by proxy and is transparent to the mobile host. So a mobile node cannot 
influence the network's tunneling operation...

Regards,
/Danny

-Original Message-
From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] 
Sent: Friday, May 06, 2016 22:21
To: Moses, Danny
Cc: dmm@ietf.org
Subject: Re: [DMM] OnDemand draft: 3 address types discussion

Hi Danny,

This is my reply to all your mails. I hope it clarifies the air.

I read RFC 5014 and I think that on-demand mobility as I and it seems like as 
3GPP understands is already there:

IPV6_PREFER_SRC_HOME
IPV6_PREFER_SRC_COA

are all we need.
So if UE wants mobility, it sets  IPV6_PREFER_SRC_HOME and as a result gets the 
fixed IP address as you call it or it gets anchored mobility service.

If UE does not want mobility, it sets IPV6_PREFER_SRC_COA then it gets the 
nomadic IP address.

Note that in the case of mobility, UE may still get nomadic address and 
mobility, that is another issue.

Therefore RFC 5014 is good enough, the authors, all good friends of this 
community have done a good job.

Regards,

Behcet


On Tue, May 3, 2016 at 7:27 AM, Moses, Danny <danny.mo...@intel.com> wrote:
>
> This is in reply to comments we received from Behcet and Suresh 
> regarding the three types of addresses define in the draft. Suresh 
> commented that the ‘Fixed IP address’ is not necessary and application 
> only require to select Sustained or Nomadic IP addresses and Behcet 
> commented that the ‘Sustained IP address’ is not needed and not well 
> define due to the fact that the draft does not define how to identify 
> the end of an IP session (will be discussed in a separate email).
> We have gave more thought to these types and concluded that the 
> definitions in the spec were confusing. We are providing new text in 
> the new version, hoping they are more clear.
> We re-evaluated whether to stay with the definition of three IP 
> address types or move to a two IP address type scheme and eventually 
> concluded that it is better to stay with the three type alternative. 
> We hope that the better text in the new draft version will clarify and 
> here are some additional inputs:
> Nomadic IP address (or in its new name: Non-persistent IP address):
> Clearly this type is useful for all applications that do not require 
> any IP session continuity guarantee from the network and wish to avoid 
> the overhead introduced by the network as part of that guarantee 
> (inefficient routes, tunneling etc…).
> Sustained IP address (or in its new name: Session-lasting IP address):
> This is our accurate definition for the IP session continuity service 
> that some application require and is similar to what is provided today 
> by default, by mobile operators via GTP or PMIP. Basically, current 
> implementations provide  a guarantee for the source IP address to be 
> valid throughout the time the mobile host is connected to the mobile network.
> We concluded that mobile hosts do not really require such a guarantee. 
> It is sufficient to require a guarantee of the IP address availability 
> while there is/are an IP session(s) using this IP address and hence 
> the more accurate definition. Furthermore, some WG members have shown 
> cases in DMM where it is more efficient for applications to request a 
> new Session-lasting IP address when launched rather than using an 
> existing one that was allocated to the mobile host in the past. This 
> is due to possible movement of the mobile host to a LAN which is being 
> served by a mobility anchor that is different from the one that was 
> used when the older Session-lasting IP address was assigned to the mobile 
> host.
> Fixed IP address (no renaming …):
> We believe that this is where our original text was the most unclear 
> leading to the confusion on the mailing list and the comments from the 
> flour. A Fixed IP address is guaranteed by the network to Always be 
> valid, even if the mobile host is not utilizing any IP sessions, or 
> has been disconnected from the network for some time. This is a 
> special service that mobile network operators provide for a premium 
> charge, for servers, VPNs , secured content and other applications. 
> With this IP address type the network operator provide IP address 
> reachability in addition to IP session continuity, and mobile hosts 
> may register these addresses in DNS infrastructure for name resolution.
> Clearly, most mobile hosts do not require Fixed IP 

Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

[Moses, Danny]

Hi again,

We added text to the draft indicating that the means of communicating required 
address types between the host and the network is outside the scope of the 
OnDemand draft. This is due to the fact that there is no RFC that we could 
refer to.

When we complete the new RFCs that handle this communication, we will add 
reference to the OnDemand draft (hopefully it will become and RFC) to indicate 
how applications can specify the required type of the source IP address.

Regards,
Alper and Danny

-Original Message-
From: Moses, Danny 
Sent: Wednesday, April 06, 2016 20:40
To: pierrick.se...@orange.com
Cc: dmm@ietf.org; sarik...@ieee.org
Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

H Pierrick,

Thanks for the support.
Yes, we will look for a place to add the clarification that these API extension 
rely on other protocol enhancements to communicate the address type request to 
the network. We cannot currently provide reference to the specific documents 
you gave in your examples because they are not RFCs (yet...).

Danny

-Original Message-
From: pierrick.se...@orange.com [mailto:pierrick.se...@orange.com]
Sent: Wednesday, April 06, 2016 05:43
To: Moses, Danny; sarik...@ieee.org
Cc: dmm@ietf.org
Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

Hi Dany,

I support this I-D. I find the document very useful, and well written. We all 
agree that mobility management must be activated on purpose,  it likely 
requires an enhanced source address selection framework where applications can 
obtain IP address with specific properties. By allowing applications to request 
prefix properties, this I-D is clearly a part of this framework. Maybe the 
document could be better by stressing clearly that it should be used together 
with solutions allowing the network to expose prefix properties to the host, 
for example with draft-korhonen-dmm-prefix-properties and 
draft-moses-dmm-dhcp-ondemand-mobility, which are somehow complementary... Like 
I said, it is  a framework :-)


BR,
Pierrick

> -Message d'origine-
> De : dmm [mailto:dmm-boun...@ietf.org] De la part de Moses, Danny 
> Envoyé : jeudi 31 mars 2016 18:44 À : sarik...@ieee.org Cc :
> dmm@ietf.org Objet : Re: [DMM] WGLC #1 for
> draft-ietf-dmm-ondemand-mobility-01
> 
> Hi,
> Good, see my reply inline (surrounded by >>>>>>>>>>>>) .
> 
> Thanks again for investing the time to review the drafts,
>   /Danny
> 
> -Original Message-
> From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
> Sent: Wednesday, March 30, 2016 12:12
> To: Moses, Danny
> Cc: dmm@ietf.org
> Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01
> 
> Hi Danny,
> 
> I am removing all previous conversation because it all got mixed up.
> Let's start afresh.
> 
> 
> I read you dhcp draft also.
> 
> There is confusion in several levels. Your API draft talks about 
> different applications on a MN needing different types of mobility 
> services. Your DHCPv6 draft seems to give a solution on how a host can 
> get different types of addresses/prefixes from DHCPv6 server, so is it for a 
> host or an application?
> Prefix or address is assigned for an interface, that is another well 
> known concept which your draft seem to completely ignore, i.e. a host 
> may have multiple interfaces.
> DM>>>>>>>>>>>>>>>>>>>>>>
> Yes, I understand were the confusion might arise. The only entity in 
> the host (or - mobile device) which uses DHCP is the DHCP client that 
> is part of the TCP/IP stack. There may be several triggers to cause 
> the DHCP client to request a source IP address:
>  - When the mobile node initially attaches to a network.
>  - When the mobile node moves to a different location and needs to 
> refresh its source IP address.
> The On-Demand concept implies a new trigger:
>  - When an application is launched, opens an IP Socket and requires a 
> special type of source IP address which was not already assigned to the 
> mobile node.
> So, it is the responsibility of the TCP/IP stack in the mobile node to 
> figure out when it is required to initiate a DHCP transaction to serve the 
> application's needs.
> 
> Regarding multiple interface, you are correct once more. A mobile node 
> may have multiple interfaces. When this occurs, the mobile node needs 
> to send at least one DHCP request on each interface and the network 
> assigns the source IP address to the interface from which the DHCP 
> request had arrived. This is not new and the DHCP draft does not 
> mention it because there are no changes or extensions required.
> >>>>>>>>>>>>>>>>>>>>>>>>>D

[DMM] Reachable vs Resolvable

[Moses, Danny]

Charlie suggested to refer to Reachable IP addresses as Resolvable IP 
addresses. This is in the introduction section of the draft that defines IP 
session continuity and IP address reachability.
This is also something we evaluated and decided not to change the text. We 
believe that the term Resolution is used with regards to host names, not IP 
addresses. Host names are either 'resolvable' or not. When a client needs to 
reach a server, it uses DNS and perform name -resolution to obtain the server's 
IP address.
Therefore, we prefer to stay with the original definition.
Regards,
Alper and Danny


-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] A new version of the On-Demand draft

[Moses, Danny]

Hi all,
We thank everyone that provided comments and suggestions for improving the 
OnDemand draft. We have made some changes to the draft addressing some of the 
comments. The main changes were to improve the description of the three 
different source IP address types and improving their names.
We would like to address each of the comments (even those that did not lead to 
changes in the draft). Since there were quite a few, we grouped them into 
several topics and will address each one in a different email to enable a focus 
discussion (if any) on a per-topic basis.
Alper and Danny

-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

[Moses, Danny]

Hi guys,

Alper and I are in the process of compiling all the new comments we received in 
the last DMM face to face. We plan to issue a new version of the draft that, 
hopefully, clarifies the definitions and will provide a written response on the 
mailing list with further explanation and responses to all the comments.

Please be patient for a couple of days.

Thanks,

Alper and Danny

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Behcet Sarikaya
Sent: Thursday, April 21, 2016 11:43
To: Seil Jeon
Cc: dmm@ietf.org
Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

On Wed, Apr 20, 2016 at 5:35 AM, Seil Jeon  wrote:
> Hi Behcet,
>
> As I was not there, what discussions was given.
> However, let me speak a few words.
>
> The specs. you referenced seems talking about need of different levels 
> of mobility support, e.g. high/medium/low mobility and so on.


I am looking at Rev 0.3, they no longer have those.
I am hearing that Rev 0.4 is being worked out and maybe posted sometime next 
week.
I hope this clarifies.

Behcet

> Within the frame, I think having a proper level of mobility support 
> based on IP session continuity and IP address reachability for an 
> application, with the defined source IP address type request will make 
> sense in the scope of mobility support in the specs.
>
> Besides, as you know, the spec. currently remains at 0.2 version, 
> describing work items briefly and concisely. It doesn't constraint 
> potentials for on-demand mobility. And we don't know how/where the direction 
> will be going.
>
> Regards,
> Seil Jeon
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Behcet Sarikaya
> Sent: Tuesday, April 19, 2016 4:52 PM
> To: Jouni Korhonen 
> Cc: dmm@ietf.org
> Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01
>
> Hello Folks,
>
> At IETF 95 session, there was some discussion on the mention of on 
> demand mobility in 3GPP 5G documents, e.g. 23.799.
>
> It seems like 3GPP meaning of on demand mobility is that the UE asks 
> or demands mobility support or not.
>
> So that has nothing to do with the sustained IP addresses.
>
> Regards,
>
> Behcet
>
> On Tue, Dec 1, 2015 at 12:07 PM, Jouni Korhonen 
> 
> wrote:
>> Folks,
>>
>> This mail starts two week WGLC for the I-D:
>>
>> https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-01
>>
>> The WGLC ends 12/15/2015.
>>
>> Provide your reviews and comments to the mailing list. For the better 
>> tracking of issues and proposed changed use the Issue Tracker to 
>> submit your issues/proposals.
>>
>> - 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 mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

[Moses, Danny]

Hi,
Good, see my reply inline (surrounded by >>>>>>>>>>>>) .

Thanks again for investing the time to review the drafts,
/Danny

-Original Message-
From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] 
Sent: Wednesday, March 30, 2016 12:12
To: Moses, Danny
Cc: dmm@ietf.org
Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

Hi Danny,

I am removing all previous conversation because it all got mixed up.
Let's start afresh.


I read you dhcp draft also.

There is confusion in several levels. Your API draft talks about different 
applications on a MN needing different types of mobility services. Your DHCPv6 
draft seems to give a solution on how a host can get different types of 
addresses/prefixes from DHCPv6 server, so is it for a host or an application?
Prefix or address is assigned for an interface, that is another well known 
concept which your draft seem to completely ignore, i.e. a host may have 
multiple interfaces.
DM>>>>>>>>>>>>>>>>>>>>>>
Yes, I understand were the confusion might arise. The only entity in the host 
(or - mobile device) which uses DHCP is the DHCP client that is part of the 
TCP/IP stack. There may be several triggers to cause the DHCP client to request 
a source IP address:
 - When the mobile node initially attaches to a network.
 - When the mobile node moves to a different location and needs to refresh its 
source IP address.
The On-Demand concept implies a new trigger:
 - When an application is launched, opens an IP Socket and requires a special 
type of source IP address which was not already assigned to the mobile node.
So, it is the responsibility of the TCP/IP stack in the mobile node to figure 
out when it is required to initiate a DHCP transaction to serve the 
application's needs.

Regarding multiple interface, you are correct once more. A mobile node may have 
multiple interfaces. When this occurs, the mobile node needs to send at least 
one DHCP request on each interface and the network assigns the source IP 
address to the interface from which the DHCP request had arrived. This is not 
new and the DHCP draft does not mention it because there are no changes or 
extensions required.
>>>>>>>>>>>>>>>>>>>>>>>>>DM

Another concept is (as I already mentioned) topological correctness.
If MN changes subnet, its previous prefix becomes topologically incorrect. 
Either it has to get a new prefix or there must be some system support, e.g. 
host routes.
Of course another case is anchoring, like in 3GPP or in MIP. If you are 
anchored your prefix does not change.

So you seem to ignore all these and instead introduce three types of addresses 
among which the sustained IP address/prefix is the key to your solution.

Sustained address/prefix has this magical property:
 the IP address used at the beginning of the session remains usable despite the 
movement of the mobile host.

and then you say

access network anchoring, corresponding network anchoring, or some
   other solution
can provide sustained address/prefixes.
what does corresponding network anchoring mean?

DM>>>>>>>>>>>>>>>>>>
Corresponding network is a concept from Alper Yegin's draft - 
https://datatracker.ietf.org/doc/draft-yegin-dmm-cnet-homing/. It defines the 
concept of having the mobility anchor in the network of the mobile node's 
corresponding node, rather than in the access network. It is an interesting 
concept with its advantages (and disadvantages...).
>>>>>>>>>>>>>>>>>>>DM

I have a feeling that what your drafts are saying that right now we don't know 
but we anticipate in the future some ways will be found to make sustained IP 
addresses.
Is this true?
DM>>>>>>>>>>>>>>>>>>>>
Well, we do know how the network can support sustained addresses. But I believe 
that in our DMM work, new alternatives for supporting Fixed and Sustained IP 
addresses will be defined.
>>>>>>>>>>>>>>>>>>>>>DM

BTW, your DHCPv6 draft says that DHCPv6 server can give me a Sustained 
address/prefix but it does not say how it will be different than the fixed one?
DM>>>>>>>>>>>>>>>>>>>>>>>
That is correct. The DHCPv6 draft defines the extensions to DHCPv6 in order to 
support the requests and replies. DHCP does not define how IP addresses are 
allocated.
>>>>>>>>>>>>>>>>>>>>>>>>DM

Suppose we want to develop an access network anchoring for sustained IP 
addresses.
What about the needs for signaling? I have a feeling that a host running very 
many applications, like in to

Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

[Moses, Danny]

Hi Behcet,

Please see my new answers marked with DM>>

Thanks,
/Danny

-Original Message-
From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] 
Sent: Monday, March 28, 2016 09:22
To: Moses, Danny
Cc: dmm@ietf.org
Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

On Sat, Mar 26, 2016 at 10:31 AM, Moses, Danny <danny.mo...@intel.com> wrote:
> Hi Behcet,
>
> Please see my reply in the text.
>
> Thanks,
> /Danny
>
> -Original Message-
> From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
> Sent: Friday, March 25, 2016 22:00
> To: Dave Dolson
> Cc: Moses, Danny; dmm@ietf.org
> Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01
>
> Hi Danny,
>
> I was reading Dave's concerns.
> In my view the real problem in this draft is not with the nomadic IP address, 
> actually Dave's concern was very syntactic.
> I have a semantic concern with the sustained IP address.
> What really is this?
> Sustained IP address is very important for this draft because everything is 
> based on that.
> Reading Section 3.1, Sustained IP Address is kind of a banana, it has the 
> taste that the beholder wants to get. It could be Fixed IP Address or nomadic.
> If Sustained IP Address gets me what I want, i.e. IP session continuity, why 
> do I need anything else?
>
> DM> I am not sure I fully understood your comment/question here. I hope my 
> reply is sufficient.
> DM>I did not understand your attempt to find resemblance between a sustained 
> IP address and a Banana. I also do not understand why you write that it could 
> be a Fixed IP address or a Nomadic IP address. It certainly cannot. What 
> should we modify in section 3.1 to make the distinguish between the different 
> types of services provided to each type of address more clearer?
> DM>If a Sustained IP address gets you what you want - choose it when your 
> application establishes a Socket. If on the other hand, a Nomadic IP address 
> gets you what you want, choose Nomadic when your application establishes a 
> Socket. If you only write applications that require Sustained IP addresses, 
> always choose them when establishing Sockets. But, as we claim in the draft, 
> there are different types of applications in the sense of the IP session 
> continuity they require from the network.

Behcet: You are assigned an address, how do you know it is 
Sustained/fixed/nomadic IP address?
DM>> Good question. Naturally, the network needs to be enhanced to support 
these new alternatives., need to be able to receive a specific request and to 
indicate to the mobile node what type of IP address (or prefix) it had 
allocated for it. This requires enhancements to some protocols who are used to 
provide IP addresses. Please refer to draft-moses-dmm-dhcp-ondemand-mobility-02 
which defines the enhancements to DHCPv6 for supporting the stating of the 
required IP address type.

Next Q: As for nomadic, I understand that I change my address when my network 
changes, i.e. I avoid having topologically incorrect address.
For fixed, I keep my address even if my network changes.
What is the sustained address case?

DM>> The difference from Sustained IP address and Fixed IP address is that the 
Sustained IP address is guaranteed by the network to be valid as long as the IP 
session is alive, while the Fixed IP address is guaranteed to be valid even 
after the IP session ends (in case the application need to re-use it at a later 
time.

I think your draft should better use these types (topologically correct, etc.) 
concepts to make sense and be understandable.
DM>> Thanks for the suggestion. We feel that Sustained and Fixed are 
understandable. We have some debates regarding - Nomadic.

> DM>Some application do not require IP session continuity services from the 
> network and should not be required to endure the overhead accompanied by that 
> service (Tunneling overhead, un-optimal routs etc..). This draft enables 
> application to convey the type of service they require, and may lead to 
> significant reduction of overhead when the above services are not required.
>

Behcet: I understand the API extension part of your draft, but I don't 
understand why you need it. You should clearly explain the use case.
Currently, the main idea is to get sustained IP address but it is not explained 
how the application gets a sustained address because it is not known?
Without a clear case, I don't think the extension is warranted.

DM>> The introduction section and sections 3.1-3.3 provides a decent 
background. Would you like to offer text to improve it?

> It says in the draft, it may be configured by using access network anchoring, 
> corresponding network anchoring, or something else, whatever that is?
> Which access network are you tal

Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

[Moses, Danny]

'Non-persistent topologically-correct' is too long...

But, 'non-persistent' or 'guarantee-less' might be considered.
It seems like this is the only  issue to e resolve. How about I present this in 
the next Face-to-face and we can have a final vote on it.

Regards,
/Danny

-Original Message-
From: Newton, Mathew Mr [mailto:mathew.newton...@mod.uk] 
Sent: Thursday, February 25, 2016 17:30
To: Dave Dolson; Moses, Danny
Cc: dmm@ietf.org
Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

A recent, and hitherto silent, lurker here so apologies for wading in 
unannounced and so late in the day...

-Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dave Dolson

> On the "nomadic address" question, this name really feels wrong to me. The 
> address doesn't move and hence isn't nomadic.
> You don't like "ephemeral" because it doesn't convey movement.
> But a question, does the host have to move for the principles of this 
> document to apply?
> Couldn't a host get a new address (perhaps from a different wireless 
> provider) without moving?
> Maybe "non-nomadic address" or "provider-local address" ?

Would something along the lines of 'Non-persistent topologically-correct' 
address work here?

The 'topologically-correct' component reflects the fact that the address is 
relevant/usable only on a specific network connection. The 'non-persistent' 
aspect indicates that this address can change (whether that be due to a change 
of attachment or not is immaterial in this context).

Granted it is a bit of a mouthful but perhaps the nuances of what is trying to 
be described require it?

Regards,

Mathew
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

[Moses, Danny]

Hi Dave,

Regarding the term "Nomadic" IP address:
Actually, this draft is about enhancements to the Socket API that are useful in 
relation with movement of the mobile host. Its intent was to notify the access 
network as to the type of IP session continuity it requires upon movement 
between LANs. The idea is to reduce the network support for session continuity 
(via PMIP, GTP, etc) when it is not needed. This draft is not dealing with 
devices migrating from one service provider to another as other issues should 
be handled in such scenario.

"Local" is not good as it clashes with IPv6 Local addresses.

The best term in my mind would be: "An IP address without any NW guarantee to 
continue to be valid after a potential host movement to a new LAN with a 
different IP prefix". So far, we could not come with a good name for such an 
address. May be "Guarantee-less"?

Let's not forget: this is going to be used by application developers who do not 
necessarily fully understand how networks allocate IP addresses and maintain 
their validity.

Regarding when On-Demand resolution occurs (Point 6):
How about if we say:

If applications want to influence the type of IP address their generated 
traffic will use, they must do so after creating a Socket and prior to 
generating the first transmitted packet.

We do not want to be too specific since it is not a user's manual.

Does this sound reasonable to you?

Thanks,
/Danny

-Original Message-
From: Dave Dolson [mailto:ddol...@sandvine.com] 
Sent: Thursday, February 18, 2016 22:46
To: Moses, Danny; dmm@ietf.org
Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

Danny and Alper,
Thanks. I hope your helpful explanations below make it into the draft as well.


On the "nomadic address" question, this name really feels wrong to me. The 
address doesn't move and hence isn't nomadic.
You don't like "ephemeral" because it doesn't convey movement.
But a question, does the host have to move for the principles of this document 
to apply?
Couldn't a host get a new address (perhaps from a different wireless provider) 
without moving?
Maybe "non-nomadic address" or "provider-local address" ?


On point 6, yes I think you have to specify when the resolution occurs, since 
it affects which functions return error codes.
I don't think the local address can be resolved before connect(), since the 
choice of local address may depend on the remote address to connect. E.g., 
connections to a peer on a local LAN subnet need to use an address on that 
interface.


-Dave




-Original Message-
From: Moses, Danny [mailto:danny.mo...@intel.com]
Sent: Thursday, February 18, 2016 9:13 AM
To: Dave Dolson; dmm@ietf.org
Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

Hi Dave,

Sorry for the very late response. Somehow we missed the original email and were 
reminded by Jouni (Thanks Jouni).

Anyway, thank you for the thorough and helpful comments. We have produced a new 
version and will publish it shortly.

Please see further details to your comments:

Dave>
1. Was the term "Nomadic" discussed? To me, a nomadic thing moves around, but 
in this draft, Nomadic IP addresses do not move around; they are replaced. 
"Ephemeral IP Address" might convey the idea more clearly.

Reply>
"Nomadic" was discussed, it is not the best name but we could not find a better 
one.
What 'moves around' is the mobile host and as a result of that movement, its 
source IP address might become obsolete (when it moves from its original LAN to 
another with a different prefix). An application on a mobile host requires a 
'Nomadic' IP address when it does not care for the IP continuity guarantee 
services provided by the network. This is either because it knows that the 
mobile host is not really mobile, or because it has other means of maintaining 
session continuity and does not want the overhead associated with 
network-provided IP continuity services.

The term 'Ephemeral' is not associated with movement - we think it is better to 
have a 'movement'-related name.

Dave>
2. I know this is really picky, but it wouldn't hurt to spell out "REQUIRE" in 
IPV6_REQ_FIXED_IP etc.
 - IPV6_REQUIRE_FIXED_IP in parallel with IPV6_PREFER_SRC_PUBLIC

Reply>
Make sense. Will be changed in the next version.

Dave>
3. There is a "TDB" in section 3.4. "TBD: Disallow this case?"  This needs to 
be resolved. I suggest the most restrictive flag applies.

Reply>
This is about whether to enable the application to set more than one flag or 
not per a given socket. We left that for discussion in the draft but never 
resolved it.

We prefer not to enable setting more than one flag since it add complexity. The 
application can check the returned code and act upon it. For example, if it 
uses setsockopt() with IPV6_REQUIRE_F

Re: [DMM] Call for adoption confirmation: draft-seite-dmm-rg-multihoming-02

[Moses, Danny]

Hi,

I support the adoption of this draft.

Regards,
/Danny



-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] mobility and link state [- re: prefix cost]

[Moses, Danny]

Hi,

This is turning to be an interesting discussion.

Regarding Dave's reply (before John reply):
Actually, there are several motivations for indications from the link layer:

1.   As Dave pointed out in his reply - to be aware of source IP address 
change - I agree that this is the most useful one

2.   To be able to postpone sending packets when the link is down (assuming 
it is a temporary state) to prevent TCP time-outs (or other higher-level 
phenomena which could occur with UDP-based traffic)

3.   To trigger a refresh of the source IP address in case of a potential 
triangle route as a result of a handoff (I tried to describe this in the 
scenario named: Handoff - Sustained address - new LAN - better service 
available in slides 15-16).
I agree that there are different events that influence a change in the source 
IP address which could affect applications and I am still not sure what is the 
preferable level of exposure to them.

Regarding John's comment:
The work done so far in the exposure WT was more in the area of enabling 
applications to better specify their needs and have the network fulfill these 
needs. For example: App wants IP session continuity, so it requests a Sustained 
address and the network allocates one. The application is not exposed to the 
details of supporting IP session continuity and that is good.

The link-state exposure topic is a little different in the sense that the 
applications request to be aware of events and are expected to handle them. 
This requires more mobility awareness from application developers.

John's draft goes one step further: It assumes that application query the 
network about different paths and costs and makes intelligent decisions based 
on that information.

I think each topic is useful, and although have some commonalities, should be 
separate work due to the level of awareness they require from application 
developers.

/Danny


From: Dave Dolson [mailto:ddol...@sandvine.com]
Sent: Wednesday, August 12, 2015 21:31
To: John Kaippallimalil; Moses, Danny
Cc: dmm@ietf.org
Subject: RE: mobility and link state [- re: prefix cost]

Yes, (by reading the abstract) that is roughly what I was thinking.
I hope the group gets to a single idea that allows applications to choose the 
best IP addresses to bind to, without having to know anything about the access 
technology.
Go no lower than the IP layer. Applications shouldn't have to know about 3G or 
LTE or WiFi or 100baseT or VPN connections...



From: John Kaippallimalil [mailto:john.kaippallima...@huawei.com]
Sent: Wednesday, August 12, 2015 2:18 PM
To: Dave Dolson; Moses, Danny
Cc: dmm@ietf.orgmailto:dmm@ietf.org
Subject: RE: mobility and link state [- re: prefix cost]

Dave,
With reference to Suppose an application could find out about the different IP 
addresses available to it, and the costs  attributes of using each. Wouldn't 
that fulfill the use case in a very general manner?

Pete and I have a draft - 
http://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcost/ that addresses 
exactly what you state above on the network (between router and host).  Is this 
close to what you are thinking about?
PS: I did receive a number of comments during the IETF presentation and will be 
updating soon. One of the comments was regarding how the host (and application) 
can use this information.

Best Regards,
John


From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dave Dolson
Sent: Wednesday, August 12, 2015 7:53 AM
To: Moses, Danny
Cc: dmm@ietf.orgmailto:dmm@ietf.org
Subject: Re: [DMM] mobility and link state

Danny,
I entirely agree with what you say about the motivation for the work.
But if I may be really picky, I think the required notification is not about 
link state per se, rather about source IP changes.

Suppose an application could find out about the different IP addresses 
available to it, and the costs  attributes of using each. Wouldn't that 
fulfill the use case in a very general manner?

I can think of ways in which a different source address is appropriate even if 
link state was not lost.
- network renumbering (even on a fixed network)
- changes in cryptographically-generated IPv6 addresses
- multi-homing changes, such as *adding* a WiFi interface without dropping a 
mobile interface.

I note also that BSD allows IP addresses to be assigned to the loopback 
interface, the state of which never changes.

-Dave



From: Moses, Danny [mailto:danny.mo...@intel.com]
Sent: Wednesday, August 12, 2015 7:44 AM
To: Dave Dolson
Cc: dmm@ietf.orgmailto:dmm@ietf.org
Subject: RE: mobility and link state

Hi Dave,

Thanks for your comments.
In general, I agree that it is preferable to hide data-link-related events from 
applications. At least, this use to be the case in the stationary world (as 
opposed to mobile).

With the introduction of mobile platforms, the event of a temporary loss of 
connection is much more common (as a result of handoffs). Still, if the 
connection loss is temporary

Re: [DMM] mobility and link state

[Moses, Danny]

Hi Dave,

Thanks for your comments.
In general, I agree that it is preferable to hide data-link-related events from 
applications. At least, this use to be the case in the stationary world (as 
opposed to mobile).

With the introduction of mobile platforms, the event of a temporary loss of 
connection is much more common (as a result of handoffs). Still, if the 
connection loss is temporary and lasts for a very short amount of time, and the 
source IP address is still valid after the connection is back, there is no real 
requirement for any specific action and that event could still be transparent 
to applications.

But maintaining the source IP address (which is referred to in some drafts as: 
'IP session continuity') come with a price: Maintaining tunnels, extra 
encapsulation header in each packet, non-optimal routes etc...

We have acknowledged that some applications can easily recover from a source IP 
address change. This ability means that they do not benefit from the network's 
IP session continuity support, but still have to suffer from the inherit 
overhead. To resolve this, we introduced the 'On-Demand' concept in which 
applications have the ability to indicate to the NW their desire to receive 
different levels of IP session continuity services.

The link-state change indication is another means to help applications that can 
recover from a change in source IP address (as a result of handoff). We believe 
that in the mobile world, application developers may benefit from being aware 
of the mobility behavior of the platform on which their applications are 
deployed. They do not have to be, but being aware can yield better performance 
(same goes for energy consumption - but this is out of the scope of DMM).

To conclude, we are not requiring all future applications to be mobility-aware. 
We are offering means for applications to be mobility aware on their choice to 
enable them to behave in a more optimal manner in mobile platforms.

/Danny

From: Dave Dolson [mailto:ddol...@sandvine.com]
Sent: Tuesday, July 21, 2015 02:52
To: Moses, Danny
Cc: dmm@ietf.org
Subject: 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


-
A member of the Intel Corporation

[DMM] New revision of the draft-moses-dmm-dhcp-ondemand-mobility I-D

[Moses, Danny]

Hi,

We have uploaded a new revision of the draft-moses-dmm-dhcp-ondemand-mobility 
I-D.

This revision includes the following:
1.  Support for requesting a specific type for an IPv6 prefix as well as an 
IPv6 address
2.  Add a new DHCPv6 option for a client to request a specific prefix 
(expressing its desire to be served by a specific Mobility Anchor)
3.  Added diagrams and corrected text

The first addition was in reply for a request from several people to include 
prefix delegation support.

Please review and send us comments.

Thanks,
Alper and Danny


-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF93 meeting.. and forming the agenda

[Moses, Danny]

Hi,

I would like a 20 minute slot to discuss the DHCP on-demand draft.

Thanks,
/Danny

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Korhonen
Sent: Monday, June 08, 2015 23:43
To: dmm@ietf.org; 成 鹏
Subject: Re: [DMM] IETF93 meeting.. and forming the agenda

Folks,

Just reminding you all. We got two early bird requests so far.

- Jouni  Dapeng

4/26/2015, 2:44 PM, Jouni Korhonen kirjoitti:
 Folks,

 Summer is getting closer as well as the Prague meeting. If you feel 
 like having a presentation slot in the meeting let the chairs know 
 (with I-D name, time requested and a reason why you need a slot).

 The WG I-Ds will have precedence and the rest of the available time 
 will be divided using secret formula to individual contributions.

 We'd like to emphasize that for any I-Ds having discussion on the 
 mailing list prior the meeting is a great plus and for a new work 
 almost a prerequisite.



 Jouni  dapeng

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] 回复： Answer on raised questions for the proposed API

[Moses, Danny]

What is simpler. Can you be more specific? What are you comparing?

Thanks,
/Danny

From: Dapeng Liu [mailto:maxpass...@gmail.com]
Sent: Monday, April 13, 2015 15:54
To: Seil Jeon
Cc: Moses, Danny; dmm@ietf.org
Subject: 回复： [DMM] Answer on raised questions for the proposed API

Hello Seil, Danny：

[as an individual contributor]

You can refer to the following two drafts:

https://tools.ietf.org/html/draft-liu-dmm-address-selection-01
http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02

Is it the similar idea?

--
Dapeng Liu


在 2015年4月13日 星期一，上午6:03，Seil Jeon 写道：

Hi Danny,



From your cases specified as follows;



“I am thinking of two places that might require an update:

When an application chooses not to specify a source address (but request a 
specific type)

When an application wishes to choose the source address from a provided list.

“



I don’t understand the meaning of the second case. Why should an application 
wish to choose a source address from a list? What I have talked about was about 
allowing the default source address selection rules, which will be determined 
in the IP stack when an application is initiated with the destination address. 
I think we don’t need to touch it.



The point is an application will totally assign the default source address 
selection mechanism based on only type request but with no preference, or will 
request with the preference of a new Sustained IP address as well as type 
request. In the former case, if there is one or multiple Sustained IP 
addresses, the IP stack will try to pick up one. Or the IP stack will try to 
get a new one. In the latter case, the IP stack will consider a newly obtained 
Sustained IP address all the time, if the requested preference value is not 
less than other preferences defined in the default source address selection 
rules.



The need of the proposed flag and main criteria to be considered were already 
covered with case studies in the draft.

http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00



So, for productive discussion, I would like to suggest that you check our draft 
again please and bring your questions if there is something weird or should be 
updated with additional cases.





Best Regards,



Seil Jeon



From: Moses, Danny [mailto:danny.mo...@intel.com]
Sent: Sunday, April 12, 2015 1:49 PM
To: Seil Jeon
Cc: dmm@ietf.orgmailto:dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API



You have a good point here.



Now I understand the need for the flag you are proposing !!!





We need to take a better look at RFC 6724 and figure out if we need to update 
it.



I am thinking of two places that might require an update:

When an application chooses not to specify a source address (but request a 
specific type)

When an application wishes to choose the source address from a provided list.



When the application indicates the desired address type, but chooses not to 
specify the source address (from a list provided by the IP stack), the stack 
should allocate a source IP address according to the address-type requested by 
the application. In this case, we should consider adding text to describe the 
behavior for Sustained IP addresses. Specifically, if there are several 
Sustained IP addresses allocated to the mobile host, whether to choose one of 
them, or to have the mobile host request a new one from the network (as a 
result of a mobility event – for example).



When an application wishes to chooses the source address from the available 
list (obtained by getaddrinfo()), there are some alternative approaches we 
should consider:

Enhance getaddrinfo() enabling the application to specify the required address 
type, and return the list of source addresses that are of that type (Nomadic, 
Sustained, Fixed or DontCare), or -

Provide the list of addresses with an indication of their type (Nomadic, 
Sustained, Fixed or TypeUnknown) and an indication of whether each address is 
New (allocated after the last handoff event) or Old (allocated before the last 
handoff event)

Some other approach…



The flag is need here, to enable the application to request a new IP address 
(if the returned list only contain 'Old' addresses) !!!



I agree that we should discuss this. How about bringing it to the next 
'Mobility Exposure and Selection WT' call?



Regards,

/Danny



From: Seil Jeon [mailto:seilj...@av.it.pt]
Sent: Sunday, April 05, 2015 17:08
To: Moses, Danny
Cc: dmm@ietf.orgmailto:dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API



Hi Danny,



Meeting is always good, even with you by f-to-f. But in the discussion, the 
main issue is whether we will allow the default source address selection rules 
defined in RFC6724 for selecting a Sustained IP address among several ones or 
fundamentally block them for a specific reason raised by a DMM need. The latter 
approach is not reasonable no matter how I try

Re: [DMM] 回复： Answer on raised questions for the proposed API

[Moses, Danny]

Again – what exactly are you comparing? Please be more specific.

From: Dapeng Liu [mailto:maxpass...@gmail.com]
Sent: Monday, April 13, 2015 16:28
To: Moses, Danny
Cc: Seil Jeon; dmm@ietf.org
Subject: 回复： [DMM] Answer on raised questions for the proposed API



在 2015年4月13日 星期一，下午9:21，Moses, Danny 写道：

What is simpler. Can you be more specific? What are you comparing?
“similar not “simpler”.


Regards,
Dapeng Liu




Thanks,

/Danny



From: Dapeng Liu [mailto:maxpass...@gmail.com]
Sent: Monday, April 13, 2015 15:54
To: Seil Jeon
Cc: Moses, Danny; dmm@ietf.orgmailto:dmm@ietf.org
Subject: 回复： [DMM] Answer on raised questions for the proposed API



Hello Seil, Danny：



[as an individual contributor]



You can refer to the following two drafts:



https://tools.ietf.org/html/draft-liu-dmm-address-selection-01

http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02



Is it the similar idea?



--

Dapeng Liu



在 2015年4月13日 星期一，上午6:03，Seil Jeon 写道：

Hi Danny,



From your cases specified as follows;



“I am thinking of two places that might require an update:

When an application chooses not to specify a source address (but request a 
specific type)

When an application wishes to choose the source address from a provided list.

“



I don’t understand the meaning of the second case. Why should an application 
wish to choose a source address from a list? What I have talked about was about 
allowing the default source address selection rules, which will be determined 
in the IP stack when an application is initiated with the destination address. 
I think we don’t need to touch it.



The point is an application will totally assign the default source address 
selection mechanism based on only type request but with no preference, or will 
request with the preference of a new Sustained IP address as well as type 
request. In the former case, if there is one or multiple Sustained IP 
addresses, the IP stack will try to pick up one. Or the IP stack will try to 
get a new one. In the latter case, the IP stack will consider a newly obtained 
Sustained IP address all the time, if the requested preference value is not 
less than other preferences defined in the default source address selection 
rules.



The need of the proposed flag and main criteria to be considered were already 
covered with case studies in the draft.

http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00



So, for productive discussion, I would like to suggest that you check our draft 
again please and bring your questions if there is something weird or should be 
updated with additional cases.





Best Regards,



Seil Jeon



From: Moses, Danny [mailto:danny.mo...@intel.com]
Sent: Sunday, April 12, 2015 1:49 PM
To: Seil Jeon
Cc: dmm@ietf.orgmailto:dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API



You have a good point here.



Now I understand the need for the flag you are proposing !!!





We need to take a better look at RFC 6724 and figure out if we need to update 
it.



I am thinking of two places that might require an update:

When an application chooses not to specify a source address (but request a 
specific type)

When an application wishes to choose the source address from a provided list.



When the application indicates the desired address type, but chooses not to 
specify the source address (from a list provided by the IP stack), the stack 
should allocate a source IP address according to the address-type requested by 
the application. In this case, we should consider adding text to describe the 
behavior for Sustained IP addresses. Specifically, if there are several 
Sustained IP addresses allocated to the mobile host, whether to choose one of 
them, or to have the mobile host request a new one from the network (as a 
result of a mobility event – for example).



When an application wishes to chooses the source address from the available 
list (obtained by getaddrinfo()), there are some alternative approaches we 
should consider:

Enhance getaddrinfo() enabling the application to specify the required address 
type, and return the list of source addresses that are of that type (Nomadic, 
Sustained, Fixed or DontCare), or -

Provide the list of addresses with an indication of their type (Nomadic, 
Sustained, Fixed or TypeUnknown) and an indication of whether each address is 
New (allocated after the last handoff event) or Old (allocated before the last 
handoff event)

Some other approach…



The flag is need here, to enable the application to request a new IP address 
(if the returned list only contain 'Old' addresses) !!!



I agree that we should discuss this. How about bringing it to the next 
'Mobility Exposure and Selection WT' call?



Regards,

/Danny



From: Seil Jeon [mailto:seilj...@av.it.pt]
Sent: Sunday, April 05, 2015 17:08
To: Moses, Danny
Cc: dmm@ietf.orgmailto:dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions

Re: [DMM] question on 'draft-moses-dmm-dhcp-ondemand-mobility'

[Moses, Danny]

Hi Fred,



I think we should explore prefix delegation as well. I am not familiar enough 
if router requirements for prefix delegation and thus would appreciate your 
help - please describe a use-case and we can evaluate it.



I can also think of a use-case for mobile hosts and Sustained IP addresses:

In the past, I presented a scenario is which it is preferable to anchor an IP 
flow in an anchor that is not necessarily the closest to the mobile node 
(please refer to draft-aliahmad-dmm-anchor-selection-01). This situation can be 
detected either by the network or by the mobile node.



If we want to enable mobile nodes to select a preferred anchor, we need to 
provide means for mobile nodes to express the desired selection. One way is 
enable mobile nodes to request a specific anchor by indicating an IP prefix 
that was provided by that anchor in the past. This could be done by 'hinting' 
the preferred IP prefix (rather than a specific IP address).



Clearly there is more work to be done on this draft and we are welcoming help 
from anyone in the group. Can you help us with the router part?



Thanks,

/Danny



-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Templin, Fred L
Sent: Friday, April 03, 2015 21:13
To: dmm@ietf.org
Subject: [DMM] question on 'draft-moses-dmm-dhcp-ondemand-mobility'



Hi Danny and Alper,



In this draft, you seem to be considering only DHCPv6 address delegation for 
when the node is acting as a mobile host. I am wondering if there are similar 
considerations for DHCPv6 prefix delegation for when the node is acting as a 
mobile router.



But then, I wonder whether any type of prefix delegation other than a fixed 
prefix makes any sense. For example, if the mobile router received a nomadic 
prefix delegation, would it need to renumber its connected networks every time 
it moves and receives a new nomadic prefix?



Should this document discuss prefix delegation considerations for mobile 
routers, or only address delegation for mobile hosts?



Thanks - Fred

fred.l.temp...@boeing.commailto:fred.l.temp...@boeing.com



___

dmm mailing list

dmm@ietf.orgmailto:dmm@ietf.org

https://www.ietf.org/mailman/listinfo/dmm
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Call for adoption: draft-wt-dmm-fpc-cpdp-00

[Moses, Danny]

I support adopting draft-wt-dmm-fpc-cpdp-00 as a DMM WG document.

Regards,
/Danny

-Original Message-
From: Jouni Korhonen [mailto:jouni.nos...@gmail.com] 
Sent: Thursday, April 02, 2015 17:22
To: dmm@ietf.org; Jouni; Dapeng Liu; draft-wt-dmm-fpc-c...@tools.ietf.org
Subject: Call for adoption: draft-wt-dmm-fpc-cpdp-00

Folks,

This emails starts a two week call for the I-D
   draft-wt-dmm-fpc-cpdp-00
to confirm the adoption as a DMM WG document. The call ends April 16th EOB PDT.

Express your support or opposition to the mailing list. During the
IETF92 meeting we got 10 voices for the adoption so at least the same amount 
supporting emails should be expected.



- Jouni  Dapeng
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Answer on raised questions for the proposed API

[Moses, Danny]

Hi Seil,

Please see my replies (surrounded by  2) to yours.

Regards,
/Danny

From: Seil Jeon [mailto:seilj...@av.it.pt]
Sent: Tuesday, March 31, 2015 15:23
To: Moses, Danny
Cc: dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API

Hi Danny,

See the inline please.


Seil Jeon



From: Moses, Danny [mailto:danny.mo...@intel.com]
Sent: Monday, March 30, 2015 4:44 PM
To: Seil Jeon
Cc: dmm@ietf.orgmailto:dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API

Hi Seil,

As to the potential of abuse:
Yes, I see your point and you are correct. If the IP stack will not request a 
sustained IP address more than once after each movement to a new LAN (with a 
different prefix), than there will be no abuse.

Seil - Yes, it's true. Thanks for correction.

As to the second comment, please let me elaborate:
One potential implementation of the IP stack in the host, can be to request a 
Nomadic IP address and a  Sustained IP address whenever connecting to a 
network, and whenever moving to a new LAN, regardless if there are any 
applications requesting any addresses. This way, whenever an application is 
launched and requests either a Nomadic or Sustained IP address, the stack can 
provide one without having to issue a request to the network. In this case, 
there is no need for this flag from the application.

Seil - Decision of which type of IP address by default will be depending on 
the IP pool management policy by operators. You case may correspond to one of 
them. What if only the Nomadic IP address is basically allocated upon a network 
attachment? That is, a lot of applications require mere Internet connectivity 
without session continuity support. So, the Sustained IP address will be 
requested on demand, and the proposed flag will be used to get a new Sustained 
IP address by expressing the explicit request by an application.

2
As I mentioned at the beginning of the description - it is a description of one 
alternative. I am not assuming it is the only scenario.
Yes, I agree that many apps require only Nomadic IP addresses, but in this 
example, the IP stack in the host pre-allocates both Nomadic and Sustained IP 
addresses upon attachment...

Yes, we can describe an alternative in which a Nomadic IP address is 
pre-allocated upon NW connection (and after every movement to a new LAN) and a 
Sustained (and/or Fixed) address is allocated on-demand. Even in such a 
scenario, I do not see any use for this flag - see my reply to the second item 
below...
2





Another potential implementation of the IP stack in the host is not to request 
IP addresses in advance. In that case, it will issue a request for a Nomadic IP 
address or a Sustained IP address the first time an application requests one 
and use it for subsequent requests as long as it is not moving to a different 
LAN. Once it moves, it will again request a new IP address (Nomadic or 
Sustained - according to what is required) after receiving the first request 
from any application. In this case as well, there is no need for this flag.

Seil - Another application requested just Sustained IP address while the IP 
stack has already a Sustained IP address. Why should the IP stack try to get a 
new one, though the application indicated simply Sustained IP address type? 
You case took a step towards a solution where you want to draw. I don't expect 
the action is generic when a Sustained IP address type is requested.

Besides, you assumption on IP address allocation seems not valid. A mobile host 
would get an IP address whatever the allocated IP address type is when it 
attaches at a network, regardless of an application's IP address request.
2
Looks like I did not express myself well enough (and did not fully understand 
your reply). Let me list some events that might help clarify...

Initial state: Mobile node is connected to a network; no Sustained IP address 
is allocated. The IP stack sets a flag (SustainedIPAddressNeeded) indicating 
that if an application requests a Sustained IP address, it will have to request 
one from the network.

Event1: An application that requires a Sustained IP address is launched.
APP action: App requests a Sustained IP address from the IP stack using the 
proposed new API.
IP stack action: Since SustainedIPAddressNeeded is set, request one from the 
network.
Network action: Assigned a Sustained IP address to the mobile node.
IP stack action: (1) Mark the new Sustained IP address as the one to be 
associated to subsequent apps; (2) Reset SustainedIPAddressNeeded; (3)Complete 
the API action and associate the marked Sustained IP address with that port 
(app)

Event2: A new application that also required a Sustained IP address is launched
App action: App requests a Sustained IP address from the IP stack using the 
proposed new API
IP Stack action: Since SustainedIPAddressNeeded  is not set, complete the API 
action and associate the marked Sustained IP address

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

[Moses, Danny]

Works for me.

/Danny

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Korhonen
Sent: Wednesday, July 30, 2014 11:38
To: dmm@ietf.org
Subject: [DMM] interims i.e. teleconferences..

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
-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Teleconference

[Moses, Danny]

Hi. For some reason I cannot vote. When entering Doodle I receive an indication 
that I have already voted even though I did not.

Am I the only one?

Thanks,
/Danny

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dapeng Liu
Sent: Friday, May 30, 2014 07:40
To: dmm
Subject: [DMM] Teleconference


Hello,



The WG decide to have a teleconference next week. Please select your prefer 
time in doodle.



Doodle:

https://doodle.com/d7fsc2gsdsgd2e52n438gimr/private?tmail=poll_invitecontact_participant_invitationtlink=pollbtn

Thanks,
--
DapengJouni

-
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Moses, Danny]

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: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of 
Jong-Hyouk Lee
Sent: Friday, April 19, 2013 11:14
To: KIM, BYOUNG-JO J (BYOUNG-JO)
Cc: dmm@ietf.org; dmm-cha...@tools.ietf.org
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) 
macs...@research.att.commailto:macs...@research.att.com 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
ATT 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
 dmm@ietf.orgmailto:dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.orgmailto:dmm@ietf.org