Subject: Re: [DMM] Mobility Exposure and Selection WT call

From: Alper Yegin <[email-masked]>
Date: Mon, 9 Feb 2015 09:59:17 +0200

Folks,

See below for the Webex details.
Remember, the call is on Tue, Feb 10, at 4pm CET.
And don't forget to read the documents in the reading list prior to the call.

> Attendees shall read the following material before the call so that we can directly jump to the discussions:
> 
> 1. http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf
> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf
> 3. https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/
> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf
> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02

Alper

DMM - Mobility Exposure and Selection WT
Tuesday 10 February 2015
16:00  |  Europe Time (Paris, GMT+01:00)  |  1 hr 30 min
> 
>  
> Join WebEx meeting
> Meeting number:	641 085 326
> Meeting password:	dmm1911
>  
> Join by phone
> 1-877-668-4493 Call-in toll free number (US/Canada)
> 1-650-479-3208 Call-in toll number (US/Canada)
> Access code: 641 085 326
> Toll-free calling restrictions
>  
> Add this meeting to your calendar.
>  
> Can't join the meeting? Contact support.
>  
> IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.

On Jan 27, 2015, at 11:12 AM, Alper Yegin wrote:

> Poll is closed, and majority selected the following date for the call:
> 
> Feb 10, 4pm CET.
> 1,5hr call.
> 
> Please mark your calendars.
> 
> In this call, we'll aim making progress on the I-D for item#1 (an API for source address selection).
> 
> Attendees shall read the following material before the call so that we can directly jump to the discussions:
> 
> 1. http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf
> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf
> 3. https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/
> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf
> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02
> 
> 
> Alper
> 
> 
> 
> 
> 
> 
> 
> On Jan 23, 2015, at 3:28 PM, Alper Yegin wrote:
> 
>> Folks,
>> 
>> Please mark your availability on the following doodle for our next DMM WG Mobility Exposure and Selection WT call:
>> 
>> http://doodle.com/7xgcr8x6cgxnbzur
>> 
>> Register your availability no later than the end of Monday (Jan 26).
>> 
>> Alper
>> 
>

---

From: Alper Yegin <[email-masked]>
Date: Wed, 11 Feb 2015 13:43:14 +0200

Hello,

Yesterday's call was attended by: Danny, Byoung-Jo Kim, Jouni, Seil, Sergio Figueiredo, Marco, and Alper.

Slides can be found at: yegin.org/NGMobility/DMM_WG_Exposure_Selection_WT-Call3.pptx

WT agreed to use draft-yegin-dmm-ondemand-mobility as the baseline for item#1 (the API).
A revision of the draft will also include a new section to cover backward compatibility (Danny will provide the draft text).
Comments on the draft are welcome.

The next call will be about items #2/#3 (IP address configuration enhancements associated with the API).
We intend to schedule that one in about 2 weeks.

Alper

On Feb 9, 2015, at 9:59 AM, Alper Yegin wrote:

> <WebEx_Meeting.ics>

---

From: Alper Yegin <[email-masked]>
Date: Wed, 11 Feb 2015 13:54:13 +0200

Folks,

Here's the doodle for setting the date for our next call.

In this call we'll discuss items #2 and #3, which involve the IP address configuration enhancements to support the on-demand mobility API.

item #2. Describe how IP address type information is conveyed from network to MN.

item #3. Describe how a required type of IP address is dynamically configured, when one is not already available on the MN.

http://doodle.com/b67r4bgcefeczbms

Please register your availability no later than the end of Friday (Feb 13).

Alper

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Feb 2015 13:23:27 +0100

Le 11/02/2015 12:43, Alper Yegin a écrit :
> Slides can be found at:
> yegin.org/NGMobility/DMM_WG_Exposure_Selection_WT-Call3.pptx
> <http://yegin.org/NGMobility/DMM_WG_Exposure_Selection_WT-Call3.pptx>

Hello,

I looked at the slides.  I think I understand the concept of type of IP 
address from a mobility perspective: fixed, sustained, nomadic.

I have remarks:
- could an aquired prefix (DHCPv6 PD) also be qualified as fixed,
   sustained, nomadic?
- how would a mobility address type relate to other address 'types'?
   - link-local, ULA, global.
   - unicast, anycast, multicast.
   - MAC-based, random-based (RFC7217).
   - configured by SLAAC, by DHCPv6, by PPP, or registered (RFC 6775).

E.g. a nomadic address could never be a link-local address.

> #2. Describe how IP address type information is conveyed from network to MN.

If one designs a protocol to convey address type information from the 
network to the end node, then one could also add the other types 
mentioned above.

SLAAC could never 'convey' the address type to the end-node, because 
SLAAC is an operation happening with as heavy weight from the Server 
(router) as from the Client (Host): the Router decides the prefix but 
the Client decides the Interface ID.

Address Registration Option of 6lo and BTLE would have the Host 
conveying this information to the Router (and not vice-versa).

Yours,

Alex

> A revision of the draft will also include a new section to cover
> backward compatibility (Danny will provide the draft text).
>>> Attendees _shall read _the following material before the call so that
>>> we can directly jump to the discussions:
>>>
>> *DMM - Mobility Exposure and Selection WT*
>> Tuesday 10 February 2015
>>> *Join WebEx meeting*
>>> <https://ietf.webex.com/ietf/j.php?MTID=m1dad9871a277ff2ab142ae8ff4b77ad3>
>>>
>>> *Join by phone*
>>> *1-877-668-4493* Call-in toll free number (US/Canada)
>>> *1-650-479-3208* Call-in toll number (US/Canada)
>>> Access code: 641 085 326
>>> <http://www.webex.com/pdf/tollfree_restrictions.pdf>
>>>
>>> Add this meeting
>>> <https://ietf.webex.com/ietf/j.php?MTID=m0855d524ccb7239248d0ce34e19f38c8> to
>>> your calendar.
>>>
>>> Can't join the meeting? Contact support. <https://ietf.webex.com/ietf/mc>
>>>
>>> IMPORTANT NOTICE: Please note that this WebEx service allows audio
>>> and other information sent during the session to be recorded, which
>>> may be discoverable in a legal matter. By joining this session, you
>>> automatically consent to such recordings. If you do not consent to
>>> being recorded, discuss your concerns with the host or do not join
>>> the session.
>>>
>> <WebEx_Meeting.ics>
>>
>>
>>> Attendees _shall read _the following material before the call so that
>>> we can directly jump to the discussions:
>>>
>>>> Please mark your availability on the following doodle for our next
>>>> DMM WG Mobility Exposure and Selection WT call:
>>>>
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 11 Feb 2015 12:28:18 +0000

Hi Alper,

I could join only the last 5min of the call and could not participate in the discussion, nor in the
draft selection, which does not mean I disagree with the agreement.

One clarifying question. The scope of WI1-4 has been clearly described and the selected
draft is about extending socket API to enable smart application with picking a suitable
address type (WI1). In case multiple addresses of type sustained are configured, is it
up to the lower stack implementation to pick one? That means only the available types
are exposed to applications through the socket API, correct?

I understand retrieval of a new type and associated IP address is covered by a separate work item.
Can a trigger for such request come from the application via the extended socket?
That means in any case an application can request the address type it needs and
the stack will retrieve it from the network. In such case, the kern may report to the
application the status of such IP address configuration, e.g. in case of failure.
A more simplistic approach is to allow applications to use only the types, which
are available on the mobile and exposed to the application. Which operation
do you have in mind?

Thanks,
marco

From: dmm [mailto:[email-masked]] On Behalf Of Alper Yegin
Sent: Mittwoch, 11. Februar 2015 12:43
To: [email-masked]
Subject: Re: [DMM] Mobility Exposure and Selection WT call

Hello,

Slides can be found at: yegin.org/NGMobility/DMM_WG_Exposure_Selection_WT-Call3.pptx<http://yegin.org/NGMobility/DMM_WG_Exposure_Selection_WT-Call3.pptx>

Alper

Folks,

Alper

Tuesday 10 February 2015

Join WebEx meeting<https://ietf.webex.com/ietf/j.php?MTID=m1dad9871a277ff2ab142ae8ff4b77ad3>

Meeting number:

641 085 326

Meeting password:

dmm1911

Join by phone

Access code: 641 085 326

Toll-free calling restrictions<http://www.webex.com/pdf/tollfree_restrictions.pdf>

Add this meeting<https://ietf.webex.com/ietf/j.php?MTID=m0855d524ccb7239248d0ce34e19f38c8> to your calendar.

Can't join the meeting? Contact support.<https://ietf.webex.com/ietf/mc>

<WebEx_Meeting.ics>

Feb 10, 4pm CET.
1,5hr call.

Alper

Folks,

Alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 13 Feb 2015 10:09:38 +0200

Hello Alex,

> I looked at the slides.  I think I understand the concept of type of IP address from a mobility perspective: fixed, sustained, nomadic.
> 
> I have remarks:

Yes.

>  - link-local, ULA, global.

Link-local can only be nomadic.
Global can be any type.
We cannot assure a ULA address stays the same (considering border crossings), hence it can only be nomadic.

>  - unicast, anycast, multicast.

This is source address selection, hence multicast address is out-of picture.
Unicast vs anycast distinction is orthogonal to mobility type of the address.

>  - MAC-based, random-based (RFC7217).

Orthogonal.

>  - configured by SLAAC, by DHCPv6, by PPP, or registered (RFC 6775).

Orthogonal.

> If one designs a protocol to convey address type information from the network to the end node, then one could also add the other types mentioned above.
> 
> SLAAC could never 'convey' the address type to the end-node, because SLAAC is an operation happening with as heavy weight from the Server (router) as from the Client (Host): the Router decides the prefix but the Client decides the Interface ID.
> 

Still, the network can convey the type of IP address to the host.
Also, one can imagine augmenting Router Solicitation to let the host convey its requested type.

> Address Registration Option of 6lo and BTLE would have the Host conveying this information to the Router (and not vice-versa).
> 

OK.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 13 Feb 2015 10:15:21 +0200

Hi Marco,

> draft selection, which does not mean I disagree with the agreement.

OK. I've recorded anyone I spotted at the meeting. 

> up to the lower stack implementation to pick one?

Yes. This, I believe, is in line with the RFC 5014.

> That means only the available types

No. If the requested type IP address is not available on the stack, then the stack will make an attempt to configure an IP address for the requested type. 
We explained that on the I-D, and also covered on the slides: http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf

Yes.

> application the status of such IP address configuration, e.g. in case of failure.

Yes, covered in the I-D.

> are available on the mobile and exposed to the application.

This is "on-demand" mobility. It'd be inefficient to do any of these:
- always configure all types of IP addresses and maintain them, just in case some app requests it,
- fail an app because the requested type IP address is not already configured (even though it could be configured dynamically).

> Which operation

Latter. 
Please take a look at the I-D, we explain it there. The I-D is a short reading.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Sat, 14 Feb 2015 15:42:10 +0200

I see very light participation in Doodle. Is there a particular reason?
Let me extend the Doodle deadline to end of Monday, Feb 16.

Hopefully more people will join the poll and the subsequent call.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 17 Feb 2015 10:17:43 +0200

OK, poll is closed.
The call will be on Feb 24, Tuesday at 4:00-5:30pm CET.

Please mark your calendars. Webex details will follow.

Alper

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Feb 2015 09:48:12 +0100

Le 13/02/2015 09:09, Alper Yegin a écrit :
> Hello Alex,
>
>> I looked at the slides.  I think I understand the concept of type
>> of IP address from a mobility perspective: fixed, sustained,
>> nomadic.
>>
>> I have remarks: - could an aquired prefix (DHCPv6 PD) also be
>> qualified as fixed, sustained, nomadic?
>
> Yes.
>
>> - how would a mobility address type relate to other address
>> 'types'? - link-local, ULA, global.
>
> Link-local can only be nomadic. Global can be any type. We cannot
> assure a ULA address stays the same (considering border crossings),
> hence it can only be nomadic.
>
>
> This is source address selection, hence multicast address is out-of
> picture. Unicast vs anycast distinction is orthogonal to mobility
> type of the address.
>

?  One wouldn't want her 'fixed' address (not the 'sustained', not
the 'nomadic') be a random-based address RFC7217.  That RFC's abstract says:
> This document specifies a method for generating IPv6 Interface
> Identifiers to be used with IPv6 Stateless Address Autoconfiguration
> (SLAAC), such that an IPv6 address configured using this method is
> stable within each subnet, but the corresponding Interface
> Identifier changes when the host moves from one network to another.

>> If one designs a protocol to convey address type information from
>> the network to the end node, then one could also add the other
>> types mentioned above.
>>
>> SLAAC could never 'convey' the address type to the end-node,
>> because SLAAC is an operation happening with as heavy weight from
>> the Server (router) as from the Client (Host): the Router decides
>> the prefix but the Client decides the Interface ID.
>>
>

I agree.

Alex

>>> WT agreed to use draft-yegin-dmm-ondemand-mobility as the
>>> baseline for item#1 (the API). A revision of the draft will also
>>> include a new section to cover backward compatibility (Danny will
>>> provide the draft text). Comments on the draft are welcome.
>>>
>>> The next call will be about items #2/#3 (IP address
>>> configuration enhancements associated with the API). We intend to
>>> schedule that one in about 2 weeks.
>>>
>>> Alper
>>>
>>>
>>>
>>>
>>>
>>>
>>>> See below for the Webex details. Remember, the call is on Tue,
>>>> Feb 10, at 4pm CET. And don't forget to read the documents in
>>>> the reading list prior to the call.
>>>>
>>>>> Attendees _shall read _the following material before the call
>>>>> so that we can directly jump to the discussions:
>>>>>
>>>>> 1.
>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf
>>>>>
>>>>>
>>>>> 3.
>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/
>>>>>
>>>>>
>>>> *DMM - Mobility Exposure and Selection WT* Tuesday 10 February
>>>> 2015 16:00  |  Europe Time (Paris, GMT+01:00)  |  1 hr 30 min
>>>>
>>>>> *Join WebEx meeting*
>>>>> *Join by phone* *1-877-668-4493* Call-in toll free number
>>>>> (US/Canada) *1-650-479-3208* Call-in toll number (US/Canada)
>>>>> Access code: 641 085 326 Toll-free calling restrictions
>>>>> <https://ietf.webex.com/ietf/j.php?MTID=m0855d524ccb7239248d0ce34e19f38c8>
>>>>> to your calendar.
>>>>>
>>>>> <https://ietf.webex.com/ietf/mc>
>>>>>
>>>>> IMPORTANT NOTICE: Please note that this WebEx service allows
>>>>> audio and other information sent during the session to be
>>>>> recorded, which may be discoverable in a legal matter. By
>>>>> joining this session, you automatically consent to such
>>>>> recordings. If you do not consent to being recorded, discuss
>>>>> your concerns with the host or do not join the session.
>>>>>
>>>> <WebEx_Meeting.ics>
>>>>
>>>>
>>>>> Feb 10, 4pm CET. 1,5hr call.
>>>>>
>>>>> Attendees _shall read _the following material before the call
>>>>> so that we can directly jump to the discussions:
>>>>>
>>>>> 1.
>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf
>>>>>
>>>>>
>>>>> 3.
>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/
>>>>>
>>>>>
>>>>>> Please mark your availability on the following doodle for
>>>>>> our next DMM WG Mobility Exposure and Selection WT call:
>>>>>>
>>> _______________________________________________ dmm mailing list
>>> [email-masked] https://www.ietf.org/mailman/listinfo/dmm
>>>
>>
>>
>> _______________________________________________ dmm mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/dmm
>
>
>

---

From: Alper Yegin <[email-masked]>
Date: Thu, 19 Feb 2015 17:30:23 +0200

>> Identifier changes when the host moves from one network to another.

When using the "fixed" IP address, the host stays connected to the same (logical/home) network at all times, anyways.
Hence, by the above definition, there's no reason to change the interface ID.

I don't know if it makes sense to request a fixed and random-based IP address. But if someone does it, it works.

Alper

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Feb 2015 16:47:05 +0100

Le 19/02/2015 16:30, Alper Yegin a écrit :
> When using the "fixed" IP address, the host stays connected to the same
> (logical/home) network at all times, anyways.

I thought by "fixed" you meant it stays the same wherever the Host goes 
(something like the Home Address).

So, I guess, I should have referred to the "nomadic" address to mean the 
one that is constant, wherever the Host goes.

As such, my suggestion is that a "nomadic" address can never be an 
RFC7217 address.

In practice that would mean that if you configure an address to be 
"nomadic" you must also tell the kernel to not run RFC7217 on it.

But ok, one might think that these two aspects ("nomadic" and RFC7217) 
are orthogonal at this point in time.

Alex

>
> I don't know if it makes sense to request a fixed and random-based IP
> address. But if someone does it, it works.

>> Meeting number:641 085 326
>>>>>>> Meeting password:dmm1911
>>>>>>>
>>>>> [email-masked] <mailto:[email-masked]>
>>>> [email-masked] <mailto:[email-masked]>

---

From: Alper Yegin <[email-masked]>
Date: Mon, 23 Feb 2015 14:46:05 +0200

Here are the Webex details for our Tuesday call.

Folks interested on the following subject, please don't miss this call.

DMM Mobility Exposure and Selection WT call#5
Tuesday 24 February 2015
16:00  |  Europe Time (Paris, GMT+01:00)  |  1 hr 30 mins
 
Join WebEx meeting
Meeting number:	648 782 119
Meeting password:	dmm1911

Join by phone
Access code: 648 782 119

---

From: Alper Yegin <[email-masked]>
Date: Tue, 24 Feb 2015 18:16:39 +0200

Hello,

Today's call was attended by: Danny, Byoung-Jo Kim, Jouni, Seil, Sergio Figueiredo, Sri, John K., and Alper.

Slides (including notes) can be found at: http://yegin.org/NGMobility/DMM_WG_Exposure_Selection_WT-Call4.pptx

Questions/comments welcome.

Alper