Re: [DMM] re-charter text updated
Hi Pete, I really don't think we should force DHCP to re-run on every handover. I thought one of the motivations for network-based mobility was to minimize the signaling to the MN during handover. In the current mobility models we have two DHCP deployment models. a.) DHCP server in the access. b.) DHCP Relay in the access For #a, it is the dominant model. The DHCP server is collocated on the access gateway; the interworking between the DHCP server and the mobility function in the access gateway allows the network to offer the same IP address to the mobile node. After each handoff and based on DNA considerations, the MN may go into DHCP INIT-REBOOT followed by Request/reply. I don't know if I should call this as complete Re-Run after each handoff, but at least the current data suggests the handoff latency related to this same-link validation is insignificant. Now, from coloring perspective, the DHCP server in the access network can potentially change the properties of the address. MN is on a new world, new access network, new link and hence some changes to the properties. For #b, we continue to route the DHCP lease renewal messages back to the network where the MN obtained its address. Typically its tunneled to the anchor. Here I see your point of not impacting the DHCP state machine by changing properties based on MN's movement. But, if the DHCP server is aware of changes to properties, can it not send the updated properties ? We have to look at properties as meta-data that goes with an IP address/prefix. This meta-data should not have any relation to the DHCP state machine. But, some properties of that address do change, based on MN's movement, mobility state changes ..etc. If the DHCP server is aware of these property change, IMO, it should reflect the updated properties. I'm more interested in #a and not deal with this issue at all. But, if we insert a property element in PIO, we should do that consistently and have that in DHCP as well. Regards Sri On 3/20/14 5:37 PM, Peter McCann peter.mcc...@huawei.com wrote: Hi, Sri, Sri Gundavelli (sgundave) wrote: On 3/20/14 5:54 AM, Peter McCann peter.mcc...@huawei.com wrote: I think our extensions should be to the prefix information option and not DHCP. The properties of an address may change after a handover and we should not couple the DHCP state machine (which is about lease renewal) to the handover state machine. Hi Pete, This is a good comment. If we are making any assumption that even after a handover, the DHCP transactions are still hitting the same DHCP server node, this may be a valid concern. But, if DHCP transactions are locally terminated after handover (Ex: RFC5844/MAG), then the updated properties can be provided as part of the new DHCP transaction. Some parameters such as MTU settings do change after an handover and so we can probably agree that address properties can change as well. Regards Sri I really don't think we should force DHCP to re-run on every handover. I thought one of the motivations for network-based mobility was to minimize the signaling to the MN during handover. -Pete ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] re-charter text updated
Ryuji, On Mar 20, 2014, at 4:55 PM, Ryuji Wakikawa ryuji.wakik...@gmail.com wrote: Jouni It’s good to see some room for non-MIP based solution in DMM;-) One clarification, the charter said following Specifically, when solutions are not based on IP mobility protocols, the DMM workingvgroup shall cooperate with other IETF working groups working on other technologies that might allow the mobility of an end host. These working groups include but are not limited to I2rs, Lisp, and Forces. If we need to extend existing non-MIP protocols, it is reasonable to do extension in the working group owning the protocol. I agree on the charter. However, DMM should work on documenting “how to use it”. The document should be informational or experimental. Is this scope of DMM? In a case some DMMish feature depends on a work done by other WG and it is used then in a DMM specific way, that should be documented in DMM document. This is specifically the case if the feature or extension done in other WG can be used also for other than DMM purposes. btw, you may add IDR in the listed of working group. Ok. - Jouni thanks ryuji 2014/03/17 午後3:41、Jouni Korhonen jouni.nos...@gmail.com のメール： Folks, I have updated the charter draft text slightly: https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt Basically: Added Sri's comment on PMIPv6 maintenance. Added Alper's comment of location of mobility functions. Added links to other IETF WGs on possible mobility enabling technologies. Added a comment that virtualised network functions are in scope. - Jouni ___ 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] re-charter text updated
Hi Jouni, On Mar 20, 2014, at 6:03 AM, Jouni Korhonen wrote: o Mobility state exposing I-D. This would communication between the end host and the network. Maybe also covering the missing parts within the end host.. Are we OK with one I-D or how people want to see this? o .. There's the API aspect on the terminal (one I-D), and there is the MN-network interface ones (e.g., extending RA, DHCP, etc.) So you want an API document? I have some reservations documenting an APIs as-is. Could this be an extension to RFC5014? I'd see this approach feasible since there are even (partial) implementations of the RFC5014 in popular operating systems. Yes, we are talking about extensions to source address selection (RFC 5014). Then the subsequent thing. Each MN-NW interface would be one document, if I understand the above comment correctly? Which one(s) to do first? ND or/and DHCP? Yes. Both. Alper - JOuni Alper - Jouni On Mar 17, 2014, at 2:41 PM, Jouni Korhonen jouni.nos...@gmail.com wrote: Folks, I have updated the charter draft text slightly: https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt Basically: Added Sri's comment on PMIPv6 maintenance. Added Alper's comment of location of mobility functions. Added links to other IETF WGs on possible mobility enabling technologies. Added a comment that virtualised network functions are in scope. - Jouni ___ 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] re-charter text updated
On Mar 20, 2014, at 2:58 PM, Alper Yegin alper.ye...@yegin.org wrote: Hi Jouni, On Mar 20, 2014, at 6:03 AM, Jouni Korhonen wrote: o Mobility state exposing I-D. This would communication between the end host and the network. Maybe also covering the missing parts within the end host.. Are we OK with one I-D or how people want to see this? o .. There's the API aspect on the terminal (one I-D), and there is the MN-network interface ones (e.g., extending RA, DHCP, etc.) So you want an API document? I have some reservations documenting an APIs as-is. Could this be an extension to RFC5014? I'd see this approach feasible since there are even (partial) implementations of the RFC5014 in popular operating systems. Yes, we are talking about extensions to source address selection (RFC 5014). Ack. Then the subsequent thing. Each MN-NW interface would be one document, if I understand the above comment correctly? Which one(s) to do first? ND or/and DHCP? Yes. Both. Ack. Since we are coming up with I-D numbers, any preference on the protocols that we patch..? - Jouni Alper - JOuni Alper - Jouni On Mar 17, 2014, at 2:41 PM, Jouni Korhonen jouni.nos...@gmail.com wrote: Folks, I have updated the charter draft text slightly: https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt Basically: Added Sri's comment on PMIPv6 maintenance. Added Alper's comment of location of mobility functions. Added links to other IETF WGs on possible mobility enabling technologies. Added a comment that virtualised network functions are in scope. - Jouni ___ 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] re-charter text updated
-Message d'origine- De : dmm [mailto:dmm-boun...@ietf.org] De la part de Alper Yegin Envoyé : jeudi 20 mars 2014 09:42 À : Jouni Korhonen Cc : dmm@ietf.org Objet : Re: [DMM] re-charter text updated On Mar 20, 2014, at 10:30 AM, Jouni Korhonen wrote: On Mar 20, 2014, at 2:58 PM, Alper Yegin alper.ye...@yegin.org wrote: Hi Jouni, On Mar 20, 2014, at 6:03 AM, Jouni Korhonen wrote: o Mobility state exposing I-D. This would communication between the end host and the network. Maybe also covering the missing parts within the end host.. Are we OK with one I-D or how people want to see this? o .. There's the API aspect on the terminal (one I-D), and there is the MN-network interface ones (e.g., extending RA, DHCP, etc.) So you want an API document? I have some reservations documenting an APIs as-is. Could this be an extension to RFC5014? I'd see this approach feasible since there are even (partial) implementations of the RFC5014 in popular operating systems. Yes, we are talking about extensions to source address selection (RFC 5014). Ack. Then the subsequent thing. Each MN-NW interface would be one document, if I understand the above comment correctly? Which one(s) to do first? ND or/and DHCP? Yes. Both. Ack. Since we are coming up with I-D numbers, any preference on the protocols that we patch..? between ND and DHCP? DHCP.. I'd say ND first :-)... but, anyway, do we really need two different documents? Although, container differs, I guess extensions will be the same. Alper - Jouni Alper - JOuni Alper - Jouni On Mar 17, 2014, at 2:41 PM, Jouni Korhonen jouni.nos...@gmail.com wrote: Folks, I have updated the charter draft text slightly: https://github.com/jounikor/dmm-re- charter/blob/master/recharter_ draft.txt Basically: Added Sri's comment on PMIPv6 maintenance. Added Alper's comment of location of mobility functions. Added links to other IETF WGs on possible mobility enabling technologies. Added a comment that virtualised network functions are in scope. - Jouni ___ 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 _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] re-charter text updated
On Mar 20, 2014, at 4:44 PM, pierrick.se...@orange.com wrote: -Message d'origine- De : dmm [mailto:dmm-boun...@ietf.org] De la part de Alper Yegin Envoyé : jeudi 20 mars 2014 09:42 À : Jouni Korhonen Cc : dmm@ietf.org Objet : Re: [DMM] re-charter text updated On Mar 20, 2014, at 10:30 AM, Jouni Korhonen wrote: On Mar 20, 2014, at 2:58 PM, Alper Yegin alper.ye...@yegin.org wrote: Hi Jouni, On Mar 20, 2014, at 6:03 AM, Jouni Korhonen wrote: o Mobility state exposing I-D. This would communication between the end host and the network. Maybe also covering the missing parts within the end host.. Are we OK with one I-D or how people want to see this? o .. There's the API aspect on the terminal (one I-D), and there is the MN-network interface ones (e.g., extending RA, DHCP, etc.) So you want an API document? I have some reservations documenting an APIs as-is. Could this be an extension to RFC5014? I'd see this approach feasible since there are even (partial) implementations of the RFC5014 in popular operating systems. Yes, we are talking about extensions to source address selection (RFC 5014). Ack. Then the subsequent thing. Each MN-NW interface would be one document, if I understand the above comment correctly? Which one(s) to do first? ND or/and DHCP? Yes. Both. Ack. Since we are coming up with I-D numbers, any preference on the protocols that we patch..? between ND and DHCP? DHCP.. I'd say ND first :-)... but, anyway, do we really need two different documents? Although, container differs, I guess extensions will be the same. Second the ND thing ;) Why two docs.. DHCP is usually easy going as you can practically shove a flock of pigeons into it and people are just fine. ND is always a different story ;) - JOuni Alper - Jouni Alper - JOuni Alper - Jouni On Mar 17, 2014, at 2:41 PM, Jouni Korhonen jouni.nos...@gmail.com wrote: Folks, I have updated the charter draft text slightly: https://github.com/jounikor/dmm-re- charter/blob/master/recharter_ draft.txt Basically: Added Sri's comment on PMIPv6 maintenance. Added Alper's comment of location of mobility functions. Added links to other IETF WGs on possible mobility enabling technologies. Added a comment that virtualised network functions are in scope. - Jouni ___ 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 _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] re-charter text updated
+1 Regards, Behcet On Thu, Mar 20, 2014 at 3:55 AM, Ryuji Wakikawa ryuji.wakik...@gmail.comwrote: Jouni It’s good to see some room for non-MIP based solution in DMM;-) One clarification, the charter said following Specifically, when solutions are not based on IP mobility protocols, the DMM workingvgroup shall cooperate with other IETF working groups working on other technologies that might allow the mobility of an end host. These working groups include but are not limited to I2rs, Lisp, and Forces. If we need to extend existing non-MIP protocols, it is reasonable to do extension in the working group owning the protocol. I agree on the charter. However, DMM should work on documenting “how to use it”. The document should be informational or experimental. Is this scope of DMM? btw, you may add IDR in the listed of working group. thanks ryuji 2014/03/17 午後3:41、Jouni Korhonen jouni.nos...@gmail.com のメール： Folks, I have updated the charter draft text slightly: https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt Basically: Added Sri's comment on PMIPv6 maintenance. Added Alper's comment of location of mobility functions. Added links to other IETF WGs on possible mobility enabling technologies. Added a comment that virtualised network functions are in scope. - Jouni ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] re-charter text updated
-Message d'origine- De : Jouni Korhonen [mailto:jouni.nos...@gmail.com] Envoyé : jeudi 20 mars 2014 10:00 À : SEITE Pierrick IMT/OLN Cc : Alper Yegin; dmm@ietf.org Objet : Re: [DMM] re-charter text updated On Mar 20, 2014, at 4:44 PM, pierrick.se...@orange.com wrote: -Message d'origine- De : dmm [mailto:dmm-boun...@ietf.org] De la part de Alper Yegin Envoyé : jeudi 20 mars 2014 09:42 À : Jouni Korhonen Cc : dmm@ietf.org Objet : Re: [DMM] re-charter text updated On Mar 20, 2014, at 10:30 AM, Jouni Korhonen wrote: On Mar 20, 2014, at 2:58 PM, Alper Yegin alper.ye...@yegin.org wrote: Hi Jouni, On Mar 20, 2014, at 6:03 AM, Jouni Korhonen wrote: o Mobility state exposing I-D. This would communication between the end host and the network. Maybe also covering the missing parts within the end host.. Are we OK with one I-D or how people want to see this? o .. There's the API aspect on the terminal (one I-D), and there is the MN-network interface ones (e.g., extending RA, DHCP, etc.) So you want an API document? I have some reservations documenting an APIs as-is. Could this be an extension to RFC5014? I'd see this approach feasible since there are even (partial) implementations of the RFC5014 in popular operating systems. Yes, we are talking about extensions to source address selection (RFC 5014). Ack. Then the subsequent thing. Each MN-NW interface would be one document, if I understand the above comment correctly? Which one(s) to do first? ND or/and DHCP? Yes. Both. Ack. Since we are coming up with I-D numbers, any preference on the protocols that we patch..? between ND and DHCP? DHCP.. I'd say ND first :-)... but, anyway, do we really need two different documents? Although, container differs, I guess extensions will be the same. Second the ND thing ;) Why two docs.. DHCP is usually easy going as you can practically shove a flock of pigeons into it and people are just fine. ND is always a different story ;) Ok, I got it... - JOuni Alper - Jouni Alper - JOuni Alper - Jouni On Mar 17, 2014, at 2:41 PM, Jouni Korhonen jouni.nos...@gmail.com wrote: Folks, I have updated the charter draft text slightly: https://github.com/jounikor/dmm-re- charter/blob/master/recharter_ draft.txt Basically: Added Sri's comment on PMIPv6 maintenance. Added Alper's comment of location of mobility functions. Added links to other IETF WGs on possible mobility enabling technologies. Added a comment that virtualised network functions are in scope. - Jouni ___ 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 ___ ___ ___ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] re-charter text updated
I think our extensions should be to the prefix information option and not DHCP. The properties of an address may change after a handover and we should not couple the DHCP state machine (which is about lease renewal) to the handover state machine. -Pete pierrick.se...@orange.com wrote: -Message d'origine- De : Jouni Korhonen [mailto:jouni.nos...@gmail.com] Envoyé : jeudi 20 mars 2014 10:00 À : SEITE Pierrick IMT/OLN Cc : Alper Yegin; dmm@ietf.org Objet : Re: [DMM] re-charter text updated On Mar 20, 2014, at 4:44 PM, pierrick.se...@orange.com wrote: -Message d'origine- De : dmm [mailto:dmm-boun...@ietf.org] De la part de Alper Yegin Envoyé : jeudi 20 mars 2014 09:42 À : Jouni Korhonen Cc : dmm@ietf.org Objet : Re: [DMM] re-charter text updated On Mar 20, 2014, at 10:30 AM, Jouni Korhonen wrote: On Mar 20, 2014, at 2:58 PM, Alper Yegin alper.ye...@yegin.org wrote: Hi Jouni, On Mar 20, 2014, at 6:03 AM, Jouni Korhonen wrote: o Mobility state exposing I-D. This would communication between the end host and the network. Maybe also covering the missing parts within the end host.. Are we OK with one I-D or how people want to see this? o .. There's the API aspect on the terminal (one I-D), and there is the MN-network interface ones (e.g., extending RA, DHCP, etc.) So you want an API document? I have some reservations documenting an APIs as-is. Could this be an extension to RFC5014? I'd see this approach feasible since there are even (partial) implementations of the RFC5014 in popular operating systems. Yes, we are talking about extensions to source address selection (RFC 5014). Ack. Then the subsequent thing. Each MN-NW interface would be one document, if I understand the above comment correctly? Which one(s) to do first? ND or/and DHCP? Yes. Both. Ack. Since we are coming up with I-D numbers, any preference on the protocols that we patch..? between ND and DHCP? DHCP.. I'd say ND first :-)... but, anyway, do we really need two different documents? Although, container differs, I guess extensions will be the same. Second the ND thing ;) Why two docs.. DHCP is usually easy going as you can practically shove a flock of pigeons into it and people are just fine. ND is always a different story ;) Ok, I got it... - JOuni Alper - Jouni Alper - JOuni Alper - Jouni On Mar 17, 2014, at 2:41 PM, Jouni Korhonen jouni.nos...@gmail.com wrote: Folks, I have updated the charter draft text slightly: https://github.com/jounikor/dmm-re- charter/blob/master/recharter_ draft.txt Basically: Added Sri's comment on PMIPv6 maintenance. Added Alper's comment of location of mobility functions. Added links to other IETF WGs on possible mobility enabling technologies. Added a comment that virtualised network functions are in scope. - Jouni ___ 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 ___ ___ ___ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. __ _ __ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used
Re: [DMM] re-charter text updated
On 3/20/14 5:54 AM, Peter McCann peter.mcc...@huawei.com wrote: I think our extensions should be to the prefix information option and not DHCP. The properties of an address may change after a handover and we should not couple the DHCP state machine (which is about lease renewal) to the handover state machine. Hi Pete, This is a good comment. If we are making any assumption that even after a handover, the DHCP transactions are still hitting the same DHCP server node, this may be a valid concern. But, if DHCP transactions are locally terminated after handover (Ex: RFC5844/MAG), then the updated properties can be provided as part of the new DHCP transaction. Some parameters such as MTU settings do change after an handover and so we can probably agree that address properties can change as well. Regards Sri ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] re-charter text updated
I split the gateway selection re-anchoring. Goals and Milestones: aaa 2014 - Submit 'The deployment models and scenarios' as a working group document. To be Informational RFC. bbb 2014 - Submit 'Enhanced gateway and mobility anchor selection' as a working group document. To be Proposed Standard. ccc 2014 - Submit 'Gateway and mobility anchor re-selection' as a working group document. To be Proposed Standard. - JOuni On Mar 18, 2014, at 5:07 PM, Alper Yegin alper.ye...@yegin.org wrote: On Mar 18, 2014, at 4:20 AM, Jouni Korhonen wrote: Folks, Triggered by the question from Behcet, we should come up with the milestones. Few proposals: o The deployment models and scenarios I-D is obvious. o Anchor selection I-D is obvious. Could we also bundle the re-anchoring solution into this one or should it be a different I-D? I'd say re-anchoring is a separate I-D. Btw, I take anchor selection as the process/algorithm for selecting the type of anchor (e.g., one in access or core or corresponding network), and selecting a specific anchor node of that type (e.g., determining its IP address). If so, that can be an I-D. But then, how the data-path is setup and maintained between the MN and the anchor across handovers is another I-D. And in fact, that's where more than one solutions is likely…. So, limiting this as one I-D may not work. o Mobility state exposing I-D. This would communication between the end host and the network. Maybe also covering the missing parts within the end host.. Are we OK with one I-D or how people want to see this? o .. There's the API aspect on the terminal (one I-D), and there is the MN-network interface ones (e.g., extending RA, DHCP, etc.) Alper - Jouni On Mar 17, 2014, at 2:41 PM, Jouni Korhonen jouni.nos...@gmail.com wrote: Folks, I have updated the charter draft text slightly: https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt Basically: Added Sri's comment on PMIPv6 maintenance. Added Alper's comment of location of mobility functions. Added links to other IETF WGs on possible mobility enabling technologies. Added a comment that virtualised network functions are in scope. - Jouni ___ 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] re-charter text updated
Hi, Mobility issues are not specifically in MIF scope. So, as long as we are talking about exposing mobility state, the I-D should be in DMM. Another reason is that MIF is still discussing the generic MIF API, so, I'm not sure they can go on the mobility area before a while. Pierrick -Message d'origine- De : dmm [mailto:dmm-boun...@ietf.org] De la part de Zuniga, Juan Carlos Envoyé : mardi 18 mars 2014 05:08 À : Sri Gundavelli (sgundave); Jouni Korhonen; dmm@ietf.org Objet : Re: [DMM] re-charter text updated Hi, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Monday, March 17, 2014 11:49 PM To: Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] re-charter text updated On 3/17/14 7:20 PM, Jouni Korhonen jouni.nos...@gmail.com wrote: Folks, Triggered by the question from Behcet, we should come up with the milestones. Few proposals: o The deployment models and scenarios I-D is obvious. o Anchor selection I-D is obvious. Could we also bundle the re-anchoring solution into this one or should it be a different I-D? IMO, these are two different topics and can be kept as separate work items. Anchor selection is tied to access network, request path, policy, handovers and load on the target elements. The entity using the gateway selection can be a end point, a network node or a policy system. The bulk of the work is around laying out the considerations for gateway selection and specifying the logic. The selection to most part is about the assigning a gateway during initial session establishment. Session Re-anchoring is about moving a session state between gateways, after the session got established. It has impact on the forwarding plane and is more about a routing problem. But, you may argue this is also touching the aspect of gateway (re)-selection at a failure point. In this sense there is some relation there, but it depends on how the re-anchoring solution is specified. IMO, its better to track them as separate work items. [JCZ] +1 o Mobility state exposing I-D. This would communication between the end host and the network. Maybe also covering the missing parts within the end host.. Are we OK with one I-D or how people want to see this? Single ID is fine. [JCZ] Single ID is fine indeed. However, we still need to assess whether this will be a DMM or a MIF ID. Regards, Juan Carlos Regards Sri ___ 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 _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] re-charter text updated
Hi Jouni, Reading your milestones: Submit I-D 'Solution Requirements' to the IESG for consideration as an Informational RFC. Submit I-D 'Gap Analysis' to the IESG for consideration as an Informational RFC. I came to the conclusion that we are the loop doing the same or similar things over and over again. Why? Regards, Behcet On Mon, Mar 17, 2014 at 1:41 AM, Jouni Korhonen jouni.nos...@gmail.comwrote: Folks, I have updated the charter draft text slightly: https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt Basically: Added Sri's comment on PMIPv6 maintenance. Added Alper's comment of location of mobility functions. Added links to other IETF WGs on possible mobility enabling technologies. Added a comment that virtualised network functions are in scope. - Jouni ___ 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] re-charter text updated
On Mar 17, 2014, at 4:29 PM, Behcet Sarikaya sarikaya2...@gmail.com wrote: Hi Jouni, Reading your milestones: Submit I-D 'Solution Requirements' to the IESG for consideration as an Informational RFC. Submit I-D 'Gap Analysis' to the IESG for consideration as an Informational RFC. I came to the conclusion that we are the loop doing the same or similar things over and over again. Why? Because our text editing has not even reached milestones part of the charter text. That's why. - Jouni Regards, Behcet On Mon, Mar 17, 2014 at 1:41 AM, Jouni Korhonen jouni.nos...@gmail.com wrote: Folks, I have updated the charter draft text slightly: https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt Basically: Added Sri's comment on PMIPv6 maintenance. Added Alper's comment of location of mobility functions. Added links to other IETF WGs on possible mobility enabling technologies. Added a comment that virtualised network functions are in scope. - Jouni ___ 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] re-charter text updated
On 3/17/14 7:20 PM, Jouni Korhonen jouni.nos...@gmail.com wrote: Folks, Triggered by the question from Behcet, we should come up with the milestones. Few proposals: o The deployment models and scenarios I-D is obvious. o Anchor selection I-D is obvious. Could we also bundle the re-anchoring solution into this one or should it be a different I-D? IMO, these are two different topics and can be kept as separate work items. Anchor selection is tied to access network, request path, policy, handovers and load on the target elements. The entity using the gateway selection can be a end point, a network node or a policy system. The bulk of the work is around laying out the considerations for gateway selection and specifying the logic. The selection to most part is about the assigning a gateway during initial session establishment. Session Re-anchoring is about moving a session state between gateways, after the session got established. It has impact on the forwarding plane and is more about a routing problem. But, you may argue this is also touching the aspect of gateway (re)-selection at a failure point. In this sense there is some relation there, but it depends on how the re-anchoring solution is specified. IMO, its better to track them as separate work items. o Mobility state exposing I-D. This would communication between the end host and the network. Maybe also covering the missing parts within the end host.. Are we OK with one I-D or how people want to see this? Single ID is fine. Regards Sri ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
