Re: [DMM] draft charter text updates in github..
Hi Fred, Thanks for clarifying. We can maybe add your solution to the bunch classified as Mobile IP based approach, even though it does not require client software in the MN. We have a PMIP based solution and a routing based solution. All of these I think, form a good basis to work on in dmm. My 2 cents. Regards, Behcet On Thu, Jun 19, 2014 at 6:13 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Behcet, -Original Message- From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Sent: Thursday, June 19, 2014 3:57 PM To: Templin, Fred L Cc: Sri Gundavelli (sgundave); Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. I thought you said in your presentation that this draft is being AD-sponsored or going thru ISE? I think maybe you are talking about RFC6706, which was AD sponsored. The (bis) has not been picked up by an AD sponsor nor a working group yet, and is IMHO too far along in its evolution to fall back and take it down the ISE path now. So, wg item would seem like a suitable path. Thanks - Fred fred.l.temp...@boeing.com Regards, Behcet On Thu, Jun 19, 2014 at 4:20 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Behcet, -Original Message- From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Sent: Thursday, June 19, 2014 2:08 PM To: Templin, Fred L Cc: Sri Gundavelli (sgundave); Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Isn't AERO becoming an RFC already? We already have RFC6706 as an experimental RFC, but I am working on a (bis) that will obsolete that: https://datatracker.ietf.org/doc/draft-templin-aerolink/ The (bis) does not currently have a wg home, so I thought I would check to see if dmm would be a good home for it. Thanks - Fred fred.l.temp...@boeing.com Regards, Behcet On Thu, Jun 19, 2014 at 3:53 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 1:40 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, Or, have IPv4 built-in from the onset for free; wouldn't that be better? Cannot say without understanding the solution approach and the needed effort. But, I guess with AERO, you have some effort in mind. I have code that, while not pretty, is astonishingly simple. I should be able to release that very soon. Thanks - Fred fred.l.temp...@boeing.com Any case, its WG/Chairs/AD call, but works for me. Regards Sri On 6/19/14 1:34 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 1:32 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, Ack on the AERO capability. OK. I have come to the conclusion that I have to deal with IPv4 for the rest of my career (assuming some left). Surely, some day in 2016 is not some thing that I'm looking at. My point is to limit the solution scope and if it happens that DMM solution is immensely successful, we can introduce IPv4 interfaces in phases. Or, have IPv4 built-in from the onset for free; wouldn't that be better? Thanks - Fred fred.l.temp...@boeing.com Regards Sri On 6/19/14 12:54 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, I will just repeat that AERO works equally well on IPv4-only, IPv6-only and dual-stacked access networks. This means that it can address real world use cases today that cannot be addressed by other mechanisms. As to schedule, who can truly say when IPv4 will be totally gone from all access networks? 2016 is just a date on a calendar; we have been waiting for IPv6 to fully replace IPv4 since about 1994, and AFAICT it still hasn't happened. Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 12:33 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, The DMM WG is still discussing PS and the related issues. By the time we adopt a solution and complete the work, we will surely be in 2016. So, is it not safer to raise the bar and limit certain interfaces to IPv6-only ? I'm not arguing against adding any support for IPv4, but IMO the bar should
Re: [DMM] draft charter text updates in github..
Hi Behcet, -Original Message- From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Sent: Friday, June 20, 2014 8:31 AM To: Templin, Fred L Cc: Sri Gundavelli (sgundave); Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, Thanks for clarifying. We can maybe add your solution to the bunch classified as Mobile IP based approach, even though it does not require client software in the MN. To clarify, AERO does require the MN to run a lightweight app. The app is very similar in principle to OpenVPN, which may in the long run be a suitable integration platform for the AERO Client function. Thanks - Fred fred.l.temp...@boeing.com We have a PMIP based solution and a routing based solution. All of these I think, form a good basis to work on in dmm. My 2 cents. Regards, Behcet On Thu, Jun 19, 2014 at 6:13 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Behcet, -Original Message- From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Sent: Thursday, June 19, 2014 3:57 PM To: Templin, Fred L Cc: Sri Gundavelli (sgundave); Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. I thought you said in your presentation that this draft is being AD-sponsored or going thru ISE? I think maybe you are talking about RFC6706, which was AD sponsored. The (bis) has not been picked up by an AD sponsor nor a working group yet, and is IMHO too far along in its evolution to fall back and take it down the ISE path now. So, wg item would seem like a suitable path. Thanks - Fred fred.l.temp...@boeing.com Regards, Behcet On Thu, Jun 19, 2014 at 4:20 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Behcet, -Original Message- From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Sent: Thursday, June 19, 2014 2:08 PM To: Templin, Fred L Cc: Sri Gundavelli (sgundave); Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Isn't AERO becoming an RFC already? We already have RFC6706 as an experimental RFC, but I am working on a (bis) that will obsolete that: https://datatracker.ietf.org/doc/draft-templin-aerolink/ The (bis) does not currently have a wg home, so I thought I would check to see if dmm would be a good home for it. Thanks - Fred fred.l.temp...@boeing.com Regards, Behcet On Thu, Jun 19, 2014 at 3:53 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 1:40 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, Or, have IPv4 built-in from the onset for free; wouldn't that be better? Cannot say without understanding the solution approach and the needed effort. But, I guess with AERO, you have some effort in mind. I have code that, while not pretty, is astonishingly simple. I should be able to release that very soon. Thanks - Fred fred.l.temp...@boeing.com Any case, its WG/Chairs/AD call, but works for me. Regards Sri On 6/19/14 1:34 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 1:32 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, Ack on the AERO capability. OK. I have come to the conclusion that I have to deal with IPv4 for the rest of my career (assuming some left). Surely, some day in 2016 is not some thing that I'm looking at. My point is to limit the solution scope and if it happens that DMM solution is immensely successful, we can introduce IPv4 interfaces in phases. Or, have IPv4 built-in from the onset for free; wouldn't that be better? Thanks - Fred fred.l.temp...@boeing.com Regards Sri On 6/19/14 12:54 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, I will just repeat that AERO works equally well on IPv4-only, IPv6-only and dual-stacked access networks. This means that it can address real world use cases today that cannot be addressed by other mechanisms. As to schedule, who can truly say when IPv4 will be totally gone from all access networks? 2016 is just a date on a calendar; we have been waiting for IPv6 to fully replace IPv4 since about 1994, and AFAICT it still hasn't
Re: [DMM] draft charter text updates in github..
Hi Jouni, Thanks for updating the charter, which is now v12! I'm fine with this version (at least my comments were resolved). Regards, -- Hidetoshi Yokota KDDI RD Laboratories, Inc. e-mail:yok...@kddilabs.jp (2014/06/14 20:20), Jouni Korhonen wrote: Folks, Another set of tweaks in github (v12): o reminders of Charlie's comments o Hidetoshi's comments o Georgios' comments Also milestones got postponed. There is still a bit of my own editing in the text so not everything got moved over letter by letter. - Jouni 6/13/2014 2:41 PM, Jouni Korhonen kirjoitti: Folks, New update (v9) available. I added most of the editorials from Charlie (thanks) and the red texts from Alper. The lot debated anchoring term (and milestone) is still there. The milestone does not mention anymore about preserving the mobility sessions and stuff. That would be up to the solution to define. - Jouni 6/6/2014 2:47 PM, Jouni Korhonen kirjoitti: Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - 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] draft charter text updates in github..
Agree. We should ensure the base solution supports IPv6 transport and user sessions. Optionally, support for IPv4 can be allowed on certain interfaces, but clearly should not deal with IPv4, NAT's or allow IPv4-only solutions. Regards Sri On 6/18/14 8:43 AM, Brian Haberman br...@innovationslab.net wrote: Hi Fred, On 6/18/14 11:25 AM, Templin, Fred L wrote: Hi Jouni, -Original Message- From: Jouni Korhonen [mailto:jouni.nos...@gmail.com] Sent: Wednesday, June 18, 2014 3:00 AM To: Templin, Fred L; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Fred, It is true IPv4 is there (and will be for a long time). Although the charter does emphasize IPv6 as the base solution it does not prohibit adding IPv4 support. It is just we can accept an IPv6-only solution as a valid complete solution from DMM point of view. However, a solution that works equally well whether the access networks are IPv6-only, dual-stack, or IPv4-only has clear advantages in terms of near-term deployment in real networks. Therefore, I think the charter is currently saying _too much_. My new proposal is simply to strike the following two sentences: DMM solutions are primarily targeted at IPv6 deployments and should not be required to support IPv4, specifically in situations where private IPv4 addresses and/or NATs are used. IPv6 is assumed to be present in both the mobile host/router and the access networks. The above has been a part of the DMM charter for a long time. Taking it out would appear to be opening the door for IPv4-only solutions. My assessment of the winds within the community is that people are not interested in new protocols for IPv4. Just my opinion... Brian ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] draft charter text updates in github..
Hi Sri, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Thursday, June 19, 2014 11:20 AM To: Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Agree. We should ensure the base solution supports IPv6 transport and user sessions. Optionally, support for IPv4 can be allowed on certain interfaces, but clearly should not deal with IPv4, NAT's or allow IPv4-only solutions. I don't understand that. In my enterprise, I have IPv4-only wireless access points yet there are IPv6 services within the enterprise. When I switch over to 4G wireless, I again get IPv4-only access but again there are IPv6 services within the enterprise. If the mobility management mechanism supports IPv6 over IPv4 tunneling (possibly including NATs in the path), then the use case is satisfied; otherwise, the use case is not satisfied. Thanks - Fred fred.l.temp...@boeing.com Regards Sri On 6/18/14 8:43 AM, Brian Haberman br...@innovationslab.net wrote: Hi Fred, On 6/18/14 11:25 AM, Templin, Fred L wrote: Hi Jouni, -Original Message- From: Jouni Korhonen [mailto:jouni.nos...@gmail.com] Sent: Wednesday, June 18, 2014 3:00 AM To: Templin, Fred L; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Fred, It is true IPv4 is there (and will be for a long time). Although the charter does emphasize IPv6 as the base solution it does not prohibit adding IPv4 support. It is just we can accept an IPv6-only solution as a valid complete solution from DMM point of view. However, a solution that works equally well whether the access networks are IPv6-only, dual-stack, or IPv4-only has clear advantages in terms of near-term deployment in real networks. Therefore, I think the charter is currently saying _too much_. My new proposal is simply to strike the following two sentences: DMM solutions are primarily targeted at IPv6 deployments and should not be required to support IPv4, specifically in situations where private IPv4 addresses and/or NATs are used. IPv6 is assumed to be present in both the mobile host/router and the access networks. The above has been a part of the DMM charter for a long time. Taking it out would appear to be opening the door for IPv4-only solutions. My assessment of the winds within the community is that people are not interested in new protocols for IPv4. Just my opinion... 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] draft charter text updates in github..
Sri, Let me be perfectly clear - AERO works equally well whether the access network is IPv4-only, IPv6-only, or dual-stacked. That is an advantage, and addresses real-world use cases. Hence, I do not think it should be discouraged by the charter. Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Templin, Fred L Sent: Thursday, June 19, 2014 11:30 AM To: Sri Gundavelli (sgundave); Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Sri, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Thursday, June 19, 2014 11:20 AM To: Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Agree. We should ensure the base solution supports IPv6 transport and user sessions. Optionally, support for IPv4 can be allowed on certain interfaces, but clearly should not deal with IPv4, NAT's or allow IPv4-only solutions. I don't understand that. In my enterprise, I have IPv4-only wireless access points yet there are IPv6 services within the enterprise. When I switch over to 4G wireless, I again get IPv4-only access but again there are IPv6 services within the enterprise. If the mobility management mechanism supports IPv6 over IPv4 tunneling (possibly including NATs in the path), then the use case is satisfied; otherwise, the use case is not satisfied. Thanks - Fred fred.l.temp...@boeing.com Regards Sri On 6/18/14 8:43 AM, Brian Haberman br...@innovationslab.net wrote: Hi Fred, On 6/18/14 11:25 AM, Templin, Fred L wrote: Hi Jouni, -Original Message- From: Jouni Korhonen [mailto:jouni.nos...@gmail.com] Sent: Wednesday, June 18, 2014 3:00 AM To: Templin, Fred L; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Fred, It is true IPv4 is there (and will be for a long time). Although the charter does emphasize IPv6 as the base solution it does not prohibit adding IPv4 support. It is just we can accept an IPv6-only solution as a valid complete solution from DMM point of view. However, a solution that works equally well whether the access networks are IPv6-only, dual-stack, or IPv4-only has clear advantages in terms of near-term deployment in real networks. Therefore, I think the charter is currently saying _too much_. My new proposal is simply to strike the following two sentences: DMM solutions are primarily targeted at IPv6 deployments and should not be required to support IPv4, specifically in situations where private IPv4 addresses and/or NATs are used. IPv6 is assumed to be present in both the mobile host/router and the access networks. The above has been a part of the DMM charter for a long time. Taking it out would appear to be opening the door for IPv4-only solutions. My assessment of the winds within the community is that people are not interested in new protocols for IPv4. Just my opinion... 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] draft charter text updates in github..
Hi Fred, The DMM WG is still discussing PS and the related issues. By the time we adopt a solution and complete the work, we will surely be in 2016. So, is it not safer to raise the bar and limit certain interfaces to IPv6-only ? I'm not arguing against adding any support for IPv4, but IMO the bar should be high. We can certainly support all possible types of networks, IPv4-only transport, IPv4-only user plane, and IPv4-only services. But, looking at our current pace and doing some extrapolation, its safe to say we will bake this for a long time and so limiting the work scope IMO helps. But, this is just my opinion/comment and personally don't care if some one wants to do the work and the chairs/AD/WG agree with it. Also, I do not know yet how much of the solution work will really be IP-version dependent. Mostly some network interfaces and there IPv6 possibly is a safe assumption. Regards Sri On 6/19/14 11:30 AM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Thursday, June 19, 2014 11:20 AM To: Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Agree. We should ensure the base solution supports IPv6 transport and user sessions. Optionally, support for IPv4 can be allowed on certain interfaces, but clearly should not deal with IPv4, NAT's or allow IPv4-only solutions. I don't understand that. In my enterprise, I have IPv4-only wireless access points yet there are IPv6 services within the enterprise. When I switch over to 4G wireless, I again get IPv4-only access but again there are IPv6 services within the enterprise. If the mobility management mechanism supports IPv6 over IPv4 tunneling (possibly including NATs in the path), then the use case is satisfied; otherwise, the use case is not satisfied. Thanks - Fred fred.l.temp...@boeing.com Regards Sri On 6/18/14 8:43 AM, Brian Haberman br...@innovationslab.net wrote: Hi Fred, On 6/18/14 11:25 AM, Templin, Fred L wrote: Hi Jouni, -Original Message- From: Jouni Korhonen [mailto:jouni.nos...@gmail.com] Sent: Wednesday, June 18, 2014 3:00 AM To: Templin, Fred L; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Fred, It is true IPv4 is there (and will be for a long time). Although the charter does emphasize IPv6 as the base solution it does not prohibit adding IPv4 support. It is just we can accept an IPv6-only solution as a valid complete solution from DMM point of view. However, a solution that works equally well whether the access networks are IPv6-only, dual-stack, or IPv4-only has clear advantages in terms of near-term deployment in real networks. Therefore, I think the charter is currently saying _too much_. My new proposal is simply to strike the following two sentences: DMM solutions are primarily targeted at IPv6 deployments and should not be required to support IPv4, specifically in situations where private IPv4 addresses and/or NATs are used. IPv6 is assumed to be present in both the mobile host/router and the access networks. The above has been a part of the DMM charter for a long time. Taking it out would appear to be opening the door for IPv4-only solutions. My assessment of the winds within the community is that people are not interested in new protocols for IPv4. Just my opinion... 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] draft charter text updates in github..
Hi Sri, I will just repeat that AERO works equally well on IPv4-only, IPv6-only and dual-stacked access networks. This means that it can address real world use cases today that cannot be addressed by other mechanisms. As to schedule, who can truly say when IPv4 will be totally gone from all access networks? 2016 is just a date on a calendar; we have been waiting for IPv6 to fully replace IPv4 since about 1994, and AFAICT it still hasn't happened. Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 12:33 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, The DMM WG is still discussing PS and the related issues. By the time we adopt a solution and complete the work, we will surely be in 2016. So, is it not safer to raise the bar and limit certain interfaces to IPv6-only ? I'm not arguing against adding any support for IPv4, but IMO the bar should be high. We can certainly support all possible types of networks, IPv4-only transport, IPv4-only user plane, and IPv4-only services. But, looking at our current pace and doing some extrapolation, its safe to say we will bake this for a long time and so limiting the work scope IMO helps. But, this is just my opinion/comment and personally don't care if some one wants to do the work and the chairs/AD/WG agree with it. Also, I do not know yet how much of the solution work will really be IP-version dependent. Mostly some network interfaces and there IPv6 possibly is a safe assumption. Regards Sri On 6/19/14 11:30 AM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Thursday, June 19, 2014 11:20 AM To: Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Agree. We should ensure the base solution supports IPv6 transport and user sessions. Optionally, support for IPv4 can be allowed on certain interfaces, but clearly should not deal with IPv4, NAT's or allow IPv4-only solutions. I don't understand that. In my enterprise, I have IPv4-only wireless access points yet there are IPv6 services within the enterprise. When I switch over to 4G wireless, I again get IPv4-only access but again there are IPv6 services within the enterprise. If the mobility management mechanism supports IPv6 over IPv4 tunneling (possibly including NATs in the path), then the use case is satisfied; otherwise, the use case is not satisfied. Thanks - Fred fred.l.temp...@boeing.com Regards Sri On 6/18/14 8:43 AM, Brian Haberman br...@innovationslab.net wrote: Hi Fred, On 6/18/14 11:25 AM, Templin, Fred L wrote: Hi Jouni, -Original Message- From: Jouni Korhonen [mailto:jouni.nos...@gmail.com] Sent: Wednesday, June 18, 2014 3:00 AM To: Templin, Fred L; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Fred, It is true IPv4 is there (and will be for a long time). Although the charter does emphasize IPv6 as the base solution it does not prohibit adding IPv4 support. It is just we can accept an IPv6-only solution as a valid complete solution from DMM point of view. However, a solution that works equally well whether the access networks are IPv6-only, dual-stack, or IPv4-only has clear advantages in terms of near-term deployment in real networks. Therefore, I think the charter is currently saying _too much_. My new proposal is simply to strike the following two sentences: DMM solutions are primarily targeted at IPv6 deployments and should not be required to support IPv4, specifically in situations where private IPv4 addresses and/or NATs are used. IPv6 is assumed to be present in both the mobile host/router and the access networks. The above has been a part of the DMM charter for a long time. Taking it out would appear to be opening the door for IPv4-only solutions. My assessment of the winds within the community is that people are not interested in new protocols for IPv4. Just my opinion... 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] draft charter text updates in github..
Hi Sri, -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 1:32 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, Ack on the AERO capability. OK. I have come to the conclusion that I have to deal with IPv4 for the rest of my career (assuming some left). Surely, some day in 2016 is not some thing that I'm looking at. My point is to limit the solution scope and if it happens that DMM solution is immensely successful, we can introduce IPv4 interfaces in phases. Or, have IPv4 built-in from the onset for free; wouldn't that be better? Thanks - Fred fred.l.temp...@boeing.com Regards Sri On 6/19/14 12:54 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, I will just repeat that AERO works equally well on IPv4-only, IPv6-only and dual-stacked access networks. This means that it can address real world use cases today that cannot be addressed by other mechanisms. As to schedule, who can truly say when IPv4 will be totally gone from all access networks? 2016 is just a date on a calendar; we have been waiting for IPv6 to fully replace IPv4 since about 1994, and AFAICT it still hasn't happened. Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 12:33 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, The DMM WG is still discussing PS and the related issues. By the time we adopt a solution and complete the work, we will surely be in 2016. So, is it not safer to raise the bar and limit certain interfaces to IPv6-only ? I'm not arguing against adding any support for IPv4, but IMO the bar should be high. We can certainly support all possible types of networks, IPv4-only transport, IPv4-only user plane, and IPv4-only services. But, looking at our current pace and doing some extrapolation, its safe to say we will bake this for a long time and so limiting the work scope IMO helps. But, this is just my opinion/comment and personally don't care if some one wants to do the work and the chairs/AD/WG agree with it. Also, I do not know yet how much of the solution work will really be IP-version dependent. Mostly some network interfaces and there IPv6 possibly is a safe assumption. Regards Sri On 6/19/14 11:30 AM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Thursday, June 19, 2014 11:20 AM To: Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Agree. We should ensure the base solution supports IPv6 transport and user sessions. Optionally, support for IPv4 can be allowed on certain interfaces, but clearly should not deal with IPv4, NAT's or allow IPv4-only solutions. I don't understand that. In my enterprise, I have IPv4-only wireless access points yet there are IPv6 services within the enterprise. When I switch over to 4G wireless, I again get IPv4-only access but again there are IPv6 services within the enterprise. If the mobility management mechanism supports IPv6 over IPv4 tunneling (possibly including NATs in the path), then the use case is satisfied; otherwise, the use case is not satisfied. Thanks - Fred fred.l.temp...@boeing.com Regards Sri On 6/18/14 8:43 AM, Brian Haberman br...@innovationslab.net wrote: Hi Fred, On 6/18/14 11:25 AM, Templin, Fred L wrote: Hi Jouni, -Original Message- From: Jouni Korhonen [mailto:jouni.nos...@gmail.com] Sent: Wednesday, June 18, 2014 3:00 AM To: Templin, Fred L; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Fred, It is true IPv4 is there (and will be for a long time). Although the charter does emphasize IPv6 as the base solution it does not prohibit adding IPv4 support. It is just we can accept an IPv6-only solution as a valid complete solution from DMM point of view. However, a solution that works equally well whether the access networks are IPv6-only, dual-stack, or IPv4-only has clear advantages in terms of near-term deployment in real networks. Therefore, I think the charter is currently saying _too much_. My new proposal is simply to strike the following two sentences: DMM solutions are primarily targeted at IPv6 deployments and should not be required to support IPv4, specifically in situations where private IPv4 addresses and/or NATs are used. IPv6 is assumed to be present in both the mobile host/router
Re: [DMM] draft charter text updates in github..
Hi Fred, Or, have IPv4 built-in from the onset for free; wouldn't that be better? Cannot say without understanding the solution approach and the needed effort. But, I guess with AERO, you have some effort in mind. Any case, its WG/Chairs/AD call, but works for me. Regards Sri On 6/19/14 1:34 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 1:32 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, Ack on the AERO capability. OK. I have come to the conclusion that I have to deal with IPv4 for the rest of my career (assuming some left). Surely, some day in 2016 is not some thing that I'm looking at. My point is to limit the solution scope and if it happens that DMM solution is immensely successful, we can introduce IPv4 interfaces in phases. Or, have IPv4 built-in from the onset for free; wouldn't that be better? Thanks - Fred fred.l.temp...@boeing.com Regards Sri On 6/19/14 12:54 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, I will just repeat that AERO works equally well on IPv4-only, IPv6-only and dual-stacked access networks. This means that it can address real world use cases today that cannot be addressed by other mechanisms. As to schedule, who can truly say when IPv4 will be totally gone from all access networks? 2016 is just a date on a calendar; we have been waiting for IPv6 to fully replace IPv4 since about 1994, and AFAICT it still hasn't happened. Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 12:33 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, The DMM WG is still discussing PS and the related issues. By the time we adopt a solution and complete the work, we will surely be in 2016. So, is it not safer to raise the bar and limit certain interfaces to IPv6-only ? I'm not arguing against adding any support for IPv4, but IMO the bar should be high. We can certainly support all possible types of networks, IPv4-only transport, IPv4-only user plane, and IPv4-only services. But, looking at our current pace and doing some extrapolation, its safe to say we will bake this for a long time and so limiting the work scope IMO helps. But, this is just my opinion/comment and personally don't care if some one wants to do the work and the chairs/AD/WG agree with it. Also, I do not know yet how much of the solution work will really be IP-version dependent. Mostly some network interfaces and there IPv6 possibly is a safe assumption. Regards Sri On 6/19/14 11:30 AM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Thursday, June 19, 2014 11:20 AM To: Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Agree. We should ensure the base solution supports IPv6 transport and user sessions. Optionally, support for IPv4 can be allowed on certain interfaces, but clearly should not deal with IPv4, NAT's or allow IPv4-only solutions. I don't understand that. In my enterprise, I have IPv4-only wireless access points yet there are IPv6 services within the enterprise. When I switch over to 4G wireless, I again get IPv4-only access but again there are IPv6 services within the enterprise. If the mobility management mechanism supports IPv6 over IPv4 tunneling (possibly including NATs in the path), then the use case is satisfied; otherwise, the use case is not satisfied. Thanks - Fred fred.l.temp...@boeing.com Regards Sri On 6/18/14 8:43 AM, Brian Haberman br...@innovationslab.net wrote: Hi Fred, On 6/18/14 11:25 AM, Templin, Fred L wrote: Hi Jouni, -Original Message- From: Jouni Korhonen [mailto:jouni.nos...@gmail.com] Sent: Wednesday, June 18, 2014 3:00 AM To: Templin, Fred L; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Fred, It is true IPv4 is there (and will be for a long time). Although the charter does emphasize IPv6 as the base solution it does not prohibit adding IPv4 support. It is just we can accept an IPv6-only solution as a valid complete solution from DMM point of view. However, a solution that works equally well whether the access networks are IPv6-only, dual-stack, or IPv4-only has clear advantages in terms of near-term deployment in real networks. Therefore, I think the charter is currently saying _too much_. My new
Re: [DMM] draft charter text updates in github..
Hi Sri, -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 1:40 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, Or, have IPv4 built-in from the onset for free; wouldn't that be better? Cannot say without understanding the solution approach and the needed effort. But, I guess with AERO, you have some effort in mind. I have code that, while not pretty, is astonishingly simple. I should be able to release that very soon. Thanks - Fred fred.l.temp...@boeing.com Any case, its WG/Chairs/AD call, but works for me. Regards Sri On 6/19/14 1:34 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 1:32 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, Ack on the AERO capability. OK. I have come to the conclusion that I have to deal with IPv4 for the rest of my career (assuming some left). Surely, some day in 2016 is not some thing that I'm looking at. My point is to limit the solution scope and if it happens that DMM solution is immensely successful, we can introduce IPv4 interfaces in phases. Or, have IPv4 built-in from the onset for free; wouldn't that be better? Thanks - Fred fred.l.temp...@boeing.com Regards Sri On 6/19/14 12:54 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, I will just repeat that AERO works equally well on IPv4-only, IPv6-only and dual-stacked access networks. This means that it can address real world use cases today that cannot be addressed by other mechanisms. As to schedule, who can truly say when IPv4 will be totally gone from all access networks? 2016 is just a date on a calendar; we have been waiting for IPv6 to fully replace IPv4 since about 1994, and AFAICT it still hasn't happened. Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 12:33 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, The DMM WG is still discussing PS and the related issues. By the time we adopt a solution and complete the work, we will surely be in 2016. So, is it not safer to raise the bar and limit certain interfaces to IPv6-only ? I'm not arguing against adding any support for IPv4, but IMO the bar should be high. We can certainly support all possible types of networks, IPv4-only transport, IPv4-only user plane, and IPv4-only services. But, looking at our current pace and doing some extrapolation, its safe to say we will bake this for a long time and so limiting the work scope IMO helps. But, this is just my opinion/comment and personally don't care if some one wants to do the work and the chairs/AD/WG agree with it. Also, I do not know yet how much of the solution work will really be IP-version dependent. Mostly some network interfaces and there IPv6 possibly is a safe assumption. Regards Sri On 6/19/14 11:30 AM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Thursday, June 19, 2014 11:20 AM To: Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Agree. We should ensure the base solution supports IPv6 transport and user sessions. Optionally, support for IPv4 can be allowed on certain interfaces, but clearly should not deal with IPv4, NAT's or allow IPv4-only solutions. I don't understand that. In my enterprise, I have IPv4-only wireless access points yet there are IPv6 services within the enterprise. When I switch over to 4G wireless, I again get IPv4-only access but again there are IPv6 services within the enterprise. If the mobility management mechanism supports IPv6 over IPv4 tunneling (possibly including NATs in the path), then the use case is satisfied; otherwise, the use case is not satisfied. Thanks - Fred fred.l.temp...@boeing.com Regards Sri On 6/18/14 8:43 AM, Brian Haberman br...@innovationslab.net wrote: Hi Fred, On 6/18/14 11:25 AM, Templin, Fred L wrote: Hi Jouni, -Original Message- From: Jouni Korhonen [mailto:jouni.nos...@gmail.com] Sent: Wednesday, June 18, 2014 3:00 AM To: Templin, Fred L; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Fred
Re: [DMM] draft charter text updates in github..
Hi Behcet, -Original Message- From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Sent: Thursday, June 19, 2014 2:08 PM To: Templin, Fred L Cc: Sri Gundavelli (sgundave); Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Isn't AERO becoming an RFC already? We already have RFC6706 as an experimental RFC, but I am working on a (bis) that will obsolete that: https://datatracker.ietf.org/doc/draft-templin-aerolink/ The (bis) does not currently have a wg home, so I thought I would check to see if dmm would be a good home for it. Thanks - Fred fred.l.temp...@boeing.com Regards, Behcet On Thu, Jun 19, 2014 at 3:53 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 1:40 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, Or, have IPv4 built-in from the onset for free; wouldn't that be better? Cannot say without understanding the solution approach and the needed effort. But, I guess with AERO, you have some effort in mind. I have code that, while not pretty, is astonishingly simple. I should be able to release that very soon. Thanks - Fred fred.l.temp...@boeing.com Any case, its WG/Chairs/AD call, but works for me. Regards Sri On 6/19/14 1:34 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 1:32 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, Ack on the AERO capability. OK. I have come to the conclusion that I have to deal with IPv4 for the rest of my career (assuming some left). Surely, some day in 2016 is not some thing that I'm looking at. My point is to limit the solution scope and if it happens that DMM solution is immensely successful, we can introduce IPv4 interfaces in phases. Or, have IPv4 built-in from the onset for free; wouldn't that be better? Thanks - Fred fred.l.temp...@boeing.com Regards Sri On 6/19/14 12:54 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, I will just repeat that AERO works equally well on IPv4-only, IPv6-only and dual-stacked access networks. This means that it can address real world use cases today that cannot be addressed by other mechanisms. As to schedule, who can truly say when IPv4 will be totally gone from all access networks? 2016 is just a date on a calendar; we have been waiting for IPv6 to fully replace IPv4 since about 1994, and AFAICT it still hasn't happened. Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 12:33 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, The DMM WG is still discussing PS and the related issues. By the time we adopt a solution and complete the work, we will surely be in 2016. So, is it not safer to raise the bar and limit certain interfaces to IPv6-only ? I'm not arguing against adding any support for IPv4, but IMO the bar should be high. We can certainly support all possible types of networks, IPv4-only transport, IPv4-only user plane, and IPv4-only services. But, looking at our current pace and doing some extrapolation, its safe to say we will bake this for a long time and so limiting the work scope IMO helps. But, this is just my opinion/comment and personally don't care if some one wants to do the work and the chairs/AD/WG agree with it. Also, I do not know yet how much of the solution work will really be IP-version dependent. Mostly some network interfaces and there IPv6 possibly is a safe assumption. Regards Sri On 6/19/14 11:30 AM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Thursday, June 19, 2014 11:20 AM To: Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Agree. We should ensure the base solution supports IPv6 transport and user sessions. Optionally, support for IPv4 can be allowed on certain interfaces, but clearly should not deal with IPv4, NAT's or allow IPv4-only solutions. I don't understand that. In my enterprise, I have IPv4-only wireless access points yet
Re: [DMM] draft charter text updates in github..
I thought you said in your presentation that this draft is being AD-sponsored or going thru ISE? Regards, Behcet On Thu, Jun 19, 2014 at 4:20 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Behcet, -Original Message- From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Sent: Thursday, June 19, 2014 2:08 PM To: Templin, Fred L Cc: Sri Gundavelli (sgundave); Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Isn't AERO becoming an RFC already? We already have RFC6706 as an experimental RFC, but I am working on a (bis) that will obsolete that: https://datatracker.ietf.org/doc/draft-templin-aerolink/ The (bis) does not currently have a wg home, so I thought I would check to see if dmm would be a good home for it. Thanks - Fred fred.l.temp...@boeing.com Regards, Behcet On Thu, Jun 19, 2014 at 3:53 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 1:40 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, Or, have IPv4 built-in from the onset for free; wouldn't that be better? Cannot say without understanding the solution approach and the needed effort. But, I guess with AERO, you have some effort in mind. I have code that, while not pretty, is astonishingly simple. I should be able to release that very soon. Thanks - Fred fred.l.temp...@boeing.com Any case, its WG/Chairs/AD call, but works for me. Regards Sri On 6/19/14 1:34 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 1:32 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, Ack on the AERO capability. OK. I have come to the conclusion that I have to deal with IPv4 for the rest of my career (assuming some left). Surely, some day in 2016 is not some thing that I'm looking at. My point is to limit the solution scope and if it happens that DMM solution is immensely successful, we can introduce IPv4 interfaces in phases. Or, have IPv4 built-in from the onset for free; wouldn't that be better? Thanks - Fred fred.l.temp...@boeing.com Regards Sri On 6/19/14 12:54 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, I will just repeat that AERO works equally well on IPv4-only, IPv6-only and dual-stacked access networks. This means that it can address real world use cases today that cannot be addressed by other mechanisms. As to schedule, who can truly say when IPv4 will be totally gone from all access networks? 2016 is just a date on a calendar; we have been waiting for IPv6 to fully replace IPv4 since about 1994, and AFAICT it still hasn't happened. Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 12:33 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, The DMM WG is still discussing PS and the related issues. By the time we adopt a solution and complete the work, we will surely be in 2016. So, is it not safer to raise the bar and limit certain interfaces to IPv6-only ? I'm not arguing against adding any support for IPv4, but IMO the bar should be high. We can certainly support all possible types of networks, IPv4-only transport, IPv4-only user plane, and IPv4-only services. But, looking at our current pace and doing some extrapolation, its safe to say we will bake this for a long time and so limiting the work scope IMO helps. But, this is just my opinion/comment and personally don't care if some one wants to do the work and the chairs/AD/WG agree with it. Also, I do not know yet how much of the solution work will really be IP-version dependent. Mostly some network interfaces and there IPv6 possibly is a safe assumption. Regards Sri On 6/19/14 11:30 AM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Thursday, June 19, 2014 11:20 AM To: Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Agree. We should ensure the base solution supports IPv6 transport and user sessions. Optionally, support for IPv4 can
Re: [DMM] draft charter text updates in github..
Hi Behcet, -Original Message- From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Sent: Thursday, June 19, 2014 3:57 PM To: Templin, Fred L Cc: Sri Gundavelli (sgundave); Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. I thought you said in your presentation that this draft is being AD-sponsored or going thru ISE? I think maybe you are talking about RFC6706, which was AD sponsored. The (bis) has not been picked up by an AD sponsor nor a working group yet, and is IMHO too far along in its evolution to fall back and take it down the ISE path now. So, wg item would seem like a suitable path. Thanks - Fred fred.l.temp...@boeing.com Regards, Behcet On Thu, Jun 19, 2014 at 4:20 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Behcet, -Original Message- From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Sent: Thursday, June 19, 2014 2:08 PM To: Templin, Fred L Cc: Sri Gundavelli (sgundave); Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Isn't AERO becoming an RFC already? We already have RFC6706 as an experimental RFC, but I am working on a (bis) that will obsolete that: https://datatracker.ietf.org/doc/draft-templin-aerolink/ The (bis) does not currently have a wg home, so I thought I would check to see if dmm would be a good home for it. Thanks - Fred fred.l.temp...@boeing.com Regards, Behcet On Thu, Jun 19, 2014 at 3:53 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 1:40 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, Or, have IPv4 built-in from the onset for free; wouldn't that be better? Cannot say without understanding the solution approach and the needed effort. But, I guess with AERO, you have some effort in mind. I have code that, while not pretty, is astonishingly simple. I should be able to release that very soon. Thanks - Fred fred.l.temp...@boeing.com Any case, its WG/Chairs/AD call, but works for me. Regards Sri On 6/19/14 1:34 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 1:32 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, Ack on the AERO capability. OK. I have come to the conclusion that I have to deal with IPv4 for the rest of my career (assuming some left). Surely, some day in 2016 is not some thing that I'm looking at. My point is to limit the solution scope and if it happens that DMM solution is immensely successful, we can introduce IPv4 interfaces in phases. Or, have IPv4 built-in from the onset for free; wouldn't that be better? Thanks - Fred fred.l.temp...@boeing.com Regards Sri On 6/19/14 12:54 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, I will just repeat that AERO works equally well on IPv4-only, IPv6-only and dual-stacked access networks. This means that it can address real world use cases today that cannot be addressed by other mechanisms. As to schedule, who can truly say when IPv4 will be totally gone from all access networks? 2016 is just a date on a calendar; we have been waiting for IPv6 to fully replace IPv4 since about 1994, and AFAICT it still hasn't happened. Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 12:33 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi Fred, The DMM WG is still discussing PS and the related issues. By the time we adopt a solution and complete the work, we will surely be in 2016. So, is it not safer to raise the bar and limit certain interfaces to IPv6-only ? I'm not arguing against adding any support for IPv4, but IMO the bar should be high. We can certainly support all possible types of networks, IPv4-only transport, IPv4-only user plane, and IPv4-only services. But, looking at our current pace and doing some extrapolation, its safe to say we will bake this for a long time and so limiting the work scope IMO helps. But, this is just my opinion/comment and personally don't care if some one wants to do
Re: [DMM] draft charter text updates in github..
Hi Jouni, -Original Message- From: Jouni Korhonen [mailto:jouni.nos...@gmail.com] Sent: Wednesday, June 18, 2014 3:00 AM To: Templin, Fred L; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Fred, It is true IPv4 is there (and will be for a long time). Although the charter does emphasize IPv6 as the base solution it does not prohibit adding IPv4 support. It is just we can accept an IPv6-only solution as a valid complete solution from DMM point of view. However, a solution that works equally well whether the access networks are IPv6-only, dual-stack, or IPv4-only has clear advantages in terms of near-term deployment in real networks. Therefore, I think the charter is currently saying _too much_. My new proposal is simply to strike the following two sentences: DMM solutions are primarily targeted at IPv6 deployments and should not be required to support IPv4, specifically in situations where private IPv4 addresses and/or NATs are used. IPv6 is assumed to be present in both the mobile host/router and the access networks. Thanks - Fred fred.l.temp...@boeing.com - Jouni 6/16/2014 7:53 PM, Templin, Fred L kirjoitti: Hi Jouni, -Original Message- From: Jouni Korhonen [mailto:jouni.nos...@gmail.com] Sent: Monday, June 16, 2014 9:41 AM To: Templin, Fred L; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Fred, 6/16/2014 5:59 PM, Templin, Fred L kirjoitti: Hi Jouni, What about operation in IPv4-only access networks? There may be many enterprise networks that offer IPv4-only in their access networks for the near future, but with IPv6 enabled internally. For them, we should be able to tunnel IPv6 inside IPv4 if the mechanism can support it. My personal view is still that IPv4-only access is even more past than anchoring ;-) OK, but I am just telling what I see and it is that IPv4-only access in enterprise networks is still a reality today. Thanks - Fred fred.l.temp...@boeing.com Anyway, if there is (rough) consensus in the WG for the below new text, so be it. - Jouni Here is my suggested re-word: OLD: DMM solutions are primarily targeted at IPv6 deployments and should not be required to support IPv4, specifically in situations where private IPv4 addresses and/or NATs are used. IPv6 is assumed to be present in both the mobile host/router and the access networks. NEW: DMM solutions are primarily targeted at IPv6 mobile hosts/routers and should not be required to support IPv4-only mobiles. Access networks may be IPv6-enabled or IPv4-only, but with IPv6 enabled in the network core. Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Korhonen Sent: Saturday, June 14, 2014 4:20 AM To: dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Folks, Another set of tweaks in github (v12): o reminders of Charlie's comments o Hidetoshi's comments o Georgios' comments Also milestones got postponed. There is still a bit of my own editing in the text so not everything got moved over letter by letter. - Jouni 6/13/2014 2:41 PM, Jouni Korhonen kirjoitti: Folks, New update (v9) available. I added most of the editorials from Charlie (thanks) and the red texts from Alper. The lot debated anchoring term (and milestone) is still there. The milestone does not mention anymore about preserving the mobility sessions and stuff. That would be up to the solution to define. - Jouni 6/6/2014 2:47 PM, Jouni Korhonen kirjoitti: Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - 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] draft charter text updates in github..
Hi Fred, On 6/18/14 11:25 AM, Templin, Fred L wrote: Hi Jouni, -Original Message- From: Jouni Korhonen [mailto:jouni.nos...@gmail.com] Sent: Wednesday, June 18, 2014 3:00 AM To: Templin, Fred L; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Fred, It is true IPv4 is there (and will be for a long time). Although the charter does emphasize IPv6 as the base solution it does not prohibit adding IPv4 support. It is just we can accept an IPv6-only solution as a valid complete solution from DMM point of view. However, a solution that works equally well whether the access networks are IPv6-only, dual-stack, or IPv4-only has clear advantages in terms of near-term deployment in real networks. Therefore, I think the charter is currently saying _too much_. My new proposal is simply to strike the following two sentences: DMM solutions are primarily targeted at IPv6 deployments and should not be required to support IPv4, specifically in situations where private IPv4 addresses and/or NATs are used. IPv6 is assumed to be present in both the mobile host/router and the access networks. The above has been a part of the DMM charter for a long time. Taking it out would appear to be opening the door for IPv4-only solutions. My assessment of the winds within the community is that people are not interested in new protocols for IPv4. Just my opinion... Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] draft charter text updates in github..
Hi Jouni, -Original Message- From: Jouni Korhonen [mailto:jouni.nos...@gmail.com] Sent: Monday, June 16, 2014 9:41 AM To: Templin, Fred L; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Fred, 6/16/2014 5:59 PM, Templin, Fred L kirjoitti: Hi Jouni, What about operation in IPv4-only access networks? There may be many enterprise networks that offer IPv4-only in their access networks for the near future, but with IPv6 enabled internally. For them, we should be able to tunnel IPv6 inside IPv4 if the mechanism can support it. My personal view is still that IPv4-only access is even more past than anchoring ;-) OK, but I am just telling what I see and it is that IPv4-only access in enterprise networks is still a reality today. Thanks - Fred fred.l.temp...@boeing.com Anyway, if there is (rough) consensus in the WG for the below new text, so be it. - Jouni Here is my suggested re-word: OLD: DMM solutions are primarily targeted at IPv6 deployments and should not be required to support IPv4, specifically in situations where private IPv4 addresses and/or NATs are used. IPv6 is assumed to be present in both the mobile host/router and the access networks. NEW: DMM solutions are primarily targeted at IPv6 mobile hosts/routers and should not be required to support IPv4-only mobiles. Access networks may be IPv6-enabled or IPv4-only, but with IPv6 enabled in the network core. Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Korhonen Sent: Saturday, June 14, 2014 4:20 AM To: dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Folks, Another set of tweaks in github (v12): o reminders of Charlie's comments o Hidetoshi's comments o Georgios' comments Also milestones got postponed. There is still a bit of my own editing in the text so not everything got moved over letter by letter. - Jouni 6/13/2014 2:41 PM, Jouni Korhonen kirjoitti: Folks, New update (v9) available. I added most of the editorials from Charlie (thanks) and the red texts from Alper. The lot debated anchoring term (and milestone) is still there. The milestone does not mention anymore about preserving the mobility sessions and stuff. That would be up to the solution to define. - Jouni 6/6/2014 2:47 PM, Jouni Korhonen kirjoitti: Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - 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] draft charter text updates in github..
Hi Jouni, Hi all, Sorry for not being able to attend the telco. I have checked the updated charter. It looks good, but I have some comments: Comment_1: Not sure which of the mentioned milestones incorporate traffic steering after re-anchoring. Is it the milestone Forwarding path and signalling management or is it the milestone Enhanced mobility anchoring? A sentence similar to below, could be included in one of these two work items to emphasize this: The steering of the traffic associated with the mid-session mobility anchor switching is also in the scope of this work item. Comment_2: virtualization should be, IMHO, better emphasized in the charter. For example, could we change the following paragraph from: The DMM solutions should not distinguish between physical or virtualised networking functions. However, whenever applicable, clarifications for specific networking function deployment models are in scope and encouraged. INTO: The DMM solutions should not distinguish between physical or virtualised networking functions. However, whenever applicable, clarifications and additional features/capabilities for specific networking function deployment models, e.g., in virtualized environments, are in scope and encouraged. Comment_3: The milestones are too ambitious. Please extend each of them with at least 3 months. Best regards, Georgios Van: dmm [dmm-boun...@ietf.org] namens Jouni Korhonen [jouni.nos...@gmail.com] Verzonden: vrijdag 13 juni 2014 13:41 Aan: dmm@ietf.org Onderwerp: Re: [DMM] draft charter text updates in github.. Folks, New update (v9) available. I added most of the editorials from Charlie (thanks) and the red texts from Alper. The lot debated anchoring term (and milestone) is still there. The milestone does not mention anymore about preserving the mobility sessions and stuff. That would be up to the solution to define. - Jouni 6/6/2014 2:47 PM, Jouni Korhonen kirjoitti: Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - 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] draft charter text updates in github..
Hi, 6/14/2014 8:59 AM, karag...@cs.utwente.nl kirjoitti: Hi Jouni, Hi all, Sorry for not being able to attend the telco. I have checked the updated charter. It looks good, but I have some comments: Comment_1: Not sure which of the mentioned milestones incorporate traffic steering after re-anchoring. Is it the milestone Forwarding path and signalling management or is it the milestone Enhanced mobility anchoring? The latter. It was also stipulated that in a good case Forwarding path and signalling management could also be used for traffic steering for anchor switch.. or then both could be entirely separate solutions. A sentence similar to below, could be included in one of these two work items to emphasize this: The steering of the traffic associated with the mid-session mobility anchor switching is also in the scope of this work item. Ok.. works for me. Comment_2: virtualization should be, IMHO, better emphasized in the charter. For example, could we change the following paragraph from: And we have an other mail saying it does not need to be mentioned ;) The DMM solutions should not distinguish between physical or virtualised networking functions. However, whenever applicable, clarifications for specific networking function deployment models are in scope and encouraged. INTO: The DMM solutions should not distinguish between physical or virtualised networking functions. However, whenever applicable, clarifications and additional features/capabilities for specific networking function deployment models, e.g., in virtualized environments, are in scope and encouraged. OK with that. Comment_3: The milestones are too ambitious. Please extend each of them with at least 3 months. Ack. Thanks, Jouni Best regards, Georgios Van: dmm [dmm-boun...@ietf.org] namens Jouni Korhonen [jouni.nos...@gmail.com] Verzonden: vrijdag 13 juni 2014 13:41 Aan: dmm@ietf.org Onderwerp: Re: [DMM] draft charter text updates in github.. Folks, New update (v9) available. I added most of the editorials from Charlie (thanks) and the red texts from Alper. The lot debated anchoring term (and milestone) is still there. The milestone does not mention anymore about preserving the mobility sessions and stuff. That would be up to the solution to define. - Jouni 6/6/2014 2:47 PM, Jouni Korhonen kirjoitti: Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - 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] draft charter text updates in github..
Hi, 6/14/2014 7:34 AM, Hidetoshi Yokota kirjoitti: Hi Jouni and all, Thanks for updating the charter, which is much tidy now. Sorry for my late response, but I have a couple of comments below: o With regard to enhanced mobility anchoring (mid-session anchor switching), there were a lot of discussions in the past as you know and eventually that idea was not fully accepted by the community. It's ok to handle it in DMM WG, but we also need convincing use cases and effectiveness. Re-anchoring LMAs/HAs with preserving IP address may not be so elegant and efficient. Right. The charter does not enforce preserving the IP during the switch, actually. It would be a desirable feature tough. o I was not very sure why virtualization needs to be mentioned. There might have been some discussion about it, but do we really need it in the charter? The DMM solutions should not distinguish between physical or virtualised networking functions. However, whenever applicable, clarifications for specific networking function deployment models are in scope and encouraged. I still keep it for the time being. Several folk seem to think it needs to be mentioned.. o The fourth paragraph mentions UP/CP separation, but the last sentence is about IP address change, which is described in the fifth paragraph. That sentence may be fit there. In contrast to existing IETF standard IP mobility protocols, mobility management signalling paths and end user traffic forwarding paths may differ; those mobility related functions may be located in separate network nodes. Solutions may also specify the selection between the care-of addresses and home address(es)/prefix(es) for different application use cases. Ack. Done. - Jouni Regards, -- Hidetoshi Yokota KDDI RD Laboratories, Inc. e-mail:yok...@kddilabs.jp (2014/06/13 20:41), Jouni Korhonen wrote: Folks, New update (v9) available. I added most of the editorials from Charlie (thanks) and the red texts from Alper. The lot debated anchoring term (and milestone) is still there. The milestone does not mention anymore about preserving the mobility sessions and stuff. That would be up to the solution to define. - Jouni 6/6/2014 2:47 PM, Jouni Korhonen kirjoitti: Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - 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] draft charter text updates in github..
Btw, I'm not aware of any decision that the baseline protocol will be PMIP. CMIP is equally on the table. Sure. For the anchoring stuff that was kind of assumed to be PMIP though. Possibly in some individual's minds. (Btw, it's likely that this WG would come up with multiple solutions. Yes, it's not desirable, but one-size-fits-all may not be achievable. Well, discussions will show…) Alper - Jouni Alper On Jun 12, 2014, at 10:25 AM, Jouni wrote: Alper, The latter bullet (forwarding path etc) is imho clearly in your 3. choice below. It can also be 2. since it is not yet stated what is the baseline protocol. The protocol solution will then determine that. The former bullet (enhanced anchoring etc) is imho clearly your 2. more than 1. It could be also partly in 3. if non-PMIP stuff is needed for the overall solution. Anyway, the baseline protocol is known - PMIP, and the solution aims to distribution within PMIP's boundaries. What is unclear here? Jouni -- Jouni Korhonen Broadcom (Sent from my mobile..) Alper Yegin alper.ye...@yegin.org kirjoitti 12.6.2014 kello 9.09: Jouni, Based on earlier discussions, and what you wrote below, there are 3 distinct things: 1. *MIP maintenance. Any bug fix or improvement not driven by DMM, but for the sake of maintaining the *MIP baseline protocols, are handled here. 2. MIP-based DMM solutions. 3. Non-MIP-based DMM solutions. I presume these 3 items map to the those two bullets in the charter. Right? I cannot clearly tell the mapping though. Alper On Jun 12, 2014, at 12:14 AM, Jouni wrote: Alper, On Jun 11, 2014, at 10:54 PM, Alper Yegin wrote: Hi Jouni, 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, for example, described in RFC 6097, 6463, and 5142. The solution should also define a mechanism for preserving ongoing mobility sessions in a single administrative or IGP routing domain, which would involve directing traffic towards the new anchor. o Forwarding path and signalling management: the mobility agent that handles the mobility signalling interacts with the network elements in the DMM network 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 anchor like network element. Define required protocol extensions to allow described forwarding path and signalling management. These above two seem inseparable. I recommend we list them as one item. Hrmph.. not sure I agree. (The separation was between anchor selection and data-path management signaling before. At that time, it was a clearer separation. But even at that time I was suggesting combining the two items. In this latest text, the separation got blurred. The title of the first item, along with references to switching, preserving sessions, directing traffic all point to the context of the second one…) I see your point/concern. Since I (personally) see the enhanced mobility anchoring more towards maintenance work, I am tempted to have these two different milestones from the beginning. We could remove the last sentence of the anchoring milestone.. So, what's called enhanced mobility anchoring refers to 'maintenance work', and It could, since we specifically point three PMIP RFCs on a related topic: daa daa on anchor selection, solution for redirect during session establishment and solution for anchor switch that does not address what happens to ongoing sessions. When you do better than those, you are approaching a solution that allows one to better distribute anchors. Still very PMIPish, though. Forwarding path and signaling management refers to 'new DMM solution'? Yes.. we specifically do not refer how and based on what to achieve that. I didn't get that from the text… So is the Forwarding path and signaling management intent unclear in DMM scope? In my understanding, what we have been calling maintenance is simply PMIP/CMIP improvements/fixes in broad context -- not related to a DMM solution. On the other hand, that first bullet above does read like a DMM solution to me. I'm confused… what is maintenance, what is the objective of first bullet, what is the objective of second bullet… First bullet intent should be clear, continue PMIP where it left on this anchor part. Second bullet gives you much more freedom. That is how I divided it in my organic compute unit. - Jouni Alper - Jouni We can note that separate anchor discovery selection drafts may be produced (opening the door for split documents, while
Re: [DMM] draft charter text updates in github..
Folks, New update (v9) available. I added most of the editorials from Charlie (thanks) and the red texts from Alper. The lot debated anchoring term (and milestone) is still there. The milestone does not mention anymore about preserving the mobility sessions and stuff. That would be up to the solution to define. - Jouni 6/6/2014 2:47 PM, Jouni Korhonen kirjoitti: Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - Jouni ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] draft charter text updates in github..
On Jun 14, 2014, at 2:37 AM, Charles E. Perkins wrote: Hello Jouni, Thanks for incorporating some of my suggested revisions. Follow-up below... On 6/13/2014 3:41 AM, Jouni Korhonen wrote: /* What about RFC 5568 (FMIP)? */ There is the ..such as.. so I think there is no really need to lost all possible MIP6 variations. FMIP is particularly important when developing solutions that are aimed at localizing handover signaling, and I think it deserves particular mention, at the cost of adding ten or fifteen more characters to the charter text. Okay. /* What does eventually mean?? */ erm.. removed.. Well, it's still there. So, maybe, the other dozen or so D'oh. revisions that didn't make it into charter revision #9 were intended to be included also...? I'll await further follow-up until I can see whether my other comments were rejected or simply overlooked. Please take a look. Hmm.. seems i did not include the comments in the milestones part.. my mistake. In particular, misuse of the definite article the can be interpreted to restrict development to a single solution. And, as has been discussed, I think that the dmm WG is very likely to develop a suite of smoothly interacting solutions. Moreover, it should be observed that on a single mobile node, different applications might require different treatment for their end-point IP address. This might also encourage further use of multiple IPv6 addresses by a single mobile node, which in my opinion is a positive feature. Or it could elevate the importance of proper treatment for flow mobility. Is it just me, or do other people prefer RFC 6275 to RFC6275? Spaces are cheap.. will add those. - Jouni Also, the suggested dates for chartered work items seem quite unrealistic to me. ;-) +3 months? That would at least enable some believability. I noticed that part of the charter fit nicely in my 80-column (vi) text window, and part of the charter does not fit nicely. I could also fix that if desired. Fixed. Thanks! For convenience, I attached the rfcdiff output from my previous text of the charter compared to today's version #9. If doing so is not helpful, please let me know. Regards, Charlie P. Diff dmm_charter-Jun10,2014.txt - dmm_charter-Jun10,2014b.txt.htm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] draft charter text updates in github..
Hi Jouni and all, Thanks for updating the charter, which is much tidy now. Sorry for my late response, but I have a couple of comments below: o With regard to enhanced mobility anchoring (mid-session anchor switching), there were a lot of discussions in the past as you know and eventually that idea was not fully accepted by the community. It's ok to handle it in DMM WG, but we also need convincing use cases and effectiveness. Re-anchoring LMAs/HAs with preserving IP address may not be so elegant and efficient. o I was not very sure why virtualization needs to be mentioned. There might have been some discussion about it, but do we really need it in the charter? The DMM solutions should not distinguish between physical or virtualised networking functions. However, whenever applicable, clarifications for specific networking function deployment models are in scope and encouraged. o The fourth paragraph mentions UP/CP separation, but the last sentence is about IP address change, which is described in the fifth paragraph. That sentence may be fit there. In contrast to existing IETF standard IP mobility protocols, mobility management signalling paths and end user traffic forwarding paths may differ; those mobility related functions may be located in separate network nodes. Solutions may also specify the selection between the care-of addresses and home address(es)/prefix(es) for different application use cases. Regards, -- Hidetoshi Yokota KDDI RD Laboratories, Inc. e-mail:yok...@kddilabs.jp (2014/06/13 20:41), Jouni Korhonen wrote: Folks, New update (v9) available. I added most of the editorials from Charlie (thanks) and the red texts from Alper. The lot debated anchoring term (and milestone) is still there. The milestone does not mention anymore about preserving the mobility sessions and stuff. That would be up to the solution to define. - Jouni 6/6/2014 2:47 PM, Jouni Korhonen kirjoitti: Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - 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] draft charter text updates in github..
Hi Jouni and all, With regard to the milestone, it looks getting more aggressive. If we think of the current pace of creating the problem statement and requirements documents, submitting the I-Ds to IESG by next March doesn't seem to be very realistic... Just a few other comments below: (2014/06/14 8:53), Jouni wrote: On Jun 14, 2014, at 2:37 AM, Charles E. Perkins wrote: Hello Jouni, Thanks for incorporating some of my suggested revisions. Follow-up below... On 6/13/2014 3:41 AM, Jouni Korhonen wrote: /* What about RFC 5568 (FMIP)? */ There is the ..such as.. so I think there is no really need to lost all possible MIP6 variations. FMIP is particularly important when developing solutions that are aimed at localizing handover signaling, and I think it deserves particular mention, at the cost of adding ten or fifteen more characters to the charter text. Okay. Then Why not RFC5949 for PMIP? ;-) /* What does eventually mean?? */ erm.. removed.. Well, it's still there. So, maybe, the other dozen or so D'oh. revisions that didn't make it into charter revision #9 were intended to be included also...? I'll await further follow-up until I can see whether my other comments were rejected or simply overlooked. Please take a look. Hmm.. seems i did not include the comments in the milestones part.. my mistake. In particular, misuse of the definite article the can be interpreted to restrict development to a single solution. And, as has been discussed, I think that the dmm WG is very likely to develop a suite of smoothly interacting solutions. Moreover, it should be observed that on a single mobile node, different applications might require different treatment for their end-point IP address. This might also encourage further use of multiple IPv6 addresses by a single mobile node, which in my opinion is a positive feature. Or it could elevate the importance of proper treatment for flow mobility. Is it just me, or do other people prefer RFC 6275 to RFC6275? Spaces are cheap.. will add those. Many RFCs don't have a space between them, but it should be ok. Regards, -- Hidetoshi - Jouni Also, the suggested dates for chartered work items seem quite unrealistic to me. ;-) +3 months? That would at least enable some believability. I noticed that part of the charter fit nicely in my 80-column (vi) text window, and part of the charter does not fit nicely. I could also fix that if desired. Fixed. Thanks! For convenience, I attached the rfcdiff output from my previous text of the charter compared to today's version #9. If doing so is not helpful, please let me know. Regards, Charlie P. Diff dmm_charter-Jun10,2014.txt - dmm_charter-Jun10,2014b.txt.htm ___ 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] draft charter text updates in github..
Jouni, Based on earlier discussions, and what you wrote below, there are 3 distinct things: 1. *MIP maintenance. Any bug fix or improvement not driven by DMM, but for the sake of maintaining the *MIP baseline protocols, are handled here. 2. MIP-based DMM solutions. 3. Non-MIP-based DMM solutions. I presume these 3 items map to the those two bullets in the charter. Right? I cannot clearly tell the mapping though. Alper On Jun 12, 2014, at 12:14 AM, Jouni wrote: Alper, On Jun 11, 2014, at 10:54 PM, Alper Yegin wrote: Hi Jouni, 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, for example, described in RFC 6097, 6463, and 5142. The solution should also define a mechanism for preserving ongoing mobility sessions in a single administrative or IGP routing domain, which would involve directing traffic towards the new anchor. o Forwarding path and signalling management: the mobility agent that handles the mobility signalling interacts with the network elements in the DMM network 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 anchor like network element. Define required protocol extensions to allow described forwarding path and signalling management. These above two seem inseparable. I recommend we list them as one item. Hrmph.. not sure I agree. (The separation was between anchor selection and data-path management signaling before. At that time, it was a clearer separation. But even at that time I was suggesting combining the two items. In this latest text, the separation got blurred. The title of the first item, along with references to switching, preserving sessions, directing traffic all point to the context of the second one…) I see your point/concern. Since I (personally) see the enhanced mobility anchoring more towards maintenance work, I am tempted to have these two different milestones from the beginning. We could remove the last sentence of the anchoring milestone.. So, what's called enhanced mobility anchoring refers to 'maintenance work', and It could, since we specifically point three PMIP RFCs on a related topic: daa daa on anchor selection, solution for redirect during session establishment and solution for anchor switch that does not address what happens to ongoing sessions. When you do better than those, you are approaching a solution that allows one to better distribute anchors. Still very PMIPish, though. Forwarding path and signaling management refers to 'new DMM solution'? Yes.. we specifically do not refer how and based on what to achieve that. I didn't get that from the text… So is the Forwarding path and signaling management intent unclear in DMM scope? In my understanding, what we have been calling maintenance is simply PMIP/CMIP improvements/fixes in broad context -- not related to a DMM solution. On the other hand, that first bullet above does read like a DMM solution to me. I'm confused… what is maintenance, what is the objective of first bullet, what is the objective of second bullet… First bullet intent should be clear, continue PMIP where it left on this anchor part. Second bullet gives you much more freedom. That is how I divided it in my organic compute unit. - Jouni Alper - Jouni We can note that separate anchor discovery selection drafts may be produced (opening the door for split documents, while not forcing people to split any solution into two parts because the charter said so..) Alper On Jun 11, 2014, at 2:36 PM, Jouni Korhonen wrote: A heavily updated charter text in the github. I am not sure it addresses all wording concerns folks had. But.. flame on ;) Reading the telco notes I realize I do not have nor have seen the slides shown during the call, so probably the re-anchoring sanitization in the charter text went too far compared what was discussed in the call. Please check. If you have concerns on the milestones and specifically their timeline, express your opinion with a new month+year combination. The cooperation with other WGs is heavily reworded. Basically it says now that DMM can mock other protocols but those then need review ratification from the protocol owning WG, just like commonly done with DHCP RADIUS. Routing based solutions are now explicitly stated to be restricted to IGP routing domain and must not propagate routing updates outside the IGP routing domain. Regarding the enhanced mobility anchoring milestone that could also be put under maintenance:
Re: [DMM] draft charter text updates in github..
Alper, The latter bullet (forwarding path etc) is imho clearly in your 3. choice below. It can also be 2. since it is not yet stated what is the baseline protocol. The protocol solution will then determine that. The former bullet (enhanced anchoring etc) is imho clearly your 2. more than 1. It could be also partly in 3. if non-PMIP stuff is needed for the overall solution. Anyway, the baseline protocol is known - PMIP, and the solution aims to distribution within PMIP's boundaries. What is unclear here? Jouni -- Jouni Korhonen Broadcom (Sent from my mobile..) Alper Yegin alper.ye...@yegin.org kirjoitti 12.6.2014 kello 9.09: Jouni, Based on earlier discussions, and what you wrote below, there are 3 distinct things: 1. *MIP maintenance. Any bug fix or improvement not driven by DMM, but for the sake of maintaining the *MIP baseline protocols, are handled here. 2. MIP-based DMM solutions. 3. Non-MIP-based DMM solutions. I presume these 3 items map to the those two bullets in the charter. Right? I cannot clearly tell the mapping though. Alper On Jun 12, 2014, at 12:14 AM, Jouni wrote: Alper, On Jun 11, 2014, at 10:54 PM, Alper Yegin wrote: Hi Jouni, 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, for example, described in RFC 6097, 6463, and 5142. The solution should also define a mechanism for preserving ongoing mobility sessions in a single administrative or IGP routing domain, which would involve directing traffic towards the new anchor. o Forwarding path and signalling management: the mobility agent that handles the mobility signalling interacts with the network elements in the DMM network 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 anchor like network element. Define required protocol extensions to allow described forwarding path and signalling management. These above two seem inseparable. I recommend we list them as one item. Hrmph.. not sure I agree. (The separation was between anchor selection and data-path management signaling before. At that time, it was a clearer separation. But even at that time I was suggesting combining the two items. In this latest text, the separation got blurred. The title of the first item, along with references to switching, preserving sessions, directing traffic all point to the context of the second one…) I see your point/concern. Since I (personally) see the enhanced mobility anchoring more towards maintenance work, I am tempted to have these two different milestones from the beginning. We could remove the last sentence of the anchoring milestone.. So, what's called enhanced mobility anchoring refers to 'maintenance work', and It could, since we specifically point three PMIP RFCs on a related topic: daa daa on anchor selection, solution for redirect during session establishment and solution for anchor switch that does not address what happens to ongoing sessions. When you do better than those, you are approaching a solution that allows one to better distribute anchors. Still very PMIPish, though. Forwarding path and signaling management refers to 'new DMM solution'? Yes.. we specifically do not refer how and based on what to achieve that. I didn't get that from the text… So is the Forwarding path and signaling management intent unclear in DMM scope? In my understanding, what we have been calling maintenance is simply PMIP/CMIP improvements/fixes in broad context -- not related to a DMM solution. On the other hand, that first bullet above does read like a DMM solution to me. I'm confused… what is maintenance, what is the objective of first bullet, what is the objective of second bullet… First bullet intent should be clear, continue PMIP where it left on this anchor part. Second bullet gives you much more freedom. That is how I divided it in my organic compute unit. - Jouni Alper - Jouni We can note that separate anchor discovery selection drafts may be produced (opening the door for split documents, while not forcing people to split any solution into two parts because the charter said so..) Alper On Jun 11, 2014, at 2:36 PM, Jouni Korhonen wrote: A heavily updated charter text in the github. I am not sure it addresses all wording concerns folks had. But.. flame on ;) Reading the telco notes I realize I do not have nor have seen the slides shown during the call, so probably the re-anchoring sanitization in the charter text went too far compared what was
Re: [DMM] draft charter text updates in github..
Alper, 6/12/2014 10:55 AM, Alper Yegin kirjoitti: Jouni, I think I can understand and follow now, after your explanation. I cannot say the same when reading the charter text. Right. Then we just need to tweak the text, since if you have issues to parse it the IESG will have double that. I'll let others speak up. If I'm the only one having difficulty parsing that part of the charter, then so be it. Btw, I'm not aware of any decision that the baseline protocol will be PMIP. CMIP is equally on the table. Sure. For the anchoring stuff that was kind of assumed to be PMIP though. - Jouni Alper On Jun 12, 2014, at 10:25 AM, Jouni wrote: Alper, The latter bullet (forwarding path etc) is imho clearly in your 3. choice below. It can also be 2. since it is not yet stated what is the baseline protocol. The protocol solution will then determine that. The former bullet (enhanced anchoring etc) is imho clearly your 2. more than 1. It could be also partly in 3. if non-PMIP stuff is needed for the overall solution. Anyway, the baseline protocol is known - PMIP, and the solution aims to distribution within PMIP's boundaries. What is unclear here? Jouni -- Jouni Korhonen Broadcom (Sent from my mobile..) Alper Yegin alper.ye...@yegin.org kirjoitti 12.6.2014 kello 9.09: Jouni, Based on earlier discussions, and what you wrote below, there are 3 distinct things: 1. *MIP maintenance. Any bug fix or improvement not driven by DMM, but for the sake of maintaining the *MIP baseline protocols, are handled here. 2. MIP-based DMM solutions. 3. Non-MIP-based DMM solutions. I presume these 3 items map to the those two bullets in the charter. Right? I cannot clearly tell the mapping though. Alper On Jun 12, 2014, at 12:14 AM, Jouni wrote: Alper, On Jun 11, 2014, at 10:54 PM, Alper Yegin wrote: Hi Jouni, 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, for example, described in RFC 6097, 6463, and 5142. The solution should also define a mechanism for preserving ongoing mobility sessions in a single administrative or IGP routing domain, which would involve directing traffic towards the new anchor. o Forwarding path and signalling management: the mobility agent that handles the mobility signalling interacts with the network elements in the DMM network 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 anchor like network element. Define required protocol extensions to allow described forwarding path and signalling management. These above two seem inseparable. I recommend we list them as one item. Hrmph.. not sure I agree. (The separation was between anchor selection and data-path management signaling before. At that time, it was a clearer separation. But even at that time I was suggesting combining the two items. In this latest text, the separation got blurred. The title of the first item, along with references to switching, preserving sessions, directing traffic all point to the context of the second one…) I see your point/concern. Since I (personally) see the enhanced mobility anchoring more towards maintenance work, I am tempted to have these two different milestones from the beginning. We could remove the last sentence of the anchoring milestone.. So, what's called enhanced mobility anchoring refers to 'maintenance work', and It could, since we specifically point three PMIP RFCs on a related topic: daa daa on anchor selection, solution for redirect during session establishment and solution for anchor switch that does not address what happens to ongoing sessions. When you do better than those, you are approaching a solution that allows one to better distribute anchors. Still very PMIPish, though. Forwarding path and signaling management refers to 'new DMM solution'? Yes.. we specifically do not refer how and based on what to achieve that. I didn't get that from the text… So is the Forwarding path and signaling management intent unclear in DMM scope? In my understanding, what we have been calling maintenance is simply PMIP/CMIP improvements/fixes in broad context -- not related to a DMM solution. On the other hand, that first bullet above does read like a DMM solution to me. I'm confused… what is maintenance, what is the objective of first bullet, what is the objective of second bullet… First bullet intent should be clear, continue PMIP where it left on this anchor part. Second bullet gives you much more freedom. That is how I divided it in my organic compute unit. - Jouni Alper - Jouni We can note that separate anchor discovery selection drafts may be produced
Re: [DMM] draft charter text updates in github..
I don't understand why anchoring, re-anchoring are still in the charter. There is no need for these terms. We need to use general approaches in the charter such as routing, network-based, client-based. We also need to acknowledge the fact that almost all carriers will have cloud networks by the time dmm picks up, if any. So the charter should be open to the terms like virtualization, cloud, type of futuristic terminology rather than the sticky anchor terminology. Regards, Behcet On Thu, Jun 12, 2014 at 3:39 AM, Jouni Korhonen jouni.nos...@gmail.com wrote: Alper, 6/12/2014 10:55 AM, Alper Yegin kirjoitti: Jouni, I think I can understand and follow now, after your explanation. I cannot say the same when reading the charter text. Right. Then we just need to tweak the text, since if you have issues to parse it the IESG will have double that. I'll let others speak up. If I'm the only one having difficulty parsing that part of the charter, then so be it. Btw, I'm not aware of any decision that the baseline protocol will be PMIP. CMIP is equally on the table. Sure. For the anchoring stuff that was kind of assumed to be PMIP though. - Jouni Alper On Jun 12, 2014, at 10:25 AM, Jouni wrote: Alper, The latter bullet (forwarding path etc) is imho clearly in your 3. choice below. It can also be 2. since it is not yet stated what is the baseline protocol. The protocol solution will then determine that. The former bullet (enhanced anchoring etc) is imho clearly your 2. more than 1. It could be also partly in 3. if non-PMIP stuff is needed for the overall solution. Anyway, the baseline protocol is known - PMIP, and the solution aims to distribution within PMIP's boundaries. What is unclear here? Jouni -- Jouni Korhonen Broadcom (Sent from my mobile..) Alper Yegin alper.ye...@yegin.org kirjoitti 12.6.2014 kello 9.09: Jouni, Based on earlier discussions, and what you wrote below, there are 3 distinct things: 1. *MIP maintenance. Any bug fix or improvement not driven by DMM, but for the sake of maintaining the *MIP baseline protocols, are handled here. 2. MIP-based DMM solutions. 3. Non-MIP-based DMM solutions. I presume these 3 items map to the those two bullets in the charter. Right? I cannot clearly tell the mapping though. Alper On Jun 12, 2014, at 12:14 AM, Jouni wrote: Alper, On Jun 11, 2014, at 10:54 PM, Alper Yegin wrote: Hi Jouni, 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, for example, described in RFC 6097, 6463, and 5142. The solution should also define a mechanism for preserving ongoing mobility sessions in a single administrative or IGP routing domain, which would involve directing traffic towards the new anchor. o Forwarding path and signalling management: the mobility agent that handles the mobility signalling interacts with the network elements in the DMM network 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 anchor like network element. Define required protocol extensions to allow described forwarding path and signalling management. These above two seem inseparable. I recommend we list them as one item. Hrmph.. not sure I agree. (The separation was between anchor selection and data-path management signaling before. At that time, it was a clearer separation. But even at that time I was suggesting combining the two items. In this latest text, the separation got blurred. The title of the first item, along with references to switching, preserving sessions, directing traffic all point to the context of the second one…) I see your point/concern. Since I (personally) see the enhanced mobility anchoring more towards maintenance work, I am tempted to have these two different milestones from the beginning. We could remove the last sentence of the anchoring milestone.. So, what's called enhanced mobility anchoring refers to 'maintenance work', and It could, since we specifically point three PMIP RFCs on a related topic: daa daa on anchor selection, solution for redirect during session establishment and solution for anchor switch that does not address what happens to ongoing sessions. When you do better than those, you are approaching a solution that allows one to better distribute anchors. Still very PMIPish, though. Forwarding path and signaling management refers to 'new DMM solution'? Yes.. we specifically do not refer how and based on what to achieve that. I didn't get that from the text… So is the Forwarding path and signaling management intent unclear in DMM scope? In my
Re: [DMM] draft charter text updates in github..
Hi Jouni, Thank you for the revision. Here are my comments: When extending non- IP mobility protocols, solutions should be reviewed and ratified by the WGs having the ownership of those protocols. I think you mean protocols that are not based on Mobile IP instead of non-IP mobility protocols. Although Internet-wide maintenance of the stable home address(es) or prefix(es) is a desirable goal when mobile hosts/routers change their point of attachment to the network, it is not a strict requirement on the DMM solutions. Mobile hosts/routers should not assume that the home address(es) and/or home network prefix(es) remain the same throughout the entire application level session lifetime, unless such property is indicated to the mobile node/router and its applications from the network. Inserted the red text above. If the network or the mobile host/router do not support the distributed mobility management enabling protocol that should not prevent the mobile host/router gaining basic (i.e., nomadic) access to the network. Red text again… 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, for example, described in RFC 6097, 6463, and 5142. The solution should also define a mechanism for preserving ongoing mobility sessions in a single administrative or IGP routing domain, which would involve directing traffic towards the new anchor. o Forwarding path and signalling management: the mobility agent that handles the mobility signalling interacts with the network elements in the DMM network 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 anchor like network element. Define required protocol extensions to allow described forwarding path and signalling management. These above two seem inseparable. I recommend we list them as one item. (The separation was between anchor selection and data-path management signaling before. At that time, it was a clearer separation. But even at that time I was suggesting combining the two items. In this latest text, the separation got blurred. The title of the first item, along with references to switching, preserving sessions, directing traffic all point to the context of the second one…) We can note that separate anchor discovery selection drafts may be produced (opening the door for split documents, while not forcing people to split any solution into two parts because the charter said so..) Alper On Jun 11, 2014, at 2:36 PM, Jouni Korhonen wrote: A heavily updated charter text in the github. I am not sure it addresses all wording concerns folks had. But.. flame on ;) Reading the telco notes I realize I do not have nor have seen the slides shown during the call, so probably the re-anchoring sanitization in the charter text went too far compared what was discussed in the call. Please check. If you have concerns on the milestones and specifically their timeline, express your opinion with a new month+year combination. The cooperation with other WGs is heavily reworded. Basically it says now that DMM can mock other protocols but those then need review ratification from the protocol owning WG, just like commonly done with DHCP RADIUS. Routing based solutions are now explicitly stated to be restricted to IGP routing domain and must not propagate routing updates outside the IGP routing domain. Regarding the enhanced mobility anchoring milestone that could also be put under maintenance: Work items related to the PMIPv6 maintenance include: 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, for example, described in RFC 6097, 6463, and 5142. The solution should also define a mechanism for preserving ongoing mobility sessions in a single administrative or IGP routing domain, which would involve directing traffic towards the new anchor. Opinions? - Jouni 6/6/2014 5:37 PM, Alper Yegin kirjoitti: Hello Jouni, DMM folks, We better clarify what anchor re-selection stands for. If it is about selecting different anchors for different IP flows, that's one thing. If it is about changing the IP anchor in the middle of an IP flow, that's another thing. And that other thing needs to be scoped out. A basic understanding of a use case would be appreciated (just an explanation for discussion, I'm not asking for another I-D!), and identification of
Re: [DMM] draft charter text updates in github..
Hi Jouni, 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, for example, described in RFC 6097, 6463, and 5142. The solution should also define a mechanism for preserving ongoing mobility sessions in a single administrative or IGP routing domain, which would involve directing traffic towards the new anchor. o Forwarding path and signalling management: the mobility agent that handles the mobility signalling interacts with the network elements in the DMM network 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 anchor like network element. Define required protocol extensions to allow described forwarding path and signalling management. These above two seem inseparable. I recommend we list them as one item. Hrmph.. not sure I agree. (The separation was between anchor selection and data-path management signaling before. At that time, it was a clearer separation. But even at that time I was suggesting combining the two items. In this latest text, the separation got blurred. The title of the first item, along with references to switching, preserving sessions, directing traffic all point to the context of the second one…) I see your point/concern. Since I (personally) see the enhanced mobility anchoring more towards maintenance work, I am tempted to have these two different milestones from the beginning. We could remove the last sentence of the anchoring milestone.. So, what's called enhanced mobility anchoring refers to 'maintenance work', and Forwarding path and signaling management refers to 'new DMM solution'? I didn't get that from the text… In my understanding, what we have been calling maintenance is simply PMIP/CMIP improvements/fixes in broad context -- not related to a DMM solution. On the other hand, that first bullet above does read like a DMM solution to me. I'm confused… what is maintenance, what is the objective of first bullet, what is the objective of second bullet… Alper - Jouni We can note that separate anchor discovery selection drafts may be produced (opening the door for split documents, while not forcing people to split any solution into two parts because the charter said so..) Alper On Jun 11, 2014, at 2:36 PM, Jouni Korhonen wrote: A heavily updated charter text in the github. I am not sure it addresses all wording concerns folks had. But.. flame on ;) Reading the telco notes I realize I do not have nor have seen the slides shown during the call, so probably the re-anchoring sanitization in the charter text went too far compared what was discussed in the call. Please check. If you have concerns on the milestones and specifically their timeline, express your opinion with a new month+year combination. The cooperation with other WGs is heavily reworded. Basically it says now that DMM can mock other protocols but those then need review ratification from the protocol owning WG, just like commonly done with DHCP RADIUS. Routing based solutions are now explicitly stated to be restricted to IGP routing domain and must not propagate routing updates outside the IGP routing domain. Regarding the enhanced mobility anchoring milestone that could also be put under maintenance: Work items related to the PMIPv6 maintenance include: 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, for example, described in RFC 6097, 6463, and 5142. The solution should also define a mechanism for preserving ongoing mobility sessions in a single administrative or IGP routing domain, which would involve directing traffic towards the new anchor. Opinions? - Jouni 6/6/2014 5:37 PM, Alper Yegin kirjoitti: Hello Jouni, DMM folks, We better clarify what anchor re-selection stands for. If it is about selecting different anchors for different IP flows, that's one thing. If it is about changing the IP anchor in the middle of an IP flow, that's another thing. And that other thing needs to be scoped out. A basic understanding of a use case would be appreciated (just an explanation for discussion, I'm not asking for another I-D!), and identification of various aspects of that scenario which translate to work items for DMM WG. I won't be in the call today. So, consider this for a discussion. Follow up on the mailing list afterwards would be good. Cheers, Alper On Jun 6, 2014, at 2:47 PM, Jouni
Re: [DMM] draft charter text updates in github..
Alper, On Jun 11, 2014, at 10:54 PM, Alper Yegin wrote: Hi Jouni, 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, for example, described in RFC 6097, 6463, and 5142. The solution should also define a mechanism for preserving ongoing mobility sessions in a single administrative or IGP routing domain, which would involve directing traffic towards the new anchor. o Forwarding path and signalling management: the mobility agent that handles the mobility signalling interacts with the network elements in the DMM network 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 anchor like network element. Define required protocol extensions to allow described forwarding path and signalling management. These above two seem inseparable. I recommend we list them as one item. Hrmph.. not sure I agree. (The separation was between anchor selection and data-path management signaling before. At that time, it was a clearer separation. But even at that time I was suggesting combining the two items. In this latest text, the separation got blurred. The title of the first item, along with references to switching, preserving sessions, directing traffic all point to the context of the second one…) I see your point/concern. Since I (personally) see the enhanced mobility anchoring more towards maintenance work, I am tempted to have these two different milestones from the beginning. We could remove the last sentence of the anchoring milestone.. So, what's called enhanced mobility anchoring refers to 'maintenance work', and It could, since we specifically point three PMIP RFCs on a related topic: daa daa on anchor selection, solution for redirect during session establishment and solution for anchor switch that does not address what happens to ongoing sessions. When you do better than those, you are approaching a solution that allows one to better distribute anchors. Still very PMIPish, though. Forwarding path and signaling management refers to 'new DMM solution'? Yes.. we specifically do not refer how and based on what to achieve that. I didn't get that from the text… So is the Forwarding path and signaling management intent unclear in DMM scope? In my understanding, what we have been calling maintenance is simply PMIP/CMIP improvements/fixes in broad context -- not related to a DMM solution. On the other hand, that first bullet above does read like a DMM solution to me. I'm confused… what is maintenance, what is the objective of first bullet, what is the objective of second bullet… First bullet intent should be clear, continue PMIP where it left on this anchor part. Second bullet gives you much more freedom. That is how I divided it in my organic compute unit. - Jouni Alper - Jouni We can note that separate anchor discovery selection drafts may be produced (opening the door for split documents, while not forcing people to split any solution into two parts because the charter said so..) Alper On Jun 11, 2014, at 2:36 PM, Jouni Korhonen wrote: A heavily updated charter text in the github. I am not sure it addresses all wording concerns folks had. But.. flame on ;) Reading the telco notes I realize I do not have nor have seen the slides shown during the call, so probably the re-anchoring sanitization in the charter text went too far compared what was discussed in the call. Please check. If you have concerns on the milestones and specifically their timeline, express your opinion with a new month+year combination. The cooperation with other WGs is heavily reworded. Basically it says now that DMM can mock other protocols but those then need review ratification from the protocol owning WG, just like commonly done with DHCP RADIUS. Routing based solutions are now explicitly stated to be restricted to IGP routing domain and must not propagate routing updates outside the IGP routing domain. Regarding the enhanced mobility anchoring milestone that could also be put under maintenance: Work items related to the PMIPv6 maintenance include: 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, for example, described in RFC 6097, 6463, and 5142. The solution should also define a mechanism for preserving ongoing mobility sessions in a single administrative or IGP routing domain, which would involve directing traffic towards the new
Re: [DMM] draft charter text updates in github..
On Jun 6, 2014, at 6:52 PM, Alper Yegin wrote: Hi John, My reading of that sentence is different. To me it says We cannot assume that the solutions we are developing would be available on all networks across the Internet. The highlighted text intend to say: unless the mobile node is made explicitly aware (by the network) of the fact that the prefix/address it got will guarantee IP session continuity, the mobile node cannot assume it to remain unchanged infinitely when doing handovers and such.. the prefix/address may remain unchanged e.g. within a limited are e.g. as long as the mobile node remains within one administrated network domain. - JOuni While I'd agree with that statement, I don't know what it really means for our solution design. Some of our solutions may not be present in a network, hence the MN cannot use them. OK…. and?? In my reading, it does not say the following: Network cannot always provide IP session continuity, hence we need to define solutions that can deal with this. (e.g., using MPTCP, or restarting flows, or some other magic, etc.). I don't think the intent of that sentence is this. And therefore, I don't think that sentence is related to anchor re-selection. Alper On Jun 6, 2014, at 5:56 PM, John Kaippallimalil wrote: Hi Alper, All: Towards the end of the charter, there is a paragraph that states: Although the maintenance of stable home address(es) and/or prefix(es) and upper level sessions is a desirable goal when mobile hosts/routers change their point of attachment to the Internet, it is not a strict requirement. Mobile hosts/routers should not assume that IP addressing including home address(es) and/or home network prefix(es) remain the same throughout the entire upper level session lifetime, or that support for mobility functions is provided on the network side in all conditions, unless these properties are specifically indicated to the mobile node and its applications from the network. I suppose this clarifies that the “anchor re-selection” can apply to a single session also? BR, John -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alper Yegin Sent: Friday, June 06, 2014 9:38 AM To: Jouni Korhonen Cc: dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hello Jouni, DMM folks, We better clarify what anchor re-selection stands for. If it is about selecting different anchors for different IP flows, that's one thing. If it is about changing the IP anchor in the middle of an IP flow, that's another thing. And that other thing needs to be scoped out. A basic understanding of a use case would be appreciated (just an explanation for discussion, I'm not asking for another I-D!), and identification of various aspects of that scenario which translate to work items for DMM WG. I won't be in the call today. So, consider this for a discussion. Follow up on the mailing list afterwards would be good. Cheers, Alper On Jun 6, 2014, at 2:47 PM, Jouni Korhonen wrote: Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - 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] draft charter text updates in github..
On Jun 9, 2014, at 9:17 AM, Jouni wrote: On Jun 9, 2014, at 5:45 AM, Weixinpeng wrote: Hi Jouni, all, .The protocol solutions should be based on existing IP mobility protocols, either host- or network-based, such as Mobile IPv6 [RFC6275, ], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO [RFC3963]. However, mobility management in a limited area, such as within an autonomous system, is not strictly limited to mentioned IP mobility protocols but can be any existing or a new protocol solution enabling the movement of a mobile node such as routing protocols. As my understanding for this text, DMM work group aims to realize mobility management by using/extending the existing host- or network-based protocols for all the scenarios except for the limited area (relatively small network as my understanding). Right? The guidance above is to attempt to build on top of existing IP mobility protocols. However, if current IP mobility protocols are unfit for the desired use case or solution, then within a closed system i.e. not internet wide, basically anything goes such as routing based solutions or whatever folks come up with. Here the example was AS wide (which can be quite large actually). The key point the above tries to address is that whatever you do in your own administered network is your own business as long as it does not propagate to Internet. Basically, this says in limited scale, a non-MIP solution may be used. The question, for sake of clarification, is: - Is DMM WG supposed to work on such solutions as well? - Or, are we just acknowledging the fact that there may be such solutions outside the scope of DMM WG, and our solutions may have to co-exist with them. Alper - Jouni Thanks. BR Xinpeng -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Korhonen Sent: Friday, June 06, 2014 7:47 PM To: dmm@ietf.org Subject: [DMM] draft charter text updates in github.. Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.tx t IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - 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] draft charter text updates in github..
DMM is supposed to work on those solutions. In a similar manner what is done with AAA protocols, DHCP etc.. folks outside the protocol owning WG do work and at some point of time get reviews etc from there. - Jouni 6/9/2014 3:49 PM, Alper Yegin kirjoitti: Basically, this says in limited scale, a non-MIP solution may be used. The question, for sake of clarification, is: - Is DMM WG supposed to work on such solutions as well? - Or, are we just acknowledging the fact that there may be such solutions outside the scope of DMM WG, and our solutions may have to co-exist with them. Alper ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] draft charter text updates in github..
So, Jouni, Is this saying Some solutions' applicability may be limited to administrative domains (i.e., not Internet-wide), and the point is DMM WG can accept such solutions? Whatever the point we are trying to make, we better spell it out. Alper On Jun 9, 2014, at 9:35 AM, Jouni wrote: On Jun 6, 2014, at 6:52 PM, Alper Yegin wrote: Hi John, My reading of that sentence is different. To me it says We cannot assume that the solutions we are developing would be available on all networks across the Internet. The highlighted text intend to say: unless the mobile node is made explicitly aware (by the network) of the fact that the prefix/address it got will guarantee IP session continuity, the mobile node cannot assume it to remain unchanged infinitely when doing handovers and such.. the prefix/address may remain unchanged e.g. within a limited are e.g. as long as the mobile node remains within one administrated network domain. - JOuni While I'd agree with that statement, I don't know what it really means for our solution design. Some of our solutions may not be present in a network, hence the MN cannot use them. OK…. and?? In my reading, it does not say the following: Network cannot always provide IP session continuity, hence we need to define solutions that can deal with this. (e.g., using MPTCP, or restarting flows, or some other magic, etc.). I don't think the intent of that sentence is this. And therefore, I don't think that sentence is related to anchor re-selection. Alper On Jun 6, 2014, at 5:56 PM, John Kaippallimalil wrote: Hi Alper, All: Towards the end of the charter, there is a paragraph that states: Although the maintenance of stable home address(es) and/or prefix(es) and upper level sessions is a desirable goal when mobile hosts/routers change their point of attachment to the Internet, it is not a strict requirement. Mobile hosts/routers should not assume that IP addressing including home address(es) and/or home network prefix(es) remain the same throughout the entire upper level session lifetime, or that support for mobility functions is provided on the network side in all conditions, unless these properties are specifically indicated to the mobile node and its applications from the network. I suppose this clarifies that the “anchor re-selection” can apply to a single session also? BR, John -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alper Yegin Sent: Friday, June 06, 2014 9:38 AM To: Jouni Korhonen Cc: dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hello Jouni, DMM folks, We better clarify what anchor re-selection stands for. If it is about selecting different anchors for different IP flows, that's one thing. If it is about changing the IP anchor in the middle of an IP flow, that's another thing. And that other thing needs to be scoped out. A basic understanding of a use case would be appreciated (just an explanation for discussion, I'm not asking for another I-D!), and identification of various aspects of that scenario which translate to work items for DMM WG. I won't be in the call today. So, consider this for a discussion. Follow up on the mailing list afterwards would be good. Cheers, Alper On Jun 6, 2014, at 2:47 PM, Jouni Korhonen wrote: Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - 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] draft charter text updates in github..
Alper, Hmm, I already read it in a way myself I said below but that seems to be only me. I'll try to reformulate the text.. - Jouni 6/9/2014 4:24 PM, Alper Yegin kirjoitti: So, Jouni, Is this saying Some solutions' applicability may be limited to administrative domains (i.e., not Internet-wide), and the point is DMM WG can accept such solutions? Whatever the point we are trying to make, we better spell it out. Alper On Jun 9, 2014, at 9:35 AM, Jouni wrote: On Jun 6, 2014, at 6:52 PM, Alper Yegin wrote: Hi John, My reading of that sentence is different. To me it says We cannot assume that the solutions we are developing would be available on all networks across the Internet. The highlighted text intend to say: unless the mobile node is made explicitly aware (by the network) of the fact that the prefix/address it got will guarantee IP session continuity, the mobile node cannot assume it to remain unchanged infinitely when doing handovers and such.. the prefix/address may remain unchanged e.g. within a limited are e.g. as long as the mobile node remains within one administrated network domain. - JOuni While I'd agree with that statement, I don't know what it really means for our solution design. Some of our solutions may not be present in a network, hence the MN cannot use them. OK…. and?? In my reading, it does not say the following: Network cannot always provide IP session continuity, hence we need to define solutions that can deal with this. (e.g., using MPTCP, or restarting flows, or some other magic, etc.). I don't think the intent of that sentence is this. And therefore, I don't think that sentence is related to anchor re-selection. Alper On Jun 6, 2014, at 5:56 PM, John Kaippallimalil wrote: Hi Alper, All: Towards the end of the charter, there is a paragraph that states: Although the maintenance of stable home address(es) and/or prefix(es) and upper level sessions is a desirable goal when mobile hosts/routers change their point of attachment to the Internet, it is not a strict requirement. Mobile hosts/routers should not assume that IP addressing including home address(es) and/or home network prefix(es) remain the same throughout the entire upper level session lifetime, or that support for mobility functions is provided on the network side in all conditions, unless these properties are specifically indicated to the mobile node and its applications from the network. I suppose this clarifies that the “anchor re-selection” can apply to a single session also? BR, John -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alper Yegin Sent: Friday, June 06, 2014 9:38 AM To: Jouni Korhonen Cc: dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hello Jouni, DMM folks, We better clarify what anchor re-selection stands for. If it is about selecting different anchors for different IP flows, that's one thing. If it is about changing the IP anchor in the middle of an IP flow, that's another thing. And that other thing needs to be scoped out. A basic understanding of a use case would be appreciated (just an explanation for discussion, I'm not asking for another I-D!), and identification of various aspects of that scenario which translate to work items for DMM WG. I won't be in the call today. So, consider this for a discussion. Follow up on the mailing list afterwards would be good. Cheers, Alper On Jun 6, 2014, at 2:47 PM, Jouni Korhonen wrote: Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - 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] draft charter text updates in github..
Hi Jouni, all, .The protocol solutions should be based on existing IP mobility protocols, either host- or network-based, such as Mobile IPv6 [RFC6275, ], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO [RFC3963]. However, mobility management in a limited area, such as within an autonomous system, is not strictly limited to mentioned IP mobility protocols but can be any existing or a new protocol solution enabling the movement of a mobile node such as routing protocols. As my understanding for this text, DMM work group aims to realize mobility management by using/extending the existing host- or network-based protocols for all the scenarios except for the limited area (relatively small network as my understanding). Right? Thanks. BR Xinpeng -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Korhonen Sent: Friday, June 06, 2014 7:47 PM To: dmm@ietf.org Subject: [DMM] draft charter text updates in github.. Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.tx t IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - 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] draft charter text updates in github..
Can someone clarify the intent of that text? Alper On Jun 7, 2014, at 10:37 AM, Jouni wrote: Ack. John Alper, any specific wording you want to clarify? - Jouni On Jun 7, 2014, at 9:28 AM, Alper Yegin wrote: Hi John, In that case we need a clarification and refinement on that text. Alper On Jun 6, 2014, at 7:21 PM, John Kaippallimalil wrote: Hi Alper, I did not intrepret it that way. The paragraph seemed broad enough to include both (or all) cases. I found the charter to be broad enough – the current text would support a solution regardless of the specific scenario/design. But, if it the text is being interpreted in a specific way, I don’t have any serious reservations against clarification. Best Regards, John From: Alper Yegin [mailto:alper.ye...@yegin.org] Sent: Friday, June 06, 2014 10:53 AM To: John Kaippallimalil Cc: Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi John, My reading of that sentence is different. To me it says We cannot assume that the solutions we are developing would be available on all networks across the Internet. While I'd agree with that statement, I don't know what it really means for our solution design. Some of our solutions may not be present in a network, hence the MN cannot use them. OK…. and?? In my reading, it does not say the following: Network cannot always provide IP session continuity, hence we need to define solutions that can deal with this. (e.g., using MPTCP, or restarting flows, or some other magic, etc.). I don't think the intent of that sentence is this. And therefore, I don't think that sentence is related to anchor re-selection. Alper On Jun 6, 2014, at 5:56 PM, John Kaippallimalil wrote: Hi Alper, All: Towards the end of the charter, there is a paragraph that states: Although the maintenance of stable home address(es) and/or prefix(es) and upper level sessions is a desirable goal when mobile hosts/routers change their point of attachment to the Internet, it is not a strict requirement. Mobile hosts/routers should not assume that IP addressing including home address(es) and/or home network prefix(es) remain the same throughout the entire upper level session lifetime, or that support for mobility functions is provided on the network side in all conditions, unless these properties are specifically indicated to the mobile node and its applications from the network. I suppose this clarifies that the “anchor re-selection” can apply to a single session also? BR, John -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alper Yegin Sent: Friday, June 06, 2014 9:38 AM To: Jouni Korhonen Cc: dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hello Jouni, DMM folks, We better clarify what anchor re-selection stands for. If it is about selecting different anchors for different IP flows, that's one thing. If it is about changing the IP anchor in the middle of an IP flow, that's another thing. And that other thing needs to be scoped out. A basic understanding of a use case would be appreciated (just an explanation for discussion, I'm not asking for another I-D!), and identification of various aspects of that scenario which translate to work items for DMM WG. I won't be in the call today. So, consider this for a discussion. Follow up on the mailing list afterwards would be good. Cheers, Alper On Jun 6, 2014, at 2:47 PM, Jouni Korhonen wrote: Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - 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] draft charter text updates in github..
Hi John, In that case we need a clarification and refinement on that text. Alper On Jun 6, 2014, at 7:21 PM, John Kaippallimalil wrote: Hi Alper, I did not intrepret it that way. The paragraph seemed broad enough to include both (or all) cases. I found the charter to be broad enough – the current text would support a solution regardless of the specific scenario/design. But, if it the text is being interpreted in a specific way, I don’t have any serious reservations against clarification. Best Regards, John From: Alper Yegin [mailto:alper.ye...@yegin.org] Sent: Friday, June 06, 2014 10:53 AM To: John Kaippallimalil Cc: Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi John, My reading of that sentence is different. To me it says We cannot assume that the solutions we are developing would be available on all networks across the Internet. While I'd agree with that statement, I don't know what it really means for our solution design. Some of our solutions may not be present in a network, hence the MN cannot use them. OK…. and?? In my reading, it does not say the following: Network cannot always provide IP session continuity, hence we need to define solutions that can deal with this. (e.g., using MPTCP, or restarting flows, or some other magic, etc.). I don't think the intent of that sentence is this. And therefore, I don't think that sentence is related to anchor re-selection. Alper On Jun 6, 2014, at 5:56 PM, John Kaippallimalil wrote: Hi Alper, All: Towards the end of the charter, there is a paragraph that states: Although the maintenance of stable home address(es) and/or prefix(es) and upper level sessions is a desirable goal when mobile hosts/routers change their point of attachment to the Internet, it is not a strict requirement. Mobile hosts/routers should not assume that IP addressing including home address(es) and/or home network prefix(es) remain the same throughout the entire upper level session lifetime, or that support for mobility functions is provided on the network side in all conditions, unless these properties are specifically indicated to the mobile node and its applications from the network. I suppose this clarifies that the “anchor re-selection” can apply to a single session also? BR, John -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alper Yegin Sent: Friday, June 06, 2014 9:38 AM To: Jouni Korhonen Cc: dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hello Jouni, DMM folks, We better clarify what anchor re-selection stands for. If it is about selecting different anchors for different IP flows, that's one thing. If it is about changing the IP anchor in the middle of an IP flow, that's another thing. And that other thing needs to be scoped out. A basic understanding of a use case would be appreciated (just an explanation for discussion, I'm not asking for another I-D!), and identification of various aspects of that scenario which translate to work items for DMM WG. I won't be in the call today. So, consider this for a discussion. Follow up on the mailing list afterwards would be good. Cheers, Alper On Jun 6, 2014, at 2:47 PM, Jouni Korhonen wrote: Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - 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] draft charter text updates in github..
Ack. John Alper, any specific wording you want to clarify? - Jouni On Jun 7, 2014, at 9:28 AM, Alper Yegin wrote: Hi John, In that case we need a clarification and refinement on that text. Alper On Jun 6, 2014, at 7:21 PM, John Kaippallimalil wrote: Hi Alper, I did not intrepret it that way. The paragraph seemed broad enough to include both (or all) cases. I found the charter to be broad enough – the current text would support a solution regardless of the specific scenario/design. But, if it the text is being interpreted in a specific way, I don’t have any serious reservations against clarification. Best Regards, John From: Alper Yegin [mailto:alper.ye...@yegin.org] Sent: Friday, June 06, 2014 10:53 AM To: John Kaippallimalil Cc: Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi John, My reading of that sentence is different. To me it says We cannot assume that the solutions we are developing would be available on all networks across the Internet. While I'd agree with that statement, I don't know what it really means for our solution design. Some of our solutions may not be present in a network, hence the MN cannot use them. OK…. and?? In my reading, it does not say the following: Network cannot always provide IP session continuity, hence we need to define solutions that can deal with this. (e.g., using MPTCP, or restarting flows, or some other magic, etc.). I don't think the intent of that sentence is this. And therefore, I don't think that sentence is related to anchor re-selection. Alper On Jun 6, 2014, at 5:56 PM, John Kaippallimalil wrote: Hi Alper, All: Towards the end of the charter, there is a paragraph that states: Although the maintenance of stable home address(es) and/or prefix(es) and upper level sessions is a desirable goal when mobile hosts/routers change their point of attachment to the Internet, it is not a strict requirement. Mobile hosts/routers should not assume that IP addressing including home address(es) and/or home network prefix(es) remain the same throughout the entire upper level session lifetime, or that support for mobility functions is provided on the network side in all conditions, unless these properties are specifically indicated to the mobile node and its applications from the network. I suppose this clarifies that the “anchor re-selection” can apply to a single session also? BR, John -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alper Yegin Sent: Friday, June 06, 2014 9:38 AM To: Jouni Korhonen Cc: dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hello Jouni, DMM folks, We better clarify what anchor re-selection stands for. If it is about selecting different anchors for different IP flows, that's one thing. If it is about changing the IP anchor in the middle of an IP flow, that's another thing. And that other thing needs to be scoped out. A basic understanding of a use case would be appreciated (just an explanation for discussion, I'm not asking for another I-D!), and identification of various aspects of that scenario which translate to work items for DMM WG. I won't be in the call today. So, consider this for a discussion. Follow up on the mailing list afterwards would be good. Cheers, Alper On Jun 6, 2014, at 2:47 PM, Jouni Korhonen wrote: Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - 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] draft charter text updates in github..
Hi Alper, All: Towards the end of the charter, there is a paragraph that states: Although the maintenance of stable home address(es) and/or prefix(es) and upper level sessions is a desirable goal when mobile hosts/routers change their point of attachment to the Internet, it is not a strict requirement. Mobile hosts/routers should not assume that IP addressing including home address(es) and/or home network prefix(es) remain the same throughout the entire upper level session lifetime, or that support for mobility functions is provided on the network side in all conditions, unless these properties are specifically indicated to the mobile node and its applications from the network. I suppose this clarifies that the anchor re-selection can apply to a single session also? BR, John -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alper Yegin Sent: Friday, June 06, 2014 9:38 AM To: Jouni Korhonen Cc: dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hello Jouni, DMM folks, We better clarify what anchor re-selection stands for. If it is about selecting different anchors for different IP flows, that's one thing. If it is about changing the IP anchor in the middle of an IP flow, that's another thing. And that other thing needs to be scoped out. A basic understanding of a use case would be appreciated (just an explanation for discussion, I'm not asking for another I-D!), and identification of various aspects of that scenario which translate to work items for DMM WG. I won't be in the call today. So, consider this for a discussion. Follow up on the mailing list afterwards would be good. Cheers, Alper On Jun 6, 2014, at 2:47 PM, Jouni Korhonen wrote: Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - Jouni ___ dmm mailing list dmm@ietf.orgmailto:dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.orgmailto: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] draft charter text updates in github..
John, Correct. -- Jouni Korhonen Broadcom (Sent from my mobile..) John Kaippallimalil john.kaippallima...@huawei.com kirjoitti 6.6.2014 kello 17.56: Hi Alper, All: Towards the end of the charter, there is a paragraph that states: Although the maintenance of stable home address(es) and/or prefix(es) and upper level sessions is a desirable goal when mobile hosts/routers change their point of attachment to the Internet, it is not a strict requirement. Mobile hosts/routers should not assume that IP addressing including home address(es) and/or home network prefix(es) remain the same throughout the entire upper level session lifetime, or that support for mobility functions is provided on the network side in all conditions, unless these properties are specifically indicated to the mobile node and its applications from the network. I suppose this clarifies that the “anchor re-selection” can apply to a single session also? BR, John -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alper Yegin Sent: Friday, June 06, 2014 9:38 AM To: Jouni Korhonen Cc: dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hello Jouni, DMM folks, We better clarify what anchor re-selection stands for. If it is about selecting different anchors for different IP flows, that's one thing. If it is about changing the IP anchor in the middle of an IP flow, that's another thing. And that other thing needs to be scoped out. A basic understanding of a use case would be appreciated (just an explanation for discussion, I'm not asking for another I-D!), and identification of various aspects of that scenario which translate to work items for DMM WG. I won't be in the call today. So, consider this for a discussion. Follow up on the mailing list afterwards would be good. Cheers, Alper On Jun 6, 2014, at 2:47 PM, Jouni Korhonen wrote: Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - 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] draft charter text updates in github..
As posted earlier in an email, I propose to keep the anchor (re)selection decoupled from mid-session or between-session aspects. I think we should have one solution for anchor selection, that can be used also to select a new one during runtime if needed. How to treat bindings in case of mid-session re-selection, is a different thing. It's about importing mobility states into the new selected anchor. Associated Traffic steering I see in a separate document, which is currently named 'forwarding path and signaling management'. marco -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Sent: Freitag, 6. Juni 2014 17:06 To: Alper Yegin Cc: dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Good point Alper. Lets hash that anchor reselection details out shortly. -- Jouni Korhonen Broadcom (Sent from my mobile..) Alper Yegin alper.ye...@yegin.org kirjoitti 6.6.2014 kello 17.37: Hello Jouni, DMM folks, We better clarify what anchor re-selection stands for. If it is about selecting different anchors for different IP flows, that's one thing. If it is about changing the IP anchor in the middle of an IP flow, that's another thing. And that other thing needs to be scoped out. A basic understanding of a use case would be appreciated (just an explanation for discussion, I'm not asking for another I-D!), and identification of various aspects of that scenario which translate to work items for DMM WG. I won't be in the call today. So, consider this for a discussion. Follow up on the mailing list afterwards would be good. Cheers, Alper On Jun 6, 2014, at 2:47 PM, Jouni Korhonen wrote: Folks, Minor changes.. https://github.com/jounikor/dmm-re- charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - 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] draft charter text updates in github..
Hi John, Hi Alper, Yes, that was the intention of having that text about “anchor re-selection” in the paragraph! Of course, the “anchor re-selection” should apply to an ongoing session! Best regards, Georgios PS. I am afraid that I cannot attend the telco! Van: dmm [dmm-boun...@ietf.org] namens John Kaippallimalil [john.kaippallima...@huawei.com] Verzonden: vrijdag 6 juni 2014 16:56 Aan: Alper Yegin; Jouni Korhonen CC: dmm@ietf.org Onderwerp: Re: [DMM] draft charter text updates in github.. Hi Alper, All: Towards the end of the charter, there is a paragraph that states: Although the maintenance of stable home address(es) and/or prefix(es) and upper level sessions is a desirable goal when mobile hosts/routers change their point of attachment to the Internet, it is not a strict requirement. Mobile hosts/routers should not assume that IP addressing including home address(es) and/or home network prefix(es) remain the same throughout the entire upper level session lifetime, or that support for mobility functions is provided on the network side in all conditions, unless these properties are specifically indicated to the mobile node and its applications from the network. I suppose this clarifies that the “anchor re-selection” can apply to a single session also? BR, John -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alper Yegin Sent: Friday, June 06, 2014 9:38 AM To: Jouni Korhonen Cc: dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hello Jouni, DMM folks, We better clarify what anchor re-selection stands for. If it is about selecting different anchors for different IP flows, that's one thing. If it is about changing the IP anchor in the middle of an IP flow, that's another thing. And that other thing needs to be scoped out. A basic understanding of a use case would be appreciated (just an explanation for discussion, I'm not asking for another I-D!), and identification of various aspects of that scenario which translate to work items for DMM WG. I won't be in the call today. So, consider this for a discussion. Follow up on the mailing list afterwards would be good. Cheers, Alper On Jun 6, 2014, at 2:47 PM, Jouni Korhonen wrote: Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - Jouni ___ dmm mailing list dmm@ietf.orgmailto:dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.orgmailto: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] draft charter text updates in github..
Hi John, My reading of that sentence is different. To me it says We cannot assume that the solutions we are developing would be available on all networks across the Internet. While I'd agree with that statement, I don't know what it really means for our solution design. Some of our solutions may not be present in a network, hence the MN cannot use them. OK…. and?? In my reading, it does not say the following: Network cannot always provide IP session continuity, hence we need to define solutions that can deal with this. (e.g., using MPTCP, or restarting flows, or some other magic, etc.). I don't think the intent of that sentence is this. And therefore, I don't think that sentence is related to anchor re-selection. Alper On Jun 6, 2014, at 5:56 PM, John Kaippallimalil wrote: Hi Alper, All: Towards the end of the charter, there is a paragraph that states: Although the maintenance of stable home address(es) and/or prefix(es) and upper level sessions is a desirable goal when mobile hosts/routers change their point of attachment to the Internet, it is not a strict requirement. Mobile hosts/routers should not assume that IP addressing including home address(es) and/or home network prefix(es) remain the same throughout the entire upper level session lifetime, or that support for mobility functions is provided on the network side in all conditions, unless these properties are specifically indicated to the mobile node and its applications from the network. I suppose this clarifies that the “anchor re-selection” can apply to a single session also? BR, John -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alper Yegin Sent: Friday, June 06, 2014 9:38 AM To: Jouni Korhonen Cc: dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hello Jouni, DMM folks, We better clarify what anchor re-selection stands for. If it is about selecting different anchors for different IP flows, that's one thing. If it is about changing the IP anchor in the middle of an IP flow, that's another thing. And that other thing needs to be scoped out. A basic understanding of a use case would be appreciated (just an explanation for discussion, I'm not asking for another I-D!), and identification of various aspects of that scenario which translate to work items for DMM WG. I won't be in the call today. So, consider this for a discussion. Follow up on the mailing list afterwards would be good. Cheers, Alper On Jun 6, 2014, at 2:47 PM, Jouni Korhonen wrote: Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - 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] draft charter text updates in github..
Hi Alper, I did not intrepret it that way. The paragraph seemed broad enough to include both (or all) cases. I found the charter to be broad enough - the current text would support a solution regardless of the specific scenario/design. But, if it the text is being interpreted in a specific way, I don't have any serious reservations against clarification. Best Regards, John From: Alper Yegin [mailto:alper.ye...@yegin.org] Sent: Friday, June 06, 2014 10:53 AM To: John Kaippallimalil Cc: Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hi John, My reading of that sentence is different. To me it says We cannot assume that the solutions we are developing would be available on all networks across the Internet. While I'd agree with that statement, I don't know what it really means for our solution design. Some of our solutions may not be present in a network, hence the MN cannot use them. OK and?? In my reading, it does not say the following: Network cannot always provide IP session continuity, hence we need to define solutions that can deal with this. (e.g., using MPTCP, or restarting flows, or some other magic, etc.). I don't think the intent of that sentence is this. And therefore, I don't think that sentence is related to anchor re-selection. Alper On Jun 6, 2014, at 5:56 PM, John Kaippallimalil wrote: Hi Alper, All: Towards the end of the charter, there is a paragraph that states: Although the maintenance of stable home address(es) and/or prefix(es) and upper level sessions is a desirable goal when mobile hosts/routers change their point of attachment to the Internet, it is not a strict requirement. Mobile hosts/routers should not assume that IP addressing including home address(es) and/or home network prefix(es) remain the same throughout the entire upper level session lifetime, or that support for mobility functions is provided on the network side in all conditions, unless these properties are specifically indicated to the mobile node and its applications from the network. I suppose this clarifies that the anchor re-selection can apply to a single session also? BR, John -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alper Yegin Sent: Friday, June 06, 2014 9:38 AM To: Jouni Korhonen Cc: dmm@ietf.orgmailto:dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Hello Jouni, DMM folks, We better clarify what anchor re-selection stands for. If it is about selecting different anchors for different IP flows, that's one thing. If it is about changing the IP anchor in the middle of an IP flow, that's another thing. And that other thing needs to be scoped out. A basic understanding of a use case would be appreciated (just an explanation for discussion, I'm not asking for another I-D!), and identification of various aspects of that scenario which translate to work items for DMM WG. I won't be in the call today. So, consider this for a discussion. Follow up on the mailing list afterwards would be good. Cheers, Alper On Jun 6, 2014, at 2:47 PM, Jouni Korhonen wrote: Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - Jouni ___ dmm mailing list dmm@ietf.orgmailto:dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.orgmailto:dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
