Re: Mobility Exposure and Selection WT call

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 protected] <mailto:[email protected]>
>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________ dmm mailing list
>>>>> [email protected] <mailto:[email protected]>
>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
> _______________________________________________
> dmm mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmm
>
>