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

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Mar 2015 13:00:51 -0500

Le 19/02/2015 10:47, Alexandru Petrescu a écrit :
> Le 19/02/2015 16:30, Alper Yegin a écrit :
>>>>
>>>> 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.
>>>
>>> ?  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.
>>>
>>>
>>
>> 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 thought by "fixed" you meant it stays the same wherever the Host goes
> (something like the Home Address).

Alper - I think a LL address can also be qualified as 'fixed' - it never 
changes.

I think it's hard to disagree with that, no?

Alex

>
> 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.
>
>
>>
>> Alper
>>
>>
>>
>>
>>>>> - configured by SLAAC, by DHCPv6, by PPP, or registered (RFC
>>>>> 6775).
>>>>>
>>>>
>>>> Orthogonal.
>>>>
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> 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.
>>>
>>> I agree.
>>>
>>> Alex
>>>
>>>
>>>>> Address Registration Option of 6lo and BTLE would have the Host
>>>>> conveying this information to the Router (and not vice-versa).
>>>>>
>>>>
>>>> OK.
>>>>
>>>> Alper
>>>>
>>>>
>>>>> Yours,
>>>>>
>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Feb 9, 2015, at 9:59 AM, Alper Yegin wrote:
>>>>>>
>>>>>>> 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*
>>>>>>>> <https://ietf.webex.com/ietf/j.php?MTID=m1dad9871a277ff2ab142ae8ff4b77ad3>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>> 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
>>>>>>>> <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>
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ dmm mailing list
>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________ dmm mailing list
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Mar 2015 13:01:21 -0500

Le 13/02/2015 03: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.

I disagree.  A LL can also be 'fixed', because it's fixed.

> Global can be any type.

Ok.

> We cannot assure a ULA address stays the same
> (considering border crossings), hence it can only be nomadic.

But it can also be sustained.

>> - unicast, anycast, multicast.
>

So all SUSTAINED, NOMADIC, FIXED addresses can only be unicast, right?

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

What does that mean?  orthogonal?

Alex

>>>>> <https://ietf.webex.com/ietf/j.php?MTID=m1dad9871a277ff2ab142ae8ff4b77ad3>
Meeting number:	641 085 326
>>>>> Meeting password:	dmm1911
>>>>>
>>> [email-masked] https://www.ietf.org/mailman/listinfo/dmm
>>>
>>
>>
>> [email-masked] https://www.ietf.org/mailman/listinfo/dmm
>
>
>

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 26 Mar 2015 11:17:35 -0700

Alex,

3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti:

[snip]

> Alper - I think a LL address can also be qualified as 'fixed' - it never

Does LL here mean link-local or link-layer? If it is the former one, 
then the above assertion is not correct.

- Jouni

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Mar 2015 17:02:32 -0500

> then the above assertion is not correct.

Link-local.

And you seem to say a link-local address is not fixed?  I think 
link-local addresses _are_ fixed set in stone.  They are formed locally 
without need of help from router.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 30 Mar 2015 22:42:39 +0000

Hi Alex,

> -----Original Message-----
> From: dmm [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: Thursday, March 26, 2015 3:03 PM
> To: Jouni Korhonen; [email-masked]
> Subject: Re: [DMM] Mobility Exposure and Selection WT call
> 

AERO provides a fixed link-local address that is formed from a prefix
received by DHCPv6 Prefix Delegation (PD). Once the AERO Client is
given a PD (either IPv6 or IPv4) it can form an AERO link-local address
that stays the same wherever the Client moves and with no need to
perform Duplicate Address Detection (DAD). It makes IPv6 ND
simple and seamless.

Thanks - Fred
[email-masked]