Re: [DMM] regarding the re-chartering..
No issue with logical vs. physical ID. But I am wondering about two things: Operation is clear to me in case a single MNID is present in a message and I see the value in being flexible to choose from different sub-types. If multiple MNIDs with different sub-types are present in a single message, which one should e.g. the LMA take for the BC lookup.. No big problem to solve, but to be considered in implementations. If the reason for multiple present MNIDs with different sub-types is to do other things than identifying the node or using the ID as key for a lookup, I am wondering if it would not be more appropriate to go for a different container option to carry such information. Something like a complementary identifier option. marco -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Donnerstag, 11. September 2014 00:42 To: Charlie Perkins; Marco Liebsch; dmm@ietf.org Cc: Vijay Devarapalli Subject: Re: [DMM] regarding the re-chartering.. Hello Charlie, Agree with that. MN-Id as its defined today is a logical identifier. It does not require the identifier to be bound to a physical device or a interface identity. But, we have clearly seen requirements where the need is for generating identifiers based on some physical identifiers. Those physical identifiers include IMSI, MSISDN, IMEI, MAC ..etc. If we can define a type for each of the source and the rules for generating MN-ID based using those sources, the sender and receiver will have clear guidance on how to use the spec. Some pointers, explanation and examples for each of those identifiers will greatly help avoid inter-op issues. Regards Sri On 9/10/14 3:21 PM, Charlie Perkins charles.perk...@earthlink.net wrote: Hello folks, I think it's best to consider the MNID as simply living in a space of identifiers, and not worry too much about whether it's a logical identifier or a physical identifier. If the former, then somewhere (perhaps below the network layer) the logical identifier has been bound to something in the physical interface, but that's not our problem. The number space for types of MNIDs is likely to stay pretty empty, so I'd say we could add as many types as would be convenient for the software designers. So, we could conceivably have several MNIDs defined that all looked like NAIs (which, themselves, look like FQDNs). Regards, Charlie P. On 9/10/2014 8:11 AM, Sri Gundavelli (sgundave) wrote: Yes. Currently, the MNID is if the nai format and is overloaded. The MNID in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the IMSI. Ex: IMSI@epc.mncMNC.mccMCC.3gppnetwork.org² We also have MAC48@REALM; We also have approaches to transform MAC to Pseudo IMSI, and then carry IMSI-NAI as the MN-ID. So, we need unique sub-types for each of the types/sources. MN-Id based on IMSI, MSISDN, IMEI, MAC .. Also, do we need to distinguish between IMSI and IMSI-NAI ? Sri On 9/10/14 6:29 AM, Marco Liebsch marco.lieb...@neclab.eu wrote: It seems the MNID is somehow overloaded to carry both, node-specific IDs, e.g. MAC, as well as subscriber IDs, which is the IMSI. There may be value in adding the IMEI to the list of possible types of node-specific IDs. marco -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Dienstag, 9. September 2014 23:30 To: Sri Gundavelli (sgundave); Charlie Perkins; dmm@ietf.org Cc: Vijay Devarapalli Subject: Re: [DMM] regarding the re-chartering.. Two more comments. 4.) I'd also use sub-type value of (2) for IMSI. Just to align with the sub-types defined for MN Id defined for ICMP. I suspect there are some implementations already using sub-type (2). Please see the other thread. 5.) For each of the sub-types, we need text including examples and some explanation on how they are used. Sri On 9/9/14 2:20 PM, Sri Gundavelli (sgundave) sgund...@cisco.com wrote: Hi Charlie, This is good. Thanks. 1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE 802.2 address, why do we need to two sub-types ? Why not have just one sub-type for mac based identifiers ? 2.) Sub type value (1) is currently used. Its currently overloaded for IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the definition of new sub-types, we need some text explaining the motivation 3.) Proposed Sub-type value of (2) for IPv6 address. What exactly is this ? Are these CGA-based IPv6 addresses ? New Mobile Node Identifier Types +-++ | Identifier Type | Identifier Type Number | +-++ | IPv6 Address| 2 | | || | IMSI| 3
Re: [DMM] regarding the re-chartering..
I do not see a reason why multiple MN-Id instances need to be present in a single message ? In my experience, this is strictly a deployment consideration, when to use what type of identifiers. Assuming the backend system can tie all the MN-Id's to a single subscription, any presented identifier can be sufficient for the gateway to do the BCE lookup. If multiple instances can be present, then we need to deal with more error cases. Is that really needed ? I am wondering if it would not be more appropriate to go for a different container option to carry such information. Something like a complementary identifier option. Sounds interesting. Are you suggesting we leave the current MN-ID as it is, but use a new complementary option ? But, if the requirement is for a Mac based identifiers, what will be there in the current MN-Id option ? We still need to have identifier there ? Sri On 9/11/14 2:03 AM, Marco Liebsch marco.lieb...@neclab.eu wrote: No issue with logical vs. physical ID. But I am wondering about two things: Operation is clear to me in case a single MNID is present in a message and I see the value in being flexible to choose from different sub-types. If multiple MNIDs with different sub-types are present in a single message, which one should e.g. the LMA take for the BC lookup.. No big problem to solve, but to be considered in implementations. If the reason for multiple present MNIDs with different sub-types is to do other things than identifying the node or using the ID as key for a lookup, I am wondering if it would not be more appropriate to go for a different container option to carry such information. Something like a complementary identifier option. marco -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Donnerstag, 11. September 2014 00:42 To: Charlie Perkins; Marco Liebsch; dmm@ietf.org Cc: Vijay Devarapalli Subject: Re: [DMM] regarding the re-chartering.. Hello Charlie, Agree with that. MN-Id as its defined today is a logical identifier. It does not require the identifier to be bound to a physical device or a interface identity. But, we have clearly seen requirements where the need is for generating identifiers based on some physical identifiers. Those physical identifiers include IMSI, MSISDN, IMEI, MAC ..etc. If we can define a type for each of the source and the rules for generating MN-ID based using those sources, the sender and receiver will have clear guidance on how to use the spec. Some pointers, explanation and examples for each of those identifiers will greatly help avoid inter-op issues. Regards Sri On 9/10/14 3:21 PM, Charlie Perkins charles.perk...@earthlink.net wrote: Hello folks, I think it's best to consider the MNID as simply living in a space of identifiers, and not worry too much about whether it's a logical identifier or a physical identifier. If the former, then somewhere (perhaps below the network layer) the logical identifier has been bound to something in the physical interface, but that's not our problem. The number space for types of MNIDs is likely to stay pretty empty, so I'd say we could add as many types as would be convenient for the software designers. So, we could conceivably have several MNIDs defined that all looked like NAIs (which, themselves, look like FQDNs). Regards, Charlie P. On 9/10/2014 8:11 AM, Sri Gundavelli (sgundave) wrote: Yes. Currently, the MNID is if the nai format and is overloaded. The MNID in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the IMSI. Ex: IMSI@epc.mncMNC.mccMCC.3gppnetwork.org² We also have MAC48@REALM; We also have approaches to transform MAC to Pseudo IMSI, and then carry IMSI-NAI as the MN-ID. So, we need unique sub-types for each of the types/sources. MN-Id based on IMSI, MSISDN, IMEI, MAC .. Also, do we need to distinguish between IMSI and IMSI-NAI ? Sri On 9/10/14 6:29 AM, Marco Liebsch marco.lieb...@neclab.eu wrote: It seems the MNID is somehow overloaded to carry both, node-specific IDs, e.g. MAC, as well as subscriber IDs, which is the IMSI. There may be value in adding the IMEI to the list of possible types of node-specific IDs. marco -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Dienstag, 9. September 2014 23:30 To: Sri Gundavelli (sgundave); Charlie Perkins; dmm@ietf.org Cc: Vijay Devarapalli Subject: Re: [DMM] regarding the re-chartering.. Two more comments. 4.) I'd also use sub-type value of (2) for IMSI. Just to align with the sub-types defined for MN Id defined for ICMP. I suspect there are some implementations already using sub-type (2). Please see the other thread. 5.) For each of the sub-types, we need text including examples and some explanation on how they are used. Sri On 9/9/14 2:20 PM, Sri Gundavelli (sgundave) sgund...@cisco.com wrote: Hi Charlie, This is good. Thanks. 1.) If EUI
Re: [DMM] regarding the re-chartering..
It seems the MNID is somehow overloaded to carry both, node-specific IDs, e.g. MAC, as well as subscriber IDs, which is the IMSI. There may be value in adding the IMEI to the list of possible types of node-specific IDs. marco -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Dienstag, 9. September 2014 23:30 To: Sri Gundavelli (sgundave); Charlie Perkins; dmm@ietf.org Cc: Vijay Devarapalli Subject: Re: [DMM] regarding the re-chartering.. Two more comments. 4.) I'd also use sub-type value of (2) for IMSI. Just to align with the sub-types defined for MN Id defined for ICMP. I suspect there are some implementations already using sub-type (2). Please see the other thread. 5.) For each of the sub-types, we need text including examples and some explanation on how they are used. Sri On 9/9/14 2:20 PM, Sri Gundavelli (sgundave) sgund...@cisco.com wrote: Hi Charlie, This is good. Thanks. 1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE 802.2 address, why do we need to two sub-types ? Why not have just one sub-type for mac based identifiers ? 2.) Sub type value (1) is currently used. Its currently overloaded for IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the definition of new sub-types, we need some text explaining the motivation 3.) Proposed Sub-type value of (2) for IPv6 address. What exactly is this ? Are these CGA-based IPv6 addresses ? New Mobile Node Identifier Types +-++ | Identifier Type | Identifier Type Number | +-++ | IPv6 Address| 2 | | || | IMSI| 3 | | || | P-TMSI | 4 | | || | EUI-48 address | 5 | | || | EUI-64 address | 6 | | || | GUTI| 7 | +-++ Regards Sri PS: Good to see Vijay back On 9/9/14 1:28 PM, Charlie Perkins charles.perk...@earthlink.net wrote: Hello folks, Here's the last Internet Draft that we did, long ago expired: http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt I'll resubmit it with a few updates as a personal draft to dmm. Regards, Charlie P. ___ 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] regarding the re-chartering..
Yes. Currently, the MNID is if the nai format and is overloaded. The MNID in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the IMSI. Ex: IMSI@epc.mncMNC.mccMCC.3gppnetwork.org² We also have MAC48@REALM; We also have approaches to transform MAC to Pseudo IMSI, and then carry IMSI-NAI as the MN-ID. So, we need unique sub-types for each of the types/sources. MN-Id based on IMSI, MSISDN, IMEI, MAC .. Also, do we need to distinguish between IMSI and IMSI-NAI ? Sri On 9/10/14 6:29 AM, Marco Liebsch marco.lieb...@neclab.eu wrote: It seems the MNID is somehow overloaded to carry both, node-specific IDs, e.g. MAC, as well as subscriber IDs, which is the IMSI. There may be value in adding the IMEI to the list of possible types of node-specific IDs. marco -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Dienstag, 9. September 2014 23:30 To: Sri Gundavelli (sgundave); Charlie Perkins; dmm@ietf.org Cc: Vijay Devarapalli Subject: Re: [DMM] regarding the re-chartering.. Two more comments. 4.) I'd also use sub-type value of (2) for IMSI. Just to align with the sub-types defined for MN Id defined for ICMP. I suspect there are some implementations already using sub-type (2). Please see the other thread. 5.) For each of the sub-types, we need text including examples and some explanation on how they are used. Sri On 9/9/14 2:20 PM, Sri Gundavelli (sgundave) sgund...@cisco.com wrote: Hi Charlie, This is good. Thanks. 1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE 802.2 address, why do we need to two sub-types ? Why not have just one sub-type for mac based identifiers ? 2.) Sub type value (1) is currently used. Its currently overloaded for IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the definition of new sub-types, we need some text explaining the motivation 3.) Proposed Sub-type value of (2) for IPv6 address. What exactly is this ? Are these CGA-based IPv6 addresses ? New Mobile Node Identifier Types +-++ | Identifier Type | Identifier Type Number | +-++ | IPv6 Address| 2 | | || | IMSI| 3 | | || | P-TMSI | 4 | | || | EUI-48 address | 5 | | || | EUI-64 address | 6 | | || | GUTI| 7 | +-++ Regards Sri PS: Good to see Vijay back On 9/9/14 1:28 PM, Charlie Perkins charles.perk...@earthlink.net wrote: Hello folks, Here's the last Internet Draft that we did, long ago expired: http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt I'll resubmit it with a few updates as a personal draft to dmm. Regards, Charlie P. ___ 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] regarding the re-chartering..
Hi Suresh, Thanks. That makes sense. Now, I remember that spec/update. The option name conflict and my search not finding 4283 references threw me off. Thanks. No comments on that one :-) :) Regards Sri On 9/9/14 10:39 AM, Suresh Krishnan suresh.krish...@ericsson.com wrote: Hi Sri, On 09/09/2014 10:11 AM, Sri Gundavelli (sgundave) wrote: This is bit strange. Some thing changed in the IANA Mobile Node Identifier pages. I assumed the MN Id was defined in RFC4283. How come I see a definition in 5271 as well. Confused. Jouni / Brian Any ideas ? Unless, I've been smoking Š No comments on that one :-). There are indeed two definitions of the MNID types. The one you originally saw is for the mobility option and is available in the mobility parameters registry http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xh tml#mobility-parameters-5 The second one you saw is for the *ND option* to carry MNID from the ICMPv6 parameters registry http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml# icmpv6-parameters-5 Thanks Suresh ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] regarding the re-chartering..
Hi Brian, It might worth adding a note in the IANA page. I will send a request to IANA. We refer to the Mobile Node Identifier option in all MIP/PMIP specs and the search from IANA page ends in the Mobile Node Identifier option defined for ICMP. Regards Sri On 9/9/14 11:48 AM, Brian Haberman br...@innovationslab.net wrote: Sri, On 9/9/14 2:09 PM, Sri Gundavelli (sgundave) wrote: Hi Suresh, Thanks. That makes sense. Now, I remember that spec/update. The option name conflict and my search not finding 4283 references threw me off. Thanks. If this is *really* confusing, it may be worth updating the name of one of them. Not sure if it is or not... Brian ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] regarding the re-chartering..
Hello folks, Here's the last Internet Draft that we did, long ago expired: http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt I'll resubmit it with a few updates as a personal draft to dmm. Regards, Charlie P. On 9/9/2014 2:04 AM, pierrick.se...@orange.com wrote: Hi, I second Charlie on this proposal, especially on the need for additional MNID and tunnel types. Another example for the latter is: using GRE with MIP/NEMO. BR, Pierrick -Message d'origine- De : dmm [mailto:dmm-boun...@ietf.org] De la part de Charlie Perkins Envoyé : lundi 8 septembre 2014 19:50 À : MONGAZON-CAZAVET, BRUNO (BRUNO); dmm@ietf.org Objet : Re: [DMM] regarding the re-chartering.. Hello folks, I'll go look for the link(s). But in the meantime, as part of the ongoing maintenance work, I'd be happy to see the following: - Additional tunnel types (including GTP) - Additional mobile node identifier types (including IMSI, MAC, ...) - Additional security mechanisms If there is a sliver of a chance that we could go down any one or more of these paths, I will resurrect the old Internet drafts as well. If people are interested, I will re-submit them for the November meeting. There are two or three other things that Mobile IP needs also, that take more words to express, but not necessarily directly related to distributed mobility management. Much of my development had to do with trying to provide an easier / incremental path for the deployment of Mobile IP by SDO partners in 3GPP, which would necessitate inclusion in their standards, which (for instance) seems to necessitate GTP as a tunneling protocol, etc. Regards, Charlie P. On 9/7/2014 11:57 PM, MONGAZON-CAZAVET, BRUNO (BRUNO) wrote: On 05/09/2014 19:10, Charlie Perkins wrote: Hello folks, I have made various presentations at IETF, some from many years ago, proposing that Mobile IP enable use of GTP as a tunneling option. I still think that would be a good idea. Should I re-re-revive a draft stating this in more detail? I would be interested to look at this draft. Thanks. Bruno Regards, Charlie P. On 9/5/2014 1:48 AM, Alper Yegin wrote: Alex, DMM is not meant to be only about a bunch of MIP-based solutions. There are various components in DMM solution space that'd also work with GTP-based architectures. For example, identifying the mobility needs of flows. Or, conveying the mobility characteristic of a prefix to the UE. Alper On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: Le 03/09/2014 20:53, Brian Haberman a écrit : Behcet, On 9/3/14 2:33 PM, Behcet Sarikaya wrote: You don't seem to understand my points. That is quite possible. Your comment on the list was I am against any deployment work before we decide on a solution... I read that as an objection to having the deployment models work item on the agenda. Please do tell me what I am missing. Regards, Brian Hi, I am following the discussion and me too I do not quite understand what is the complain. I am happy to learn that a if a WG is to be formed then it would be around a solution rather than just requirements or architecture. That said, I would like to express a worry along similar lines. In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted disconnect between the product developped - (P)Mobile IP - and the deployments. We know for a fact that 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do mention Mobile IP. To such a point that I wonder whether 3GPP has not the same disconnect as here. On another hand, we do have indications of where (P)Mobile IP is used - the trials, the projects, the kernel code, and not least the slideware attracting real customers. The worry: develop DMM protocol while continuing the disconnect. Alex ___ 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 ___ 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 _ 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
Re: [DMM] regarding the re-chartering..
Hi Charlie, This is good. Thanks. 1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE 802.2 address, why do we need to two sub-types ? Why not have just one sub-type for mac based identifiers ? 2.) Sub type value (1) is currently used. Its currently overloaded for IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the definition of new sub-types, we need some text explaining the motivation 3.) Proposed Sub-type value of (2) for IPv6 address. What exactly is this ? Are these CGA-based IPv6 addresses ? New Mobile Node Identifier Types +-++ | Identifier Type | Identifier Type Number | +-++ | IPv6 Address| 2 | | || | IMSI| 3 | | || | P-TMSI | 4 | | || | EUI-48 address | 5 | | || | EUI-64 address | 6 | | || | GUTI| 7 | +-++ Regards Sri PS: Good to see Vijay back On 9/9/14 1:28 PM, Charlie Perkins charles.perk...@earthlink.net wrote: Hello folks, Here's the last Internet Draft that we did, long ago expired: http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt I'll resubmit it with a few updates as a personal draft to dmm. Regards, Charlie P. ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] regarding the re-chartering..
Two more comments. 4.) I'd also use sub-type value of (2) for IMSI. Just to align with the sub-types defined for MN Id defined for ICMP. I suspect there are some implementations already using sub-type (2). Please see the other thread. 5.) For each of the sub-types, we need text including examples and some explanation on how they are used. Sri On 9/9/14 2:20 PM, Sri Gundavelli (sgundave) sgund...@cisco.com wrote: Hi Charlie, This is good. Thanks. 1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE 802.2 address, why do we need to two sub-types ? Why not have just one sub-type for mac based identifiers ? 2.) Sub type value (1) is currently used. Its currently overloaded for IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the definition of new sub-types, we need some text explaining the motivation 3.) Proposed Sub-type value of (2) for IPv6 address. What exactly is this ? Are these CGA-based IPv6 addresses ? New Mobile Node Identifier Types +-++ | Identifier Type | Identifier Type Number | +-++ | IPv6 Address| 2 | | || | IMSI| 3 | | || | P-TMSI | 4 | | || | EUI-48 address | 5 | | || | EUI-64 address | 6 | | || | GUTI| 7 | +-++ Regards Sri PS: Good to see Vijay back On 9/9/14 1:28 PM, Charlie Perkins charles.perk...@earthlink.net wrote: Hello folks, Here's the last Internet Draft that we did, long ago expired: http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt I'll resubmit it with a few updates as a personal draft to dmm. Regards, Charlie P. ___ 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] regarding the re-chartering..
Hello folks, I'll go look for the link(s). But in the meantime, as part of the ongoing maintenance work, I'd be happy to see the following: - Additional tunnel types (including GTP) - Additional mobile node identifier types (including IMSI, MAC, ...) - Additional security mechanisms If there is a sliver of a chance that we could go down any one or more of these paths, I will resurrect the old Internet drafts as well. If people are interested, I will re-submit them for the November meeting. There are two or three other things that Mobile IP needs also, that take more words to express, but not necessarily directly related to distributed mobility management. Much of my development had to do with trying to provide an easier / incremental path for the deployment of Mobile IP by SDO partners in 3GPP, which would necessitate inclusion in their standards, which (for instance) seems to necessitate GTP as a tunneling protocol, etc. Regards, Charlie P. On 9/7/2014 11:57 PM, MONGAZON-CAZAVET, BRUNO (BRUNO) wrote: On 05/09/2014 19:10, Charlie Perkins wrote: Hello folks, I have made various presentations at IETF, some from many years ago, proposing that Mobile IP enable use of GTP as a tunneling option. I still think that would be a good idea. Should I re-re-revive a draft stating this in more detail? I would be interested to look at this draft. Thanks. Bruno Regards, Charlie P. On 9/5/2014 1:48 AM, Alper Yegin wrote: Alex, DMM is not meant to be only about a bunch of MIP-based solutions. There are various components in DMM solution space that'd also work with GTP-based architectures. For example, identifying the mobility needs of flows. Or, conveying the mobility characteristic of a prefix to the UE. Alper On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: Le 03/09/2014 20:53, Brian Haberman a écrit : Behcet, On 9/3/14 2:33 PM, Behcet Sarikaya wrote: You don't seem to understand my points. That is quite possible. Your comment on the list was I am against any deployment work before we decide on a solution... I read that as an objection to having the deployment models work item on the agenda. Please do tell me what I am missing. Regards, Brian Hi, I am following the discussion and me too I do not quite understand what is the complain. I am happy to learn that a if a WG is to be formed then it would be around a solution rather than just requirements or architecture. That said, I would like to express a worry along similar lines. In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted disconnect between the product developped - (P)Mobile IP - and the deployments. We know for a fact that 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do mention Mobile IP. To such a point that I wonder whether 3GPP has not the same disconnect as here. On another hand, we do have indications of where (P)Mobile IP is used - the trials, the projects, the kernel code, and not least the slideware attracting real customers. The worry: develop DMM protocol while continuing the disconnect. Alex ___ 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 ___ 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] regarding the re-chartering..
Alex, The most robust way is to let the application tell the IP stack. http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-02.txt Sounds reasonable. A complimentary means is to look at this as a source address selection problem: given two addresses configured on an interface (an IP address, and an IP address designated as CoA), the application selects the src address as the IP address if its flows are brief query/response (http), or it selects the src address as the CoA if its flows are longer timed (request of UDP stream, or TCP download). That's exactly the intention and the approach. This would need a means to designate to the stack an IP address as to be a 'CoA', or otherwise designate a prefix to be the 'home' prefix and, by deduction any address differing be the CoA. At a high-level, yes. If you've read the draft you'll see there are some details and extensions on top of that (such as it's not a simply matter of CoA vs HoA, but there are in fact 3 types of IP addresses, and also a required type IP address can be configured on-demand when needed). Alper Alex Alper Alex Alper On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: Le 03/09/2014 20:53, Brian Haberman a écrit : Behcet, On 9/3/14 2:33 PM, Behcet Sarikaya wrote: You don't seem to understand my points. That is quite possible. Your comment on the list was I am against any deployment work before we decide on a solution... I read that as an objection to having the deployment models work item on the agenda. Please do tell me what I am missing. Regards, Brian Hi, I am following the discussion and me too I do not quite understand what is the complain. I am happy to learn that a if a WG is to be formed then it would be around a solution rather than just requirements or architecture. That said, I would like to express a worry along similar lines. In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted disconnect between the product developped - (P)Mobile IP - and the deployments. We know for a fact that 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do mention Mobile IP. To such a point that I wonder whether 3GPP has not the same disconnect as here. On another hand, we do have indications of where (P)Mobile IP is used - the trials, the projects, the kernel code, and not least the slideware attracting real customers. The worry: develop DMM protocol while continuing the disconnect. Alex ___ 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] regarding the re-chartering..
Alex, DMM is not meant to be only about a bunch of MIP-based solutions. There are various components in DMM solution space that'd also work with GTP-based architectures. For example, identifying the mobility needs of flows. Or, conveying the mobility characteristic of a prefix to the UE. Alper On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: Le 03/09/2014 20:53, Brian Haberman a écrit : Behcet, On 9/3/14 2:33 PM, Behcet Sarikaya wrote: You don't seem to understand my points. That is quite possible. Your comment on the list was I am against any deployment work before we decide on a solution... I read that as an objection to having the deployment models work item on the agenda. Please do tell me what I am missing. Regards, Brian Hi, I am following the discussion and me too I do not quite understand what is the complain. I am happy to learn that a if a WG is to be formed then it would be around a solution rather than just requirements or architecture. That said, I would like to express a worry along similar lines. In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted disconnect between the product developped - (P)Mobile IP - and the deployments. We know for a fact that 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do mention Mobile IP. To such a point that I wonder whether 3GPP has not the same disconnect as here. On another hand, we do have indications of where (P)Mobile IP is used - the trials, the projects, the kernel code, and not least the slideware attracting real customers. The worry: develop DMM protocol while continuing the disconnect. Alex ___ 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] regarding the re-chartering..
From meeting minutes: (Jouni) I suggest that we left the bullet as a work item and we do not have explicit milestone for it. we can add this milestone when we actually see that there is something meaningful forming for that document. The decision at the meeting was to leave the work item in the charter, but not to associate a specific milestone with it until the WG sees what goes into that document. It was not fully clear what would be in that document, and it's a concern that the rest of the WG documents would be gated by such a document. Jouni's above suggestion is a good way forward IMO. Alper On Sep 3, 2014, at 9:53 PM, Brian Haberman wrote: Behcet, On 9/3/14 2:33 PM, Behcet Sarikaya wrote: You don't seem to understand my points. That is quite possible. Your comment on the list was I am against any deployment work before we decide on a solution... I read that as an objection to having the deployment models work item on the agenda. Please do tell me what I am missing. Regards, Brian ___ 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] regarding the re-chartering..
Hi Alex, On Sep 5, 2014, at 3:32 PM, Alexandru Petrescu wrote: Le 05/09/2014 10:48, Alper Yegin a écrit : Alex, DMM is not meant to be only about a bunch of MIP-based solutions. There are various components in DMM solution space that'd also work with GTP-based architectures. For example, identifying the mobility needs of flows. Or, conveying the mobility characteristic of a prefix to the UE. Alper - thanks for the reply. Identifying the mobility needs of flows assumes that IP flows _can_ be characterized, and then distinguished as mobile - or non-mobile. I think this is very hard to do, given the difficulty to write good firewall rules, and the difficulty of analyzing traffic dumps. For example, Netalyzr was written to tell whether or not one's computer is connected to the Internet. That report page has so many lines that it is hard to tell which part of it really means 'connected to the Internet'. The same problem may arise when trying to identify a particular 'flow'. The most robust way is to let the application tell the IP stack. http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-02.txt Alper Alex Alper On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: Le 03/09/2014 20:53, Brian Haberman a écrit : Behcet, On 9/3/14 2:33 PM, Behcet Sarikaya wrote: You don't seem to understand my points. That is quite possible. Your comment on the list was I am against any deployment work before we decide on a solution... I read that as an objection to having the deployment models work item on the agenda. Please do tell me what I am missing. Regards, Brian Hi, I am following the discussion and me too I do not quite understand what is the complain. I am happy to learn that a if a WG is to be formed then it would be around a solution rather than just requirements or architecture. That said, I would like to express a worry along similar lines. In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted disconnect between the product developped - (P)Mobile IP - and the deployments. We know for a fact that 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do mention Mobile IP. To such a point that I wonder whether 3GPP has not the same disconnect as here. On another hand, we do have indications of where (P)Mobile IP is used - the trials, the projects, the kernel code, and not least the slideware attracting real customers. The worry: develop DMM protocol while continuing the disconnect. Alex ___ 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] regarding the re-chartering..
Hello folks, I have made various presentations at IETF, some from many years ago, proposing that Mobile IP enable use of GTP as a tunneling option. I still think that would be a good idea. Should I re-re-revive a draft stating this in more detail? Regards, Charlie P. On 9/5/2014 1:48 AM, Alper Yegin wrote: Alex, DMM is not meant to be only about a bunch of MIP-based solutions. There are various components in DMM solution space that'd also work with GTP-based architectures. For example, identifying the mobility needs of flows. Or, conveying the mobility characteristic of a prefix to the UE. Alper On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: Le 03/09/2014 20:53, Brian Haberman a écrit : Behcet, On 9/3/14 2:33 PM, Behcet Sarikaya wrote: You don't seem to understand my points. That is quite possible. Your comment on the list was I am against any deployment work before we decide on a solution... I read that as an objection to having the deployment models work item on the agenda. Please do tell me what I am missing. Regards, Brian Hi, I am following the discussion and me too I do not quite understand what is the complain. I am happy to learn that a if a WG is to be formed then it would be around a solution rather than just requirements or architecture. That said, I would like to express a worry along similar lines. In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted disconnect between the product developped - (P)Mobile IP - and the deployments. We know for a fact that 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do mention Mobile IP. To such a point that I wonder whether 3GPP has not the same disconnect as here. On another hand, we do have indications of where (P)Mobile IP is used - the trials, the projects, the kernel code, and not least the slideware attracting real customers. The worry: develop DMM protocol while continuing the disconnect. Alex ___ 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 ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] regarding the re-chartering..
Le 03/09/2014 20:53, Brian Haberman a écrit : Behcet, On 9/3/14 2:33 PM, Behcet Sarikaya wrote: You don't seem to understand my points. That is quite possible. Your comment on the list was I am against any deployment work before we decide on a solution... I read that as an objection to having the deployment models work item on the agenda. Please do tell me what I am missing. Regards, Brian Hi, I am following the discussion and me too I do not quite understand what is the complain. I am happy to learn that a if a WG is to be formed then it would be around a solution rather than just requirements or architecture. That said, I would like to express a worry along similar lines. In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted disconnect between the product developped - (P)Mobile IP - and the deployments. We know for a fact that 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do mention Mobile IP. To such a point that I wonder whether 3GPP has not the same disconnect as here. On another hand, we do have indications of where (P)Mobile IP is used - the trials, the projects, the kernel code, and not least the slideware attracting real customers. The worry: develop DMM protocol while continuing the disconnect. Alex ___ 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] regarding the re-chartering..
Hello folks, I have asked this same question many times, in different words... Namely, if we design a solution that fits the requirements, and bridges the gaps as analyzed in the gap analysis document, have we succeeded? Or, is there a requirement for the work to be adopted by 3GPP? What if we design for IEEE 802 Wireless, which is currently carrying the preponderance of the world's wireless data, and will almost assuredly continue to carry a greater proportion? Regards Charlie P. On 9/4/2014 3:14 AM, Alexandru Petrescu wrote: Hi, In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted disconnect between the product developped - (P)Mobile IP - and the deployments. We know for a fact that 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do mention Mobile IP. To such a point that I wonder whether 3GPP has not the same disconnect as here. On another hand, we do have indications of where (P)Mobile IP is used - the trials, the projects, the kernel code, and not least the slideware attracting real customers. The worry: develop DMM protocol while continuing the disconnect. Alex ___ 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 -- Regards, Charlie P. ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] regarding the re-chartering..
On Sep 4, 2014, at 1:31 PM, Charles E. Perkins wrote: Hello folks, I have asked this same question many times, in different words... Namely, if we design a solution that fits the requirements, and bridges the gaps as analyzed in the gap analysis document, have we succeeded? Or, is there a requirement for the work to be adopted by 3GPP? It would be cool but not required. What if we design for IEEE 802 Wireless, which is currently carrying the preponderance of the world's wireless data, and will almost assuredly continue to carry a greater proportion? ..and if the solution were adopted that would count as a major success. - JOuni Regards Charlie P. On 9/4/2014 3:14 AM, Alexandru Petrescu wrote: Hi, In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted disconnect between the product developped - (P)Mobile IP - and the deployments. We know for a fact that 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do mention Mobile IP. To such a point that I wonder whether 3GPP has not the same disconnect as here. On another hand, we do have indications of where (P)Mobile IP is used - the trials, the projects, the kernel code, and not least the slideware attracting real customers. The worry: develop DMM protocol while continuing the disconnect. Alex ___ 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 -- Regards, Charlie P. ___ 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] regarding the re-chartering..
Le 04/09/2014 12:31, Jouni a écrit : [...] In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted disconnect between the product developped - (P)Mobile IP - and the deployments. We know for a fact that 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do mention Mobile IP. To such a point that I wonder whether 3GPP has not the same disconnect as here. There are LTE deployments using PMIP. Nation wide even. While not hugely popular, there are still serious commercial deployments. Jouni, I would truly appreciate to stand corrected because it would be a good example to tell other customers about the technology. But I am afraid that what you are saying is part of: the trials, the projects, the kernel code and not least the slideware attracting real customers. The nation-wide LTE IPv6 trial I am familiar with does not use PMIPv6. Alex On another hand, we do have indications of where (P)Mobile IP is used - the trials, the projects, the kernel code, and not least the slideware attracting real customers. The worry: develop DMM protocol while continuing the disconnect. DMM solutions are not predefined to be a (P)MIP extensions. - Jouni Alex ___ 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] regarding the re-chartering..
Hi Charlie, Check this out: http://tools.ietf.org/id/draft-sarikaya-dmm-for-wifi-00.txt Regards, Behcet On Thu, Sep 4, 2014 at 5:31 AM, Charles E. Perkins charl...@computer.org wrote: Hello folks, I have asked this same question many times, in different words... Namely, if we design a solution that fits the requirements, and bridges the gaps as analyzed in the gap analysis document, have we succeeded? Or, is there a requirement for the work to be adopted by 3GPP? What if we design for IEEE 802 Wireless, which is currently carrying the preponderance of the world's wireless data, and will almost assuredly continue to carry a greater proportion? Regards Charlie P. On 9/4/2014 3:14 AM, Alexandru Petrescu wrote: Hi, In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted disconnect between the product developped - (P)Mobile IP - and the deployments. We know for a fact that 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do mention Mobile IP. To such a point that I wonder whether 3GPP has not the same disconnect as here. On another hand, we do have indications of where (P)Mobile IP is used - the trials, the projects, the kernel code, and not least the slideware attracting real customers. The worry: develop DMM protocol while continuing the disconnect. Alex ___ 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 -- Regards, Charlie P. ___ 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] regarding the re-chartering..
Hi Alex, On Thu, Sep 4, 2014 at 6:36 AM, Alexandru Petrescu alexandru.petre...@gmail.com wrote: Le 04/09/2014 12:31, Charles E. Perkins a écrit : Hello folks, I have asked this same question many times, in different words... Namely, if we design a solution that fits the requirements, and bridges the gaps as analyzed in the gap analysis document, have we succeeded? My answer is no. As of now it may look as a homework - yes it solves the problem statement, yes it gets a high grade, yes it can. But what if no, deployments wouldn't need it. Or, is there a requirement for the work to be adopted by 3GPP? Even then - even if there were a req from 3GPP (a row in an excel sheet, an IPv6 mentioned in a 3GPP doc) - one would rather need a commitment of deployment from 3GPP. What if we design for IEEE 802 Wireless, which is currently carrying the preponderance of the world's wireless data, and will almost assuredly continue to carry a greater proportion? Yes, and with the advent of cheap 802.11ac's huge bandwidth (1.2GB/s) one of the strong selling points of Mobile IP is the ability to offer session continuity when handover cellular/802-Wireless - the heterogeneity to some extent. Additionally, there are many possibilities of doing Mobile IP in a 802-Wireless only environment: large indoor hotspot areas, long 11p-covered roads, etc. These are exhibited in trials. But, sorry for saying again, one couldn't stop wondering whether these are to be embraced by deployments. Why is the 'tethering' application on operator's smartphones preferring to use a form of IPv6 prefix sharing rather than Mobile IP/NEMO? Why there is no session continuity app in these smartphones? Why one has to always click on some icon on their smartphones to (1) switch on/off 'mobile data', (2) turn on/off WiFi? Good questions. I think that 3GPP SA1 work reported by Alper is addressing this issue in terms of classifying the flows. They identify certain class of flows like interactive calls where you would definitely need session continuity. 3GPP thinks that in most other cases like Web browsing you don't. So in dmm we can say that the protocol dmm is going to develop could be a candidate solution for those flows that you need session continuity. I don't think IETF can do more. Regards, Behcet Given these behaviours one may wonder how much the session continuity aspect is need by end users. There are some answers I heard about this... for example when one needs a session to be stable one by instinct will try to not move. Hardly can one walk and talk: two things at a time. Alex Regards Charlie P. On 9/4/2014 3:14 AM, Alexandru Petrescu wrote: Hi, In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted disconnect between the product developped - (P)Mobile IP - and the deployments. We know for a fact that 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do mention Mobile IP. To such a point that I wonder whether 3GPP has not the same disconnect as here. On another hand, we do have indications of where (P)Mobile IP is used - the trials, the projects, the kernel code, and not least the slideware attracting real customers. The worry: develop DMM protocol while continuing the disconnect. Alex ___ 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 ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] regarding the re-chartering..
-Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Sent: Thursday, September 04, 2014 6:36 AM To: Charles E. Perkins Cc: dmm@ietf.org Subject: Re: [DMM] regarding the re-chartering.. On Sep 4, 2014, at 1:31 PM, Charles E. Perkins wrote: Hello folks, I have asked this same question many times, in different words... Namely, if we design a solution that fits the requirements, and bridges the gaps as analyzed in the gap analysis document, have we succeeded? Or, is there a requirement for the work to be adopted by 3GPP? It would be cool but not required. What if we design for IEEE 802 Wireless, which is currently carrying the preponderance of the world's wireless data, and will almost assuredly continue to carry a greater proportion? ..and if the solution were adopted that would count as a major success. [JCZ] While I don't have a crystal ball to predict success of a technology (to respond to other people's concerns), I would strongly support addressing IEEE 802 Wireless technologies. Chances are that if 3GPP likes the solution, they will add some bits, change the name, and will adopt it as a non-IETF solution. Jc - JOuni Regards Charlie P. On 9/4/2014 3:14 AM, Alexandru Petrescu wrote: Hi, In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted disconnect between the product developped - (P)Mobile IP - and the deployments. We know for a fact that 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do mention Mobile IP. To such a point that I wonder whether 3GPP has not the same disconnect as here. On another hand, we do have indications of where (P)Mobile IP is used - the trials, the projects, the kernel code, and not least the slideware attracting real customers. The worry: develop DMM protocol while continuing the disconnect. Alex ___ 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 -- Regards, Charlie P. ___ 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] regarding the re-chartering..
On Wed, Sep 3, 2014 at 12:07 AM, Jouni Korhonen jouni.nos...@gmail.com wrote: We were on this in yesterday's interim call. We have a proposal text now. You were also on the call but I did not record you commenting anything during the discussion we had on this particular topic. I had leave early due to doctor's appointment. Are you now saying the resolution we have now in the charter text is not adequate? Distributed mobility management deployment models and scenarios: describe the target high-level network architectures and deployment models where distributed mobility management protocol solutions would apply. Behcet: the above text does not reflect my comments. I am against any deployment work before we decide on a solution (and there is currently no draft on this). This is strongly supported by IETF work on deployment as well as 3GPP. I am also concerned on the time DMM is taking on dressing up the charter text. I remind you on what Jari Arkko who is founding AD for DMM said in Toronto admin plenary: WGs should have solution work from day 1. He also emphasized importance of running code. It is not that we don't have solutions and it is claimed that two of them have been implemented. Regards, behcet - JOuni 9/2/2014 11:39 PM, Behcet Sarikaya kirjoitti: On Mon, Sep 1, 2014 at 1:34 PM, Jouni Korhonen jouni.nos...@gmail.com wrote: Behcet, Obviously that protocols are known that the intended deployment is going to use. The details what goes inside that protocol are not. This holds for my example case 3GPP as well. We do not need to into same level of detail that e.g. 3GPP stage-2 has detailing all signaling flows and so on. I believe we as a WG are competent enough to make a fine division what level of detail is left for the deployment models and scenarios and what goes into protocol solutions. I hope you read previous mails on this issue. I think it clear that 3GPP agrees with IETF on the interpretation of deployment. How can we close our eyes on this and try to put the horse before the cart? Why not simply remove it? Regards, Behcet - Jouni 9/1/2014 6:43 PM, Behcet Sarikaya kirjoitti: On Mon, Sep 1, 2014 at 3:25 AM, Jouni jouni.nos...@gmail.com wrote: Alper, I hear your concern. Anyway, the division here is similar to (3GPP) stage-2 and stage-3 work. The deployment models and scenarios are the stage-2 descriptions and then we also need the protocol level solutions that are in separate documents. Thanks Alper for raising this issue. 3GPP Stage 2 like in SA2 documents are architecture documents. I don't understand what is going on here. I am looking at 23.402 on Architecture Enhancements for non-3GPP accesses. Yes, this document talks about deployment in just a few places, here is one occurrence: on page 64, PCC deployment options on page 94, PMIP based S5/S8 deployments, etc. So in all cases the protocol, i.e. PCC or PMIP is known. Regards, Behcet Makes sense? - Jouni On Sep 1, 2014, at 10:13 AM, Alper Yegin wrote: Okay, we are not going to define how the existing 3FPP system works - that knowledge is assumed. What I thought goes into the document, for example, in the case of 3GPP system would be identifying the architecture changes or modifications needed. If the deployment model assumes all network functions are virtualized, the document states that and lays out the architecture based on that. Satoru's Ryuji's vEPC deployment model (based on their solution) is IMHO a good example of what could be documented. The similar applies for other system architectures such as SP Wi-Fi etc. Jouni, The architecture changes would be based on the a specific solution. So, as part of describing a solution one can be talking about what you are suggesting above. But I don't understand how we can be talking about deployment models and scenarios before we agree on the solutions. Alper o Enhanced mobility anchoring: define protocol solutions for a gateway and mobility anchor assignment and mid-session mobility anchor switching that go beyond what has been specified, for example, in RFC 6097, 6463, and 5142. Traffic steering associated with the anchor switch is also in-scope if deemed appropriate. o Forwarding path and signaling management: the function that handles mobility management signaling interacts with the DMM network elements for managing the forwarding state associated with a mobile node's IP traffic. These two functions may or may not be collocated. Furthermore, the forwarding state may also be distributed into multiple network elements instead of a single network element (e.g., anchor). Protocol extensions or new protocols will be specified to allow the above mentioned forwarding path and signalling management. I cannot separate mobility anchoring from fwding
Re: [DMM] regarding the re-chartering..
Just for clarification... On 9/3/14 12:22 PM, Behcet Sarikaya wrote: I am also concerned on the time DMM is taking on dressing up the charter text. I remind you on what Jari Arkko who is founding AD for DMM said in Toronto admin plenary: WGs should have solution work from day 1. Not should, but rather could. Not all WGs need to have requirements, frameworks, architecture, etc. That is why this type of discussion during charter development is important. He also emphasized importance of running code. Running code is good thing. So is an understanding of customer needs (in this case, other SDOs). Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] regarding the re-chartering..
Hi Brian, On Wed, Sep 3, 2014 at 11:30 AM, Brian Haberman br...@innovationslab.net wrote: Just for clarification... On 9/3/14 12:22 PM, Behcet Sarikaya wrote: I am also concerned on the time DMM is taking on dressing up the charter text. I remind you on what Jari Arkko who is founding AD for DMM said in Toronto admin plenary: WGs should have solution work from day 1. Not should, but rather could. Not all WGs need to have requirements, frameworks, architecture, etc. That is why this type of discussion during charter development is important. Here is the quote: WGs should have solution work from day 1 from page 22 of Jari's slides at: http://www.ietf.org/proceedings/90/slides/slides-90-iesg-opsplenary-7.pdf BTW we already did the requirements and gap analysis, etc. The architecture in our case is defined elsewhere, like 3GPP and everybody in this group is familiar with 3GPP architecture. He also emphasized importance of running code. Running code is good thing. So is an understanding of customer needs (in this case, other SDOs). Absolutely. Regards, Behcet Regards, Brian ___ 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] regarding the re-chartering..
On 9/3/14 12:50 PM, Behcet Sarikaya wrote: Hi Brian, On Wed, Sep 3, 2014 at 11:30 AM, Brian Haberman br...@innovationslab.net wrote: Just for clarification... On 9/3/14 12:22 PM, Behcet Sarikaya wrote: I am also concerned on the time DMM is taking on dressing up the charter text. I remind you on what Jari Arkko who is founding AD for DMM said in Toronto admin plenary: WGs should have solution work from day 1. Not should, but rather could. Not all WGs need to have requirements, frameworks, architecture, etc. That is why this type of discussion during charter development is important. Here is the quote: WGs should have solution work from day 1 from page 22 of Jari's slides at: http://www.ietf.org/proceedings/90/slides/slides-90-iesg-opsplenary-7.pdf Yes, that is what the slide says. The IESG discussed the contents of this presentation and the overwhelming consensus (and what was verbalized in the plenary) is that WGs should not be formed where the *only* output is architecture, frameworks, and/or requirements documents. The charter should have protocol/solution work on the charter from day one. It does not mean that non-solution documents should be skipped if they are needed or provide useful background. The charter text that Jouni sent to the mailing has four (4) work items. By my read, three (3) of them are solutions to identified problem areas. So, I believe the charter is following the spirit of Jari's plenary slides. Your only complaint is about the first work item. I have seen people asking about clarifications on that work item, but you are the only one who wants it removed. I believe others are in favor of providing a document of the high-level models being targeted for the solutions work. At this point, the WG chairs need to determine if there is consensus for the latest charter text. Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] regarding the re-chartering..
Behcet, On 9/3/14 2:33 PM, Behcet Sarikaya wrote: You don't seem to understand my points. That is quite possible. Your comment on the list was I am against any deployment work before we decide on a solution... I read that as an objection to having the deployment models work item on the agenda. Please do tell me what I am missing. Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] regarding the re-chartering..
On Mon, Sep 1, 2014 at 1:34 PM, Jouni Korhonen jouni.nos...@gmail.com wrote: Behcet, Obviously that protocols are known that the intended deployment is going to use. The details what goes inside that protocol are not. This holds for my example case 3GPP as well. We do not need to into same level of detail that e.g. 3GPP stage-2 has detailing all signaling flows and so on. I believe we as a WG are competent enough to make a fine division what level of detail is left for the deployment models and scenarios and what goes into protocol solutions. I hope you read previous mails on this issue. I think it clear that 3GPP agrees with IETF on the interpretation of deployment. How can we close our eyes on this and try to put the horse before the cart? Why not simply remove it? Regards, Behcet - Jouni 9/1/2014 6:43 PM, Behcet Sarikaya kirjoitti: On Mon, Sep 1, 2014 at 3:25 AM, Jouni jouni.nos...@gmail.com wrote: Alper, I hear your concern. Anyway, the division here is similar to (3GPP) stage-2 and stage-3 work. The deployment models and scenarios are the stage-2 descriptions and then we also need the protocol level solutions that are in separate documents. Thanks Alper for raising this issue. 3GPP Stage 2 like in SA2 documents are architecture documents. I don't understand what is going on here. I am looking at 23.402 on Architecture Enhancements for non-3GPP accesses. Yes, this document talks about deployment in just a few places, here is one occurrence: on page 64, PCC deployment options on page 94, PMIP based S5/S8 deployments, etc. So in all cases the protocol, i.e. PCC or PMIP is known. Regards, Behcet Makes sense? - Jouni On Sep 1, 2014, at 10:13 AM, Alper Yegin wrote: Okay, we are not going to define how the existing 3FPP system works - that knowledge is assumed. What I thought goes into the document, for example, in the case of 3GPP system would be identifying the architecture changes or modifications needed. If the deployment model assumes all network functions are virtualized, the document states that and lays out the architecture based on that. Satoru's Ryuji's vEPC deployment model (based on their solution) is IMHO a good example of what could be documented. The similar applies for other system architectures such as SP Wi-Fi etc. Jouni, The architecture changes would be based on the a specific solution. So, as part of describing a solution one can be talking about what you are suggesting above. But I don't understand how we can be talking about deployment models and scenarios before we agree on the solutions. Alper o Enhanced mobility anchoring: define protocol solutions for a gateway and mobility anchor assignment and mid-session mobility anchor switching that go beyond what has been specified, for example, in RFC 6097, 6463, and 5142. Traffic steering associated with the anchor switch is also in-scope if deemed appropriate. o Forwarding path and signaling management: the function that handles mobility management signaling interacts with the DMM network elements for managing the forwarding state associated with a mobile node's IP traffic. These two functions may or may not be collocated. Furthermore, the forwarding state may also be distributed into multiple network elements instead of a single network element (e.g., anchor). Protocol extensions or new protocols will be specified to allow the above mentioned forwarding path and signalling management. I cannot separate mobility anchoring from fwding path and signaling management. Wherever you want to set your anchor or move your anchor to, you'd need signaling and setting up data path. The two are inseparable. Having said that, I'm OK to keep the current work item descriptions and finalize rechartering. Once we have detailed discussions about the breakdown of the work, we can come back and refine the goals and milestones (as already stated below [*]). The enhanced mobility anchoring above is/was rather MIP type solutions influenced with anchors like we understand today, while the forwarding path and signaling management was meant for more future oriented solutions where the forwarding path does not necessarily have anything mobility specific etc. (Just FYI: It's not possible to gather what you are saying from reading the charter. Different people reading the charter may not have the same understanding. But like I said, this is just FYI, I can live with this text until we come back and refine it later). Ok. I'll try to clarify the point the text tries to make. - Jouni Thanks. Alper Any other opinions on collapsing these two? - Jouni o Exposing mobility state to mobile nodes and network nodes: define solutions that allow, for example, mobile nodes to select either a care-of address or a home address
Re: [DMM] regarding the re-chartering..
On Mon, Sep 1, 2014 at 3:25 AM, Jouni jouni.nos...@gmail.com wrote: Alper, I hear your concern. Anyway, the division here is similar to (3GPP) stage-2 and stage-3 work. The deployment models and scenarios are the stage-2 descriptions and then we also need the protocol level solutions that are in separate documents. Thanks Alper for raising this issue. 3GPP Stage 2 like in SA2 documents are architecture documents. I don't understand what is going on here. I am looking at 23.402 on Architecture Enhancements for non-3GPP accesses. Yes, this document talks about deployment in just a few places, here is one occurrence: on page 64, PCC deployment options on page 94, PMIP based S5/S8 deployments, etc. So in all cases the protocol, i.e. PCC or PMIP is known. Regards, Behcet Makes sense? - Jouni On Sep 1, 2014, at 10:13 AM, Alper Yegin wrote: Okay, we are not going to define how the existing 3FPP system works - that knowledge is assumed. What I thought goes into the document, for example, in the case of 3GPP system would be identifying the architecture changes or modifications needed. If the deployment model assumes all network functions are virtualized, the document states that and lays out the architecture based on that. Satoru's Ryuji's vEPC deployment model (based on their solution) is IMHO a good example of what could be documented. The similar applies for other system architectures such as SP Wi-Fi etc. Jouni, The architecture changes would be based on the a specific solution. So, as part of describing a solution one can be talking about what you are suggesting above. But I don't understand how we can be talking about deployment models and scenarios before we agree on the solutions. Alper o Enhanced mobility anchoring: define protocol solutions for a gateway and mobility anchor assignment and mid-session mobility anchor switching that go beyond what has been specified, for example, in RFC 6097, 6463, and 5142. Traffic steering associated with the anchor switch is also in-scope if deemed appropriate. o Forwarding path and signaling management: the function that handles mobility management signaling interacts with the DMM network elements for managing the forwarding state associated with a mobile node's IP traffic. These two functions may or may not be collocated. Furthermore, the forwarding state may also be distributed into multiple network elements instead of a single network element (e.g., anchor). Protocol extensions or new protocols will be specified to allow the above mentioned forwarding path and signalling management. I cannot separate mobility anchoring from fwding path and signaling management. Wherever you want to set your anchor or move your anchor to, you'd need signaling and setting up data path. The two are inseparable. Having said that, I'm OK to keep the current work item descriptions and finalize rechartering. Once we have detailed discussions about the breakdown of the work, we can come back and refine the goals and milestones (as already stated below [*]). The enhanced mobility anchoring above is/was rather MIP type solutions influenced with anchors like we understand today, while the forwarding path and signaling management was meant for more future oriented solutions where the forwarding path does not necessarily have anything mobility specific etc. (Just FYI: It's not possible to gather what you are saying from reading the charter. Different people reading the charter may not have the same understanding. But like I said, this is just FYI, I can live with this text until we come back and refine it later). Ok. I'll try to clarify the point the text tries to make. - Jouni Thanks. Alper Any other opinions on collapsing these two? - Jouni o Exposing mobility state to mobile nodes and network nodes: define solutions that allow, for example, mobile nodes to select either a care-of address or a home address depending on an application' mobility needs. In order to enable this functionality, the network-side control functions and other networking nodes must also be able to exchange appropriate control information, as well as to the mobile nodes and their applications. The working group may decide to extend the current milestones based on the new information and knowledge gained during working on other documents listed in the initial milestones. [*] Cheers, Alper Possible new documents and milestones must still fit into the overall DMM charter scope as outlined above. Goals and Milestones: Feb 2015 - Submit 'The deployment models and scenarios' as a working group document(s). To be Informational RFC. Feb 2015 - Submit 'Enhanced mobility anchoring' as a working group document. To be Proposed Standard. Feb 2015 - Submit
Re: [DMM] regarding the re-chartering..
OK, I see it now. thanks. Fred -Original Message- From: Jouni Korhonen [mailto:jouni.nos...@gmail.com] Sent: Wednesday, August 13, 2014 10:38 PM To: Templin, Fred L Cc: dmm@ietf.org Subject: Re: [DMM] regarding the re-chartering.. https://github.com/jounikor/dmm-re-charter 8/14/2014 1:44 AM, Templin, Fred L kirjoitti: Hi Jouni, Is the draft charter under some sort of version control, or are the previous versions gone for good? Thanks - Fred fred.l.temp...@boeing.com ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] regarding the re-chartering..
So, in lines 27-30 of the current draft charter, it says: 5213, RFC 5844, RFC , RFC 5568, and RFC 6275) as well as new approaches which capitalize on other protocols specified by the IETF. When extending protocols that are not based on Mobile IP, DMM solutions will be have to be reviewed by the corresponding WGs. That text has changed considerably from earlier versions but I am still thinking that AERO can be considered a new approach which capitalizes on other protocols specified by the IETF. Am I right that AERO could be a candidate for such a new approach? If so, then my only concern is that AERO doesn't currently have a working group home, and I was sort of thinking dmm could become the home working group. Is that wishful thinking? Thanks - Fred fred.l.temp...@boeing.com ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] regarding the re-chartering..
Alper, all, 8/5/2014 11:43 AM, Alper Yegin kirjoitti: Hello, Thank you Kostas for this rewrite. The charter reads better now. Please see below for few comments. On Jul 30, 2014, at 11:20 AM, Jouni Korhonen wrote: Folks, A major rewrite of the charter is in github (and below). Thanks to Kostas providing excellent feedbask on the text. Comments are welcome. Description of Working Group: Mobility management solutions lie at the center of the wireless Internet and enable mobile devices to partake in IP networks anytime and anywhere. The IETF Distributed Mobility Management (DMM) working group (WG) specifies solutions for IP networks so that traffic can be expedited between mobile and correspondent nodes. DMM solutions aim for transparency above the IP layer, including maintenance of active transport level sessions when mobile hosts or mobile networks change their point of attachment to the Internet. Wireless network deployments have traditionally relied on hierarchical schemes that often lead to centralized deployment models, where a small number of mobility anchors manage both mobility and reachability for a mobile node. The DMM WG will consider the latest developments in mobile networking research and operational practice (i.e. flat network architectures, the impact of virtualization, new deployment needs as wireless access technologies evolve in the coming years) and will describe how distributed mobility management addresses the new needs in this area better than previously standardized solutions. A topic of particular focus will be mobility anchoring in this new context, and the DMM working group is chartered to work on maintenance-oriented extensions of the Mobile IPv6 protocol family (RFC 5213, RFC 5844, RFC , RFC 5568, and RFC 6275) as well as new approaches which capitalize on other protocols specified by the IETF. When extending protocols that are not based on Mobile IP, DMM solutions will be have to be reviewed by the corresponding WGs. IPv6 is assumed to be present in both the mobile host/router and the access networks. DMM solutions are primarily targeted at IPv6 deployments and are not required to support IPv4, in particular for the case where private IPv4 addresses and/or NATs are used. DMM solutions must maintain backward compatibility: If the network or the mobile host/router does not support the distributed mobility management protocol that should not prevent the mobile host/router gaining basic access (i.e., nomadic) to the network. Contrary to earlier IP mobility protocols, mobility management signaling paths and end-user traffic forwarding paths may differ. Further, mobility-related functions may be located in separate network nodes. DMM solutions should not distinguish between physical or virtualized networking functions. Whenever applicable, clarifications and additional features/capabilities for specific networking function deployment models, e.g. in virtualized environments, are in-scope and encouraged. Solutions may also specify the selection between the care-of addresses and home address(es)/prefix(es) for different application use cases. Work items related to distributed mobility management include: o Distributed mobility management deployment models and scenarios: describe the target high-level network architectures and deployment models where distributed mobility management protocol solutions could apply. Can someone elaborate on what kind of information will go into such a document? See the reply to Brian: http://www.ietf.org/mail-archive/web/dmm/current/msg01406.html o Enhanced mobility anchoring: define protocol solutions for a gateway and mobility anchor assignment and mid-session mobility anchor switching that go beyond what has been specified, for example, in RFC 6097, 6463, and 5142. Traffic steering associated with the anchor switch is also in-scope if deemed appropriate. o Forwarding path and signaling management: the function that handles mobility management signaling interacts with the DMM network elements for managing the forwarding state associated with a mobile node's IP traffic. These two functions may or may not be collocated. Furthermore, the forwarding state may also be distributed into multiple network elements instead of a single network element (e.g., anchor). Protocol extensions or new protocols will be specified to allow the above mentioned forwarding path and signalling management. I cannot separate mobility anchoring from fwding path and signaling management. Wherever you want to set your anchor or move your anchor to, you'd need signaling and setting up data path. The two are inseparable. Having said that, I'm OK to keep the current work item descriptions and finalize rechartering. Once we have
Re: [DMM] regarding the re-chartering..
Hi Jouni, Is the draft charter under some sort of version control, or are the previous versions gone for good? Thanks - Fred fred.l.temp...@boeing.com ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] regarding the re-chartering..
Hello, Thank you Kostas for this rewrite. The charter reads better now. Please see below for few comments. On Jul 30, 2014, at 11:20 AM, Jouni Korhonen wrote: Folks, A major rewrite of the charter is in github (and below). Thanks to Kostas providing excellent feedbask on the text. Comments are welcome. Description of Working Group: Mobility management solutions lie at the center of the wireless Internet and enable mobile devices to partake in IP networks anytime and anywhere. The IETF Distributed Mobility Management (DMM) working group (WG) specifies solutions for IP networks so that traffic can be expedited between mobile and correspondent nodes. DMM solutions aim for transparency above the IP layer, including maintenance of active transport level sessions when mobile hosts or mobile networks change their point of attachment to the Internet. Wireless network deployments have traditionally relied on hierarchical schemes that often lead to centralized deployment models, where a small number of mobility anchors manage both mobility and reachability for a mobile node. The DMM WG will consider the latest developments in mobile networking research and operational practice (i.e. flat network architectures, the impact of virtualization, new deployment needs as wireless access technologies evolve in the coming years) and will describe how distributed mobility management addresses the new needs in this area better than previously standardized solutions. A topic of particular focus will be mobility anchoring in this new context, and the DMM working group is chartered to work on maintenance-oriented extensions of the Mobile IPv6 protocol family (RFC 5213, RFC 5844, RFC , RFC 5568, and RFC 6275) as well as new approaches which capitalize on other protocols specified by the IETF. When extending protocols that are not based on Mobile IP, DMM solutions will be have to be reviewed by the corresponding WGs. IPv6 is assumed to be present in both the mobile host/router and the access networks. DMM solutions are primarily targeted at IPv6 deployments and are not required to support IPv4, in particular for the case where private IPv4 addresses and/or NATs are used. DMM solutions must maintain backward compatibility: If the network or the mobile host/router does not support the distributed mobility management protocol that should not prevent the mobile host/router gaining basic access (i.e., nomadic) to the network. Contrary to earlier IP mobility protocols, mobility management signaling paths and end-user traffic forwarding paths may differ. Further, mobility-related functions may be located in separate network nodes. DMM solutions should not distinguish between physical or virtualized networking functions. Whenever applicable, clarifications and additional features/capabilities for specific networking function deployment models, e.g. in virtualized environments, are in-scope and encouraged. Solutions may also specify the selection between the care-of addresses and home address(es)/prefix(es) for different application use cases. Work items related to distributed mobility management include: o Distributed mobility management deployment models and scenarios: describe the target high-level network architectures and deployment models where distributed mobility management protocol solutions could apply. Can someone elaborate on what kind of information will go into such a document? o Enhanced mobility anchoring: define protocol solutions for a gateway and mobility anchor assignment and mid-session mobility anchor switching that go beyond what has been specified, for example, in RFC 6097, 6463, and 5142. Traffic steering associated with the anchor switch is also in-scope if deemed appropriate. o Forwarding path and signaling management: the function that handles mobility management signaling interacts with the DMM network elements for managing the forwarding state associated with a mobile node's IP traffic. These two functions may or may not be collocated. Furthermore, the forwarding state may also be distributed into multiple network elements instead of a single network element (e.g., anchor). Protocol extensions or new protocols will be specified to allow the above mentioned forwarding path and signalling management. I cannot separate mobility anchoring from fwding path and signaling management. Wherever you want to set your anchor or move your anchor to, you'd need signaling and setting up data path. The two are inseparable. Having said that, I'm OK to keep the current work item descriptions and finalize rechartering. Once we have detailed discussions about the breakdown of the work, we can come back and refine the goals and
Re: [DMM] regarding the re-chartering..
Folks, A major rewrite of the charter is in github (and below). Thanks to Kostas providing excellent feedbask on the text. Comments are welcome. Description of Working Group: Mobility management solutions lie at the center of the wireless Internet and enable mobile devices to partake in IP networks anytime and anywhere. The IETF Distributed Mobility Management (DMM) working group (WG) specifies solutions for IP networks so that traffic can be expedited between mobile and correspondent nodes. DMM solutions aim for transparency above the IP layer, including maintenance of active transport level sessions when mobile hosts or mobile networks change their point of attachment to the Internet. Wireless network deployments have traditionally relied on hierarchical schemes that often lead to centralized deployment models, where a small number of mobility anchors manage both mobility and reachability for a mobile node. The DMM WG will consider the latest developments in mobile networking research and operational practice (i.e. flat network architectures, the impact of virtualization, new deployment needs as wireless access technologies evolve in the coming years) and will describe how distributed mobility management addresses the new needs in this area better than previously standardized solutions. A topic of particular focus will be mobility anchoring in this new context, and the DMM working group is chartered to work on maintenance-oriented extensions of the Mobile IPv6 protocol family (RFC 5213, RFC 5844, RFC , RFC 5568, and RFC 6275) as well as new approaches which capitalize on other protocols specified by the IETF. When extending protocols that are not based on Mobile IP, DMM solutions will be have to be reviewed by the corresponding WGs. IPv6 is assumed to be present in both the mobile host/router and the access networks. DMM solutions are primarily targeted at IPv6 deployments and are not required to support IPv4, in particular for the case where private IPv4 addresses and/or NATs are used. DMM solutions must maintain backward compatibility: If the network or the mobile host/router does not support the distributed mobility management protocol that should not prevent the mobile host/router gaining basic access (i.e., nomadic) to the network. Contrary to earlier IP mobility protocols, mobility management signaling paths and end-user traffic forwarding paths may differ. Further, mobility-related functions may be located in separate network nodes. DMM solutions should not distinguish between physical or virtualized networking functions. Whenever applicable, clarifications and additional features/capabilities for specific networking function deployment models, e.g. in virtualized environments, are in-scope and encouraged. Solutions may also specify the selection between the care-of addresses and home address(es)/prefix(es) for different application use cases. Work items related to distributed mobility management include: o Distributed mobility management deployment models and scenarios: describe the target high-level network architectures and deployment models where distributed mobility management protocol solutions could apply. o Enhanced mobility anchoring: define protocol solutions for a gateway and mobility anchor assignment and mid-session mobility anchor switching that go beyond what has been specified, for example, in RFC 6097, 6463, and 5142. Traffic steering associated with the anchor switch is also in-scope if deemed appropriate. o Forwarding path and signaling management: the function that handles mobility management signaling interacts with the DMM network elements for managing the forwarding state associated with a mobile node's IP traffic. These two functions may or may not be collocated. Furthermore, the forwarding state may also be distributed into multiple network elements instead of a single network element (e.g., anchor). Protocol extensions or new protocols will be specified to allow the above mentioned forwarding path and signalling management. o Exposing mobility state to mobile nodes and network nodes: define solutions that allow, for example, mobile nodes to select either a care-of address or a home address depending on an application' mobility needs. In order to enable this functionality, the network-side control functions and other networking nodes must also be able to exchange appropriate control information, as well as to the mobile nodes and their applications. The working group may decide to extend the current milestones based on the new information and knowledge gained during working on other documents listed in the initial milestones. Possible new documents and milestones must still fit
Re: [DMM] regarding the re-chartering..
7/25/2014 1:17 AM, Brian Haberman kirjoitti: On 7/24/14 6:01 PM, Behcet Sarikaya wrote: Hi Jouni, Regarding Distributed mobility management deployment models and scenarios: As I said in the session today I am having trouble understanding the deployment models. To me it sounds like doing the last thing first, i.e. after we get the dmm solution we work on how to deploy it (of course if the deployment has not already been considered by the solution). I may be interpreting the charter incorrectly, but I think there may be a disconnect. I interpreted the the charter text as describing deployment models like: - Wi-Fi-based mobility management - Cellular (e.g., 3GPP) mobility management - Mixed technology mobility management - etc. If that above interpretation is what was intended, I think it makes sense to have that type of description available to guide solution development. The above interpretation is correct. - Jouni If the above is not correct, then I suspect the charter needs some clarification. Regards, Brian ___ 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] regarding the re-chartering..
I may be interpreting the charter incorrectly, but I think there may be a disconnect. I interpreted the the charter text as describing deployment models like: - Wi-Fi-based mobility management - Cellular (e.g., 3GPP) mobility management - Mixed technology mobility management - etc. If that above interpretation is what was intended, I think it makes sense to have that type of description available to guide solution development. The above interpretation is correct. Can we expand that a bit more? Are we talking about: - Describing how WiFi and 3GPP-based architectures work today? - Describing how they'd work when flattened (e.g., moving the GW to the radio edge)? - Something else? Alper - Jouni If the above is not correct, then I suspect the charter needs some clarification. Regards, Brian ___ 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] regarding the re-chartering..
On Thu, Jul 24, 2014 at 5:17 PM, Brian Haberman br...@innovationslab.net wrote: On 7/24/14 6:01 PM, Behcet Sarikaya wrote: Hi Jouni, Regarding Distributed mobility management deployment models and scenarios: As I said in the session today I am having trouble understanding the deployment models. To me it sounds like doing the last thing first, i.e. after we get the dmm solution we work on how to deploy it (of course if the deployment has not already been considered by the solution). I may be interpreting the charter incorrectly, but I think there may be a disconnect. I interpreted the the charter text as describing deployment models like: - Wi-Fi-based mobility management - Cellular (e.g., 3GPP) mobility management - Mixed technology mobility management - etc. If that above interpretation is what was intended, I think it makes sense to have that type of description available to guide solution development. If the above is not correct, then I suspect the charter needs some clarification. If that is the case then I suggest calling it DMM usage scenarios or use cases in real networks? Use case work is done before solution work, so that I think is a good match with DMM. Regards, Behcet Regards, Brian ___ 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] regarding the re-chartering..
Hi Jouni, Regarding Distributed mobility management deployment models and scenarios: As I said in the session today I am having trouble understanding the deployment models. To me it sounds like doing the last thing first, i.e. after we get the dmm solution we work on how to deploy it (of course if the deployment has not already been considered by the solution). Is there an existing draft which comes close to this item so that I can read and try to understand? On the expected high level network architectures Is this about the architectures of the existing networks like 3GPP, home networks, enterprise networks, etc.? I hope you can shed some light into this. Regards, Behcet On Thu, Jul 24, 2014 at 4:49 PM, Jouni Korhonen jouni.nos...@gmail.com wrote: Folks, The latest charter draft can be found here: https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt The deadline for the text chnges are 31st July. I'll setup a call for next week so that those who want to dial in and have verbal commenting can do that. In a meanwhile, email works as usual for updates and comments on the text. The actual milestone dates are to be done last but suggestions are more than welcome. - Jouni Dapeng ___ 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
