Re: [DMM] Mobility Exposure and Selection WT call
On 4/22/15 12:51 PM, Templin, Fred L wrote: Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Tuesday, April 21, 2015 12:42 PM To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility Exposure and Selection WT call Le 31/03/2015 00:42, Templin, Fred L a écrit : Hi Alex, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru Petrescu Sent: Thursday, March 26, 2015 3:03 PM To: Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility Exposure and Selection WT call Le 26/03/2015 13:17, Jouni Korhonen a écrit : Alex, 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti: [snip] 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. Does LL here mean link-local or link-layer? If it is the former one, 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. AERO provides a fixed link-local address that is formed from a prefix received by DHCPv6 Prefix Delegation (PD). Fred - but why should this ll prefix be provided by DHCP? Is it of variable value? Or is the link-local constant all the time? (in which case it could be hardcoded everywhere). DHCPv6 Prefix Delegation delegates an IPv6 prefix to the AERO Client (e.g., 2001:db8:1:2::/64). The Client then constructs an AERO link-local address from the prefix as fe80::2001:db8:1:2 (i.e., it embeds the 64-bit prefix from the prefix delegation in the 64-bit interface identifier of an IPv6 link-local address). So, it is not actually a link-local address per the IPv6 Addressing Architecture (https://tools.ietf.org/html/rfc4291#section-2.5.6). Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Mobility Exposure and Selection WT call
Hi Brian, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Brian Haberman Sent: Monday, April 27, 2015 6:45 AM To: dmm@ietf.org Subject: Re: [DMM] Mobility Exposure and Selection WT call On 4/22/15 12:51 PM, Templin, Fred L wrote: Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Tuesday, April 21, 2015 12:42 PM To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility Exposure and Selection WT call Le 31/03/2015 00:42, Templin, Fred L a écrit : Hi Alex, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru Petrescu Sent: Thursday, March 26, 2015 3:03 PM To: Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility Exposure and Selection WT call Le 26/03/2015 13:17, Jouni Korhonen a écrit : Alex, 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti: [snip] 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. Does LL here mean link-local or link-layer? If it is the former one, 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. AERO provides a fixed link-local address that is formed from a prefix received by DHCPv6 Prefix Delegation (PD). Fred - but why should this ll prefix be provided by DHCP? Is it of variable value? Or is the link-local constant all the time? (in which case it could be hardcoded everywhere). DHCPv6 Prefix Delegation delegates an IPv6 prefix to the AERO Client (e.g., 2001:db8:1:2::/64). The Client then constructs an AERO link-local address from the prefix as fe80::2001:db8:1:2 (i.e., it embeds the 64-bit prefix from the prefix delegation in the 64-bit interface identifier of an IPv6 link-local address). So, it is not actually a link-local address per the IPv6 Addressing Architecture (https://tools.ietf.org/html/rfc4291#section-2.5.6). Just because the AERO address Interface ID is not formed via EUI-64 does not mean that it is not a link-local address (see RFC7136, which updates RFC4291). RFC7421 gives further commentary. Thanks - Fred fred.l.temp...@boeing.com Regards, Brian ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Mobility Exposure and Selection WT call
On 4/27/15 12:30 PM, Templin, Fred L wrote: Hi Brian, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Brian Haberman Sent: Monday, April 27, 2015 9:22 AM To: dmm@ietf.org Subject: Re: [DMM] Mobility Exposure and Selection WT call On 4/27/15 11:53 AM, Templin, Fred L wrote: So, it is not actually a link-local address per the IPv6 Addressing Architecture (https://tools.ietf.org/html/rfc4291#section-2.5.6). Just because the AERO address Interface ID is not formed via EUI-64 does not mean that it is not a link-local address (see RFC7136, which updates RFC4291). RFC7421 gives further commentary. I am not referring to the IID of the link-local address. I am talking about the 54 bits of zero which immediately follow the FE80::/10 prefix. AERO leaves those 54 bits as zero - are you seeing some place in the spec where it does not appear that way? Apologies. I read your example incorrectly. As long as the prefix delegated is 64 bits... Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Mobility Exposure and Selection WT call
On 4/27/15 11:53 AM, Templin, Fred L wrote: So, it is not actually a link-local address per the IPv6 Addressing Architecture (https://tools.ietf.org/html/rfc4291#section-2.5.6). Just because the AERO address Interface ID is not formed via EUI-64 does not mean that it is not a link-local address (see RFC7136, which updates RFC4291). RFC7421 gives further commentary. I am not referring to the IID of the link-local address. I am talking about the 54 bits of zero which immediately follow the FE80::/10 prefix. signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Mobility Exposure and Selection WT call
Hi Brian, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Brian Haberman Sent: Monday, April 27, 2015 9:22 AM To: dmm@ietf.org Subject: Re: [DMM] Mobility Exposure and Selection WT call On 4/27/15 11:53 AM, Templin, Fred L wrote: So, it is not actually a link-local address per the IPv6 Addressing Architecture (https://tools.ietf.org/html/rfc4291#section-2.5.6). Just because the AERO address Interface ID is not formed via EUI-64 does not mean that it is not a link-local address (see RFC7136, which updates RFC4291). RFC7421 gives further commentary. I am not referring to the IID of the link-local address. I am talking about the 54 bits of zero which immediately follow the FE80::/10 prefix. AERO leaves those 54 bits as zero - are you seeing some place in the spec where it does not appear that way? Thanks - Fred fred.l.temp...@boeing.com ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Mobility Exposure and Selection WT call
Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Friday, April 24, 2015 9:36 AM To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility Exposure and Selection WT call Hi Fred, Le 22/04/2015 19:22, Templin, Fred L a écrit : Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Wednesday, April 22, 2015 9:59 AM To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility Exposure and Selection WT call Le 22/04/2015 18:51, Templin, Fred L a écrit : Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Tuesday, April 21, 2015 12:42 PM To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility Exposure and Selection WT call Le 31/03/2015 00:42, Templin, Fred L a écrit : Hi Alex, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru Petrescu Sent: Thursday, March 26, 2015 3:03 PM To: Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility Exposure and Selection WT call Le 26/03/2015 13:17, Jouni Korhonen a écrit : Alex, 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti: [snip] 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. Does LL here mean link-local or link-layer? If it is the former one, 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. AERO provides a fixed link-local address that is formed from a prefix received by DHCPv6 Prefix Delegation (PD). Fred - but why should this ll prefix be provided by DHCP? Is it of variable value? Or is the link-local constant all the time? (in which case it could be hardcoded everywhere). DHCPv6 Prefix Delegation delegates an IPv6 prefix to the AERO Client (e.g., 2001:db8:1:2::/64). The Client then constructs an AERO link-local address from the prefix as fe80::2001:db8:1:2 (i.e., it embeds the 64-bit prefix from the prefix delegation in the 64-bit interface identifier of an IPv6 link-local address). Fred, that looks weird. Never saw a prefix to be used as an Interface Identifier. It is specified in the AERO document and also cited in RFC7421. There are lots of weird address within address encapsulations in common use within the IPv6 interface identifier (e.g., ISATAP address, etc.) and this I think is in some ways less weird than some of the others. Ok. I guess this breaks the DHCP prefix delegation specification. Not at all; I have running code that uses unmodified public domain DHCPv6 clients and servers. On the server side, I was using ISC DHCP but have recently moved over to a great new server package called Kea (also from ISC). Why does not the DHCPv6 server assign a link-local address altogether (rather than assigning a prefix, to be used as an IID). Because the prefix length may be different than /64; hence, the Client needs to receive the prefix in a DHCPv6 IA_PD option. What if DHCP had an option to provide an Interface ID (instead of Prefix Delegation)? Wouldnt that be more appropriate to form a link-local address with that Interface ID? The great thing about the AERO address is that it can be used for both IPv6 ND messaging and route determination. The AERO address is guaranteed to be unique, so it can be used as the source address of IPv6 ND messages with no need for DAD. It can also be used for route determination without consulting a routing table. Plus, we don't need any special options since DHCPv6 PD works fine with no client or server modifications. Thanks - Fred fred.l.temp...@boeing.com Alex Thanks - Fred fred.l.temp...@boeing.com Alex Once the prefix delegation and AERO address configuration are done, they stay fixes as long as the Client remains associated with the same AERO link. 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. Is that prefix fe80::/10? No, it would be a global IPv6 prefix like 2001:db8:1:2::/64. The AERO link has an associated AERO Service Prefix (e.g., 2001:db8::/32) from which longer global IPv6 prefixes are delegated to each Client. The Client then gets to keep and continually use its prefix delegation as long as it stays associated with the same AERO link. Thanks - Fred fred.l.temp...@boeing.com Alex Thanks - Fred fred.l.temp...@boeing.com
Re: [DMM] Mobility Exposure and Selection WT call
Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Wednesday, April 22, 2015 9:59 AM To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility Exposure and Selection WT call Le 22/04/2015 18:51, Templin, Fred L a écrit : Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Tuesday, April 21, 2015 12:42 PM To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility Exposure and Selection WT call Le 31/03/2015 00:42, Templin, Fred L a écrit : Hi Alex, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru Petrescu Sent: Thursday, March 26, 2015 3:03 PM To: Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility Exposure and Selection WT call Le 26/03/2015 13:17, Jouni Korhonen a écrit : Alex, 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti: [snip] 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. Does LL here mean link-local or link-layer? If it is the former one, 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. AERO provides a fixed link-local address that is formed from a prefix received by DHCPv6 Prefix Delegation (PD). Fred - but why should this ll prefix be provided by DHCP? Is it of variable value? Or is the link-local constant all the time? (in which case it could be hardcoded everywhere). DHCPv6 Prefix Delegation delegates an IPv6 prefix to the AERO Client (e.g., 2001:db8:1:2::/64). The Client then constructs an AERO link-local address from the prefix as fe80::2001:db8:1:2 (i.e., it embeds the 64-bit prefix from the prefix delegation in the 64-bit interface identifier of an IPv6 link-local address). Fred, that looks weird. Never saw a prefix to be used as an Interface Identifier. It is specified in the AERO document and also cited in RFC7421. There are lots of weird address within address encapsulations in common use within the IPv6 interface identifier (e.g., ISATAP address, etc.) and this I think is in some ways less weird than some of the others. I guess this breaks the DHCP prefix delegation specification. Not at all; I have running code that uses unmodified public domain DHCPv6 clients and servers. On the server side, I was using ISC DHCP but have recently moved over to a great new server package called Kea (also from ISC). Why does not the DHCPv6 server assign a link-local address altogether (rather than assigning a prefix, to be used as an IID). Because the prefix length may be different than /64; hence, the Client needs to receive the prefix in a DHCPv6 IA_PD option. Thanks - Fred fred.l.temp...@boeing.com Alex Once the prefix delegation and AERO address configuration are done, they stay fixes as long as the Client remains associated with the same AERO link. 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. Is that prefix fe80::/10? No, it would be a global IPv6 prefix like 2001:db8:1:2::/64. The AERO link has an associated AERO Service Prefix (e.g., 2001:db8::/32) from which longer global IPv6 prefixes are delegated to each Client. The Client then gets to keep and continually use its prefix delegation as long as it stays associated with the same AERO link. Thanks - Fred fred.l.temp...@boeing.com Alex Thanks - Fred fred.l.temp...@boeing.com Alex - Jouni 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
Re: [DMM] Mobility Exposure and Selection WT call
Le 22/04/2015 18:51, Templin, Fred L a écrit : Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Tuesday, April 21, 2015 12:42 PM To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility Exposure and Selection WT call Le 31/03/2015 00:42, Templin, Fred L a écrit : Hi Alex, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru Petrescu Sent: Thursday, March 26, 2015 3:03 PM To: Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility Exposure and Selection WT call Le 26/03/2015 13:17, Jouni Korhonen a écrit : Alex, 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti: [snip] 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. Does LL here mean link-local or link-layer? If it is the former one, 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. AERO provides a fixed link-local address that is formed from a prefix received by DHCPv6 Prefix Delegation (PD). Fred - but why should this ll prefix be provided by DHCP? Is it of variable value? Or is the link-local constant all the time? (in which case it could be hardcoded everywhere). DHCPv6 Prefix Delegation delegates an IPv6 prefix to the AERO Client (e.g., 2001:db8:1:2::/64). The Client then constructs an AERO link-local address from the prefix as fe80::2001:db8:1:2 (i.e., it embeds the 64-bit prefix from the prefix delegation in the 64-bit interface identifier of an IPv6 link-local address). Fred, that looks weird. Never saw a prefix to be used as an Interface Identifier. I guess this breaks the DHCP prefix delegation specification. Why does not the DHCPv6 server assign a link-local address altogether (rather than assigning a prefix, to be used as an IID). Alex Once the prefix delegation and AERO address configuration are done, they stay fixes as long as the Client remains associated with the same AERO link. 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. Is that prefix fe80::/10? No, it would be a global IPv6 prefix like 2001:db8:1:2::/64. The AERO link has an associated AERO Service Prefix (e.g., 2001:db8::/32) from which longer global IPv6 prefixes are delegated to each Client. The Client then gets to keep and continually use its prefix delegation as long as it stays associated with the same AERO link. Thanks - Fred fred.l.temp...@boeing.com Alex Thanks - Fred fred.l.temp...@boeing.com Alex - Jouni 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
Re: [DMM] Mobility Exposure and Selection WT call
Le 26/03/2015 13:17, Jouni Korhonen a écrit : Alex, 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti: [snip] 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. Does LL here mean link-local or link-layer? If it is the former one, 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 - Jouni 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/
Re: [DMM] Mobility Exposure and Selection WT call
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 ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Mobility Exposure and Selection WT call#5
Here are the Webex details for our Tuesday call.Folks interested on the following subject, please don't miss this 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.DMM Mobility Exposure and Selection WT call#5Tuesday 24 February 201516:00|Europe Time (Paris, GMT+01:00)|1 hr 30 minsJoin WebEx meetingMeeting number:648 782 119Meeting password:dmm1911Join by phone1-877-668-4493Call-in toll free number (US/Canada)1-650-479-3208Call-in toll number (US/Canada)Access code:648 782 119Toll-free calling restrictionsAdd this meetingto your calendar.Can't join the meeting?Contact support.BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Europe Time BEGIN:STANDARD DTSTART:20131001T03 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10 TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:Standard Time END:STANDARD BEGIN:DAYLIGHT DTSTART:20130301T02 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3 TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:Daylight Savings Time END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ATTENDEE;CN=Dime Working Group;ROLE=REQ-PARTICIPANT;RSVP=FALSE:MAILTO:dime-cha...@tools.ietf.org ORGANIZER;CN=webex:MAILTO:messen...@webex.com DTSTART;TZID=Europe Time:20150224T16 DTEND;TZID=Europe Time:20150224T173000 LOCATION:https://ietf.webex.com/ietf TRANSP:OPAQUE SEQUENCE:1424201510 UID:be806633-475e-4657-8e9e-b681dbfddcd0 DTSTAMP:20150224T15Z DESCRIPTION:\nHost key: 582746\n\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=m9a2800e05c6f1b66ae1162fb0cf703b5\nMeeting number: 648 782 119\nMeeting password: dmm1911\n\n\nJOIN BY PHONE\n1-877-668-4493 Call-in toll free number (US/Canada) \n1-650-479-3208 Call-in toll number (US/Canada)\nAccess code: 648 782 119\n\nToll-free dialing restrictions: \nhttp://www.webex.com/pdf/tollfree_restrictions.pdf\n\n\n\nCan't join the meeting? Contact support here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTANT 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. You should inform all meeting attendees prior to recording if you intend to record the meeting.\n X-ALT-DESC;FMTTYPE=text/html: FONT SIZE=1 FACE=ARIALFONT SIZE=2 COLOR=#66 FACE=Arial nbsp;BRHost key: 582746/FONTnbsp;BRnbsp;BRnbsp;BR FONT SIZE=4 FACE=ARIAL a href=https://ietf.webex.com/ietf/j.php?MTID=m9a2800e05c6f1b66ae1162fb0cf703b5;FONT SIZE=3 COLOR=#00AFF9 FACE=ArialJoin WebEx meeting/FONT/a tabletr td FONT SIZE=2 COLOR=#66 FACE=arialMeeting number:/FONT /td td FONT SIZE=2 COLOR=#66 FACE=arial648 782 119/FONT /td/tr /table tabletrtdFONT SIZE=2 COLOR=#66 FACE=arialMeeting password:/FONT/tdtdFONT SIZE=2 COLOR=#66 FACE=arialdmm1911/FONT/td/tr/table /FONTFONT SIZE=1 FACE=ARIALnbsp;BRnbsp;BR/FONTFONT SIZE=4 FACE=ARIALFONT SIZE=3 COLOR=#66 FACE=arialJoin by phone/FONTnbsp; BRFONT SIZE=2 COLOR=#66 FACE=arialstrong1-877-668-4493/strongnbsp;Call-in toll free number (US/Canada)/FONTnbsp; BRFONT SIZE=2 COLOR=#66 FACE=arialstrong1-650-479-3208/strongnbsp;Call-in toll number (US/Canada)/FONTnbsp; BRFONT SIZE=2 COLOR=#66 FACE=arialAccess code: 648 782 119/FONTnbsp; BRa href=http://www.webex.com/pdf/tollfree_restrictions.pdf;FONT SIZE=1 COLOR=#00AFF9 FACE=arialToll-free calling restrictions/FONT/a nbsp; BR/FONTBRBR nbsp;BR FONT SIZE=1 COLOR=#66 FACE=arialCan't join the meeting?/FONT a href=https://ietf.webex.com/ietf/mc; FONT SIZE=1 COLOR=#00AFF9 FACE=ArialContact support./FONT/a nbsp;BRnbsp;BRFONT COLOR=#A0A0A0 size=1 FACE=arialIMPORTANT 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. You should inform all meeting attendees prior to recording if you intend to record the meeting./FONT/FONT SUMMARY:DMM Mobility Exposure and Selection WT call#5 PRIORITY:5 CLASS:PUBLIC BEGIN:VALARM TRIGGER:-PT5M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR On Feb 17, 2015, at 10:17 AM, Alper Yegin wrote: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.AlperOn Feb 14, 2015, at 3:42 PM, Alper Yegin wrote:I see very light participation in Doodle. Is there a particular reason?Let me extend the Doodle deadline to end of Monday, Feb 16.http://doodle.com/b67r4bgcefeczbmsHopefully more people will join the poll and the subsequent call.AlperOn Feb 11, 2015, at 1:54 PM, Alper Yegin wrote:Folks,Here's the doodle for setting the date for our next call.In this call we'll
Re: [DMM] Mobility Exposure and Selection WT call
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. - 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. ? 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. - 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.
Re: [DMM] Mobility Exposure and Selection WT call
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). 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
Re: [DMM] Mobility Exposure and Selection WT call
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 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.
Re: [DMM] Mobility Exposure and Selection WT call#5
I see very light participation in Doodle. Is there a particular reason? Let me extend the Doodle deadline to end of Monday, Feb 16. http://doodle.com/b67r4bgcefeczbms Hopefully more people will join the poll and the subsequent call. Alper On Feb 11, 2015, at 1:54 PM, Alper Yegin wrote: 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 ___ 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
Re: [DMM] Mobility Exposure and Selection WT call
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. - 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. 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. 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
Re: [DMM] Mobility Exposure and Selection WT call
Hi Marco, On Feb 11, 2015, at 2:28 PM, Marco Liebsch wrote: 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. OK. I've recorded anyone I spotted at the meeting. 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? Yes. This, I believe, is in line with the RFC 5014. That means only the available types are exposed to applications through the socket API, correct? 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 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? Yes. 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. Yes, covered in the I-D. A more simplistic approach is to allow applications to use only the types, which 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 do you have in mind? Latter. Please take a look at the I-D, we explain it there. The I-D is a short reading. Alper Thanks, marco From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alper Yegin Sent: Mittwoch, 11. Februar 2015 12:43 To: dmm@ietf.org Subject: Re: [DMM] Mobility Exposure and Selection WT call 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: 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. 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
Re: [DMM] Mobility Exposure and Selection WT call
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: 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. 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 dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Mobility Exposure and Selection WT call
Le 11/02/2015 12:43, Alper Yegin a écrit : 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 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 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 dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Mobility Exposure and Selection WT call
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 dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
