Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
An explicit DHCP exchange (maybe for just a prefix) seems like the cleanest approach and the assignment state machine is properly decoupled from the state of the link. However, many people seem to prefer SLAAC (almost religiously) so the tracking of used addresses plus NUD after some timeout is what we settled on in prefixcost. Sent from HUAWEI AnyOffice From:Moses, Danny To:Peter McCann,Lorenzo Colitti Cc:draft-ietf-dmm-ondemand-mobil...@ietf.org,dmm@ietf.org Date:2016-12-06 06:02:48 Subject:RE: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 Well, although the network allocates prefixes it could keep track of addresses that were constructed from those prefixes and initiate NUD on these addresses… Personally, I don’t believe in designs that rely on MNs to volunteer to provide such information. The better approach is to have a finite lease time for prefixes (like DHCP does) and force the MN to request lease extensions – if they required. Could that be a reasonable approach? Danny From: Peter McCann [mailto:peter.mcc...@huawei.com] Sent: Monday, December 05, 2016 21:02 To: Moses, Danny <danny.mo...@intel.com>; Lorenzo Colitti <lore...@google.com> Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org Subject: RE: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 In the prefixcost draft, we handwaved a solution that would keep soft state in the network and have the network initiate NUD when it hadn’t seen a given address being used by the MN for a while. However, NUD only works on individual addresses not whole prefixes. It might be good to have an explicit message from a MN that says “I am done using this prefix” but this problem is bigger than DMM. I am not sure what is the right solution. -Pete From: Moses, Danny [mailto:danny.mo...@intel.com] Sent: Monday, December 05, 2016 1:01 PM To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>; Lorenzo Colitti <lore...@google.com<mailto:lore...@google.com>> Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>; dmm@ietf.org<mailto:dmm@ietf.org> Subject: RE: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 That is correct. Do we need a draft about freeing addresses/prefixes? Regards, Danny From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Peter McCann Sent: Monday, December 05, 2016 17:43 To: Lorenzo Colitti <lore...@google.com<mailto:lore...@google.com>> Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 That may work for communicating the allocation state of the prefix to the MN, but too frequent advertisements may chew up precious wireless bandwidth. Also, it doesn’t solve the problem of allowing the network to detect when the MN is done using the prefix. -Pete From: Lorenzo Colitti [mailto:lore...@google.com] Sent: Sunday, December 04, 2016 9:21 PM To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 Agreed; if we want to support this sort of mobility it needs to be possible to tell a MN that its previous prefix is no longer valid. >From a technical perspective this can be done using router advertisements, >except for the 2-hour rule in RFC 4862 section 5.3.3. That rule exists to >prevent DOS attacks on shared links, so I think it would be reasonable to >update RFC 4862 to say that less-than-2-hour valid lifetimes are acceptable if >the link provides strong guarantees that there are no other nodes on link that >can mount such an attack. On Fri, Dec 2, 2016 at 12:36 PM, Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote: Agree, I am not arguing in favor of sharing a prefix between two or more MNs at the same time. However, I think it is important to reclaim a prefix for use by another MN after the current MN has moved to a new attachment point and stopped using the prefix it got from the old attachment point. It is also important to refrain from advertising the prefix to another MN until the current MN has stopped using it. That is the network state I am talking about. -Pete From: Lorenzo Colitti [mailto:lore...@google.com<mailto:lore...@google.com>] Sent: Friday, December 02, 2016 3:32 PM To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-
Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
The problem with using link status is that the MN may want to keep the prefix even after it has moved off link. It may also break the other way: the MN wants to give up the prefix while it stays on link. We need to decouple the prefix assignment from the link status. Sent from HUAWEI AnyOffice From:Lorenzo Colitti To:Peter McCann Cc:Moses, Danny,draft-ietf-dmm-ondemand-mobil...@ietf.org,dmm@ietf.org Date:2016-12-06 06:43:31 Subject:Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 The network can't do NUD for a prefix, but it can do NUD for the link-local IPv6 address that sent the RS that caused it to announce the prefix. Even better would be to make it the responsibility of the link layer to let the network know if the MN is still attached. Most link layers used in mobile networks have to do this anyway. On Mon, Dec 5, 2016 at 11:02 AM, Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote: In the prefixcost draft, we handwaved a solution that would keep soft state in the network and have the network initiate NUD when it hadn’t seen a given address being used by the MN for a while. However, NUD only works on individual addresses not whole prefixes. It might be good to have an explicit message from a MN that says “I am done using this prefix” but this problem is bigger than DMM. I am not sure what is the right solution. -Pete From: Moses, Danny [mailto:danny.mo...@intel.com<mailto:danny.mo...@intel.com>] Sent: Monday, December 05, 2016 1:01 PM To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>; Lorenzo Colitti <lore...@google.com<mailto:lore...@google.com>> Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>; dmm@ietf.org<mailto:dmm@ietf.org> Subject: RE: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 That is correct. Do we need a draft about freeing addresses/prefixes? Regards, Danny From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Peter McCann Sent: Monday, December 05, 2016 17:43 To: Lorenzo Colitti <lore...@google.com<mailto:lore...@google.com>> Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 That may work for communicating the allocation state of the prefix to the MN, but too frequent advertisements may chew up precious wireless bandwidth. Also, it doesn’t solve the problem of allowing the network to detect when the MN is done using the prefix. -Pete From: Lorenzo Colitti [mailto:lore...@google.com] Sent: Sunday, December 04, 2016 9:21 PM To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 Agreed; if we want to support this sort of mobility it needs to be possible to tell a MN that its previous prefix is no longer valid. >From a technical perspective this can be done using router advertisements, >except for the 2-hour rule in RFC 4862 section 5.3.3. That rule exists to >prevent DOS attacks on shared links, so I think it would be reasonable to >update RFC 4862 to say that less-than-2-hour valid lifetimes are acceptable if >the link provides strong guarantees that there are no other nodes on link that >can mount such an attack. On Fri, Dec 2, 2016 at 12:36 PM, Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote: Agree, I am not arguing in favor of sharing a prefix between two or more MNs at the same time. However, I think it is important to reclaim a prefix for use by another MN after the current MN has moved to a new attachment point and stopped using the prefix it got from the old attachment point. It is also important to refrain from advertising the prefix to another MN until the current MN has stopped using it. That is the network state I am talking about. -Pete From: Lorenzo Colitti [mailto:lore...@google.com<mailto:lore...@google.com>] Sent: Friday, December 02, 2016 3:32 PM To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 On the particular case of shared links: note that they have substantial scalability and performance issues. In order for shared links to work you have to engage in DAD proxying, ND
Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
In the prefixcost draft, we handwaved a solution that would keep soft state in the network and have the network initiate NUD when it hadn’t seen a given address being used by the MN for a while. However, NUD only works on individual addresses not whole prefixes. It might be good to have an explicit message from a MN that says “I am done using this prefix” but this problem is bigger than DMM. I am not sure what is the right solution. -Pete From: Moses, Danny [mailto:danny.mo...@intel.com] Sent: Monday, December 05, 2016 1:01 PM To: Peter McCann <peter.mcc...@huawei.com>; Lorenzo Colitti <lore...@google.com> Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org Subject: RE: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 That is correct. Do we need a draft about freeing addresses/prefixes? Regards, Danny From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Peter McCann Sent: Monday, December 05, 2016 17:43 To: Lorenzo Colitti <lore...@google.com<mailto:lore...@google.com>> Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 That may work for communicating the allocation state of the prefix to the MN, but too frequent advertisements may chew up precious wireless bandwidth. Also, it doesn’t solve the problem of allowing the network to detect when the MN is done using the prefix. -Pete From: Lorenzo Colitti [mailto:lore...@google.com] Sent: Sunday, December 04, 2016 9:21 PM To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 Agreed; if we want to support this sort of mobility it needs to be possible to tell a MN that its previous prefix is no longer valid. From a technical perspective this can be done using router advertisements, except for the 2-hour rule in RFC 4862 section 5.3.3. That rule exists to prevent DOS attacks on shared links, so I think it would be reasonable to update RFC 4862 to say that less-than-2-hour valid lifetimes are acceptable if the link provides strong guarantees that there are no other nodes on link that can mount such an attack. On Fri, Dec 2, 2016 at 12:36 PM, Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote: Agree, I am not arguing in favor of sharing a prefix between two or more MNs at the same time. However, I think it is important to reclaim a prefix for use by another MN after the current MN has moved to a new attachment point and stopped using the prefix it got from the old attachment point. It is also important to refrain from advertising the prefix to another MN until the current MN has stopped using it. That is the network state I am talking about. -Pete From: Lorenzo Colitti [mailto:lore...@google.com<mailto:lore...@google.com>] Sent: Friday, December 02, 2016 3:32 PM To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 On the particular case of shared links: note that they have substantial scalability and performance issues. In order for shared links to work you have to engage in DAD proxying, ND snooping, client isolation and all sorts of unsavoury and L2/L3 magic that does not scale. Some of these issues are described in RFC 7934 section 9.3. On shared links, these forces act to reduce the number of IP addresses per host that the network can support and leads to the negative consequences in section 4 of the document, which is why they are not recommended. For these and other reasons, on many public networks we're seeing a shift *away* from shared links - see, for example, draft-ietf-v6ops-unique-ipv6-prefix-per-host , and the current large deployments of that model in the form of Comcast community wifi. For many years 3GPP networks have been providing those benefits by providing a full /64 to every host. I would hate to lose those benefits. On Fri, Dec 2, 2016 at 12:12 PM, Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote: With a fixed access network the prefix can be assigned to the link and used by anyone who joins the link. With a prefix offering mobility the prefix belongs to the mobile host and needs to move with it. There aren’t enough prefixes (even in IPv6) to assign a permanent prefix t
Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
That may work for communicating the allocation state of the prefix to the MN, but too frequent advertisements may chew up precious wireless bandwidth. Also, it doesn’t solve the problem of allowing the network to detect when the MN is done using the prefix. -Pete From: Lorenzo Colitti [mailto:lore...@google.com] Sent: Sunday, December 04, 2016 9:21 PM To: Peter McCann <peter.mcc...@huawei.com> Cc: jouni.nospam <jouni.nos...@gmail.com>; draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 Agreed; if we want to support this sort of mobility it needs to be possible to tell a MN that its previous prefix is no longer valid. From a technical perspective this can be done using router advertisements, except for the 2-hour rule in RFC 4862 section 5.3.3. That rule exists to prevent DOS attacks on shared links, so I think it would be reasonable to update RFC 4862 to say that less-than-2-hour valid lifetimes are acceptable if the link provides strong guarantees that there are no other nodes on link that can mount such an attack. On Fri, Dec 2, 2016 at 12:36 PM, Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote: Agree, I am not arguing in favor of sharing a prefix between two or more MNs at the same time. However, I think it is important to reclaim a prefix for use by another MN after the current MN has moved to a new attachment point and stopped using the prefix it got from the old attachment point. It is also important to refrain from advertising the prefix to another MN until the current MN has stopped using it. That is the network state I am talking about. -Pete From: Lorenzo Colitti [mailto:lore...@google.com<mailto:lore...@google.com>] Sent: Friday, December 02, 2016 3:32 PM To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 On the particular case of shared links: note that they have substantial scalability and performance issues. In order for shared links to work you have to engage in DAD proxying, ND snooping, client isolation and all sorts of unsavoury and L2/L3 magic that does not scale. Some of these issues are described in RFC 7934 section 9.3. On shared links, these forces act to reduce the number of IP addresses per host that the network can support and leads to the negative consequences in section 4 of the document, which is why they are not recommended. For these and other reasons, on many public networks we're seeing a shift *away* from shared links - see, for example, draft-ietf-v6ops-unique-ipv6-prefix-per-host , and the current large deployments of that model in the form of Comcast community wifi. For many years 3GPP networks have been providing those benefits by providing a full /64 to every host. I would hate to lose those benefits. On Fri, Dec 2, 2016 at 12:12 PM, Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote: With a fixed access network the prefix can be assigned to the link and used by anyone who joins the link. With a prefix offering mobility the prefix belongs to the mobile host and needs to move with it. There aren’t enough prefixes (even in IPv6) to assign a permanent prefix to each UE for every topological attachment point that it might visit or start a session from. -Pete From: Lorenzo Colitti [mailto:lore...@google.com<mailto:lore...@google.com>] Sent: Friday, December 02, 2016 3:09 PM To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 But you have that problem with IP addresses as well, right? I don't see how "assigning a prefix with certain properties" requires more state in the network than "assigning an IP address with certain properties". On Fri, Dec 2, 2016 at 12:00 PM, Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote: Providing any kind of mobility service for a prefix will require some state somewhere in the network. It would be great to avoid an allocation request / response for the prefix, but the state has to be created somehow before the UE can use the prefix and it has to be reclaimed eventually after the UE stops using the prefix (which may not be until well after it disconnects from the current link and moves to another one). Would
Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
Agree, I am not arguing in favor of sharing a prefix between two or more MNs at the same time. However, I think it is important to reclaim a prefix for use by another MN after the current MN has moved to a new attachment point and stopped using the prefix it got from the old attachment point. It is also important to refrain from advertising the prefix to another MN until the current MN has stopped using it. That is the network state I am talking about. -Pete From: Lorenzo Colitti [mailto:lore...@google.com] Sent: Friday, December 02, 2016 3:32 PM To: Peter McCann <peter.mcc...@huawei.com> Cc: jouni.nospam <jouni.nos...@gmail.com>; draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 On the particular case of shared links: note that they have substantial scalability and performance issues. In order for shared links to work you have to engage in DAD proxying, ND snooping, client isolation and all sorts of unsavoury and L2/L3 magic that does not scale. Some of these issues are described in RFC 7934 section 9.3. On shared links, these forces act to reduce the number of IP addresses per host that the network can support and leads to the negative consequences in section 4 of the document, which is why they are not recommended. For these and other reasons, on many public networks we're seeing a shift *away* from shared links - see, for example, draft-ietf-v6ops-unique-ipv6-prefix-per-host , and the current large deployments of that model in the form of Comcast community wifi. For many years 3GPP networks have been providing those benefits by providing a full /64 to every host. I would hate to lose those benefits. On Fri, Dec 2, 2016 at 12:12 PM, Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote: With a fixed access network the prefix can be assigned to the link and used by anyone who joins the link. With a prefix offering mobility the prefix belongs to the mobile host and needs to move with it. There aren’t enough prefixes (even in IPv6) to assign a permanent prefix to each UE for every topological attachment point that it might visit or start a session from. -Pete From: Lorenzo Colitti [mailto:lore...@google.com<mailto:lore...@google.com>] Sent: Friday, December 02, 2016 3:09 PM To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 But you have that problem with IP addresses as well, right? I don't see how "assigning a prefix with certain properties" requires more state in the network than "assigning an IP address with certain properties". On Fri, Dec 2, 2016 at 12:00 PM, Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote: Providing any kind of mobility service for a prefix will require some state somewhere in the network. It would be great to avoid an allocation request / response for the prefix, but the state has to be created somehow before the UE can use the prefix and it has to be reclaimed eventually after the UE stops using the prefix (which may not be until well after it disconnects from the current link and moves to another one). Would welcome any suggestions on how to manage this state. -Pete From: dmm [mailto:dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org>] On Behalf Of Lorenzo Colitti Sent: Friday, December 02, 2016 12:04 PM To: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>> Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 Hi, I like the goal of reducing network cost by allowing the use of IP addresses that do not require network mobility, but we should not be doing this by requesting IP addresses from the network, because this violates IPv6 address assignment best practices. Specifically, RFC 7934 recommends that a) the network should provide multiple addresses from each prefix and b) the network should allow the host to use new addresses without requiring explicit requests to the network. This is in conflict with at least this text in the draft, which says: In case an application requests one, the IP stack shall make an attempt to configure one by issuing a request to the network. If the operation fails, the IP stack shall fail the associated socket request One way to resolve this conflict would be to say that the network must not assign individual addresses, but /64 (or shorter) prefixes. So if the device desires to use
Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
Maybe I missed Lorenzo's point and talked past him, though. I agree we should be talking about the state maintained for a prefix and not individual addresses. At least, for IPv6. There is still a state management problem and we need to decide whether explicit signaling is required. -Pete -Original Message- From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Sent: Friday, December 02, 2016 3:15 PM To: Peter McCann <peter.mcc...@huawei.com> Cc: Lorenzo Colitti <lore...@google.com>; draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 Lorenzo, It is 3GPP practice (or law, should I say) is to assign a prefix in IPv6 to the UE. That is what Peter is talking about. Regards, Behcet On Fri, Dec 2, 2016 at 2:12 PM, Peter McCann <peter.mcc...@huawei.com> wrote: > With a fixed access network the prefix can be assigned to the link and > used by anyone who joins the link. > > > > With a prefix offering mobility the prefix belongs to the mobile host > and needs to move with it. There aren’t enough prefixes (even in > IPv6) to assign a permanent prefix to each UE for every topological > attachment point that it might visit or start a session from. > > > > -Pete > > > > > > From: Lorenzo Colitti [mailto:lore...@google.com] > Sent: Friday, December 02, 2016 3:09 PM > To: Peter McCann <peter.mcc...@huawei.com> > Cc: jouni.nospam <jouni.nos...@gmail.com>; > draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org > Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 > > > > But you have that problem with IP addresses as well, right? I don't > see how "assigning a prefix with certain properties" requires more > state in the network than "assigning an IP address with certain properties". > > > > On Fri, Dec 2, 2016 at 12:00 PM, Peter McCann > <peter.mcc...@huawei.com> > wrote: > > Providing any kind of mobility service for a prefix will require some > state somewhere in the network. It would be great to avoid an > allocation request / response for the prefix, but the state has to be > created somehow before the UE can use the prefix and it has to be > reclaimed eventually after the UE stops using the prefix (which may > not be until well after it disconnects from the current link and moves to > another one). > > > > Would welcome any suggestions on how to manage this state. > > > > -Pete > > > > > > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Lorenzo Colitti > Sent: Friday, December 02, 2016 12:04 PM > To: jouni.nospam <jouni.nos...@gmail.com> > Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org > Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 > > > > Hi, > > > > I like the goal of reducing network cost by allowing the use of IP > addresses that do not require network mobility, but we should not be > doing this by requesting IP addresses from the network, because this > violates IPv6 address assignment best practices. > > > > Specifically, RFC 7934 recommends that a) the network should provide > multiple addresses from each prefix and b) the network should allow > the host to use new addresses without requiring explicit requests to the > network. > This is in conflict with at least this text in the draft, which says: > > > >In case an application > >requests one, the IP stack shall make an attempt to configure one > by > >issuing a request to the network. If the operation fails, the IP > >stack shall fail the associated socket request > > > > One way to resolve this conflict would be to say that the network must > not assign individual addresses, but /64 (or shorter) prefixes. So if > the device desires to use fixed IPv6 addresses, then the network > should give the host a fixed IPv6 prefix from which the host can form > as many addresses as it wants. > > > > I do not think we should advance this document until the conflicts are > resolved. This document is about IPv6 address assignment to mobile > nodes, and we should not publish a document about IPv6 address > assignment that conflicts with best current practices on IPv6 address > assignment. > > > > Regards, > > Lorenzo > > > > On Mon, Nov 28, 2016 at 12:56 PM, jouni.nospam > <jouni.nos...@gmail.com> > wrote: > > Folks, > > > > The authors of draft-ietf-dmm-ondemand-mobility-07 and > draft-sijeon-dmm-use-cases-api-source have come up with a merged > document draft-ietf-dmm-ondemand-mobility-08. > > > > This email starts a
Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt
We need more than just a binary value. Those tunnels can be long, medium, short, or non-existent. We do in fact embed the prefix cost in korhonen-dmm-prefix-properties (we reference it in the draft). I don't think DHCP is the right protocol to carry this information. If you believe, as I think you do, that the prefix property will change upon handover to a new AR then we shouldn't tie the transmission of the information to the DHCP state machine. We should not force DHCP to run on every handover. -Pete From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, October 29, 2015 2:54 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Sure. But, if this all boils down to marking a prefix as a local prefix , or a remove prefix (as in this example), then its more a capability indicator and not a cost indicator. Prefix-cost can be viewed as a property as the value in there has no significance any more and it always converge to a binary value. I also suspect Jouni might be wondering as why his earlier draft, (draft-korhonen-dmm-local-prefix-01) cannot meet the requirement here, it can tell what is local prefix and what is remote prefix. I'm also thinking why the much more generic prefix property scheme (draft-bhandari-dhc-class-based-prefix, draft-korhonen-dmm-prefix-properties) does not help here. At least there, inherently there is an aspect of an application selecting a prefix based on its requirements and not have the network blindly assume the application requirement and select a gateway that it believes is the best for the application. Sri From: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Date: Wednesday, October 28, 2015 at 10:44 AM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.com>>, "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>> Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt The application should always prefer the lowest cost prefix (the more local one). What is wrong with that? The only reason you would use a higher cost prefix is because you had a session already established on that prefix and needed to keep using it. -Pete From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Wednesday, October 28, 2015 12:42 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt If you look at the network design of any SP's network archtecture, they ensure the latency between two points in the back-haul network does not exceed "n" msecs. So, there is a local gateway and two remote gateways, the new logic that inserted in the access gateway will give you prefix-cost of 1, 2 and 2. What does the client pick ? Local prefix with prefix-cost 1 or 2 ? It always coverges to local or remote, similar to the current home or roam. If there is any latency differential, that is largely due to radio or the application server, and the prefix cost does not include either of them. Fundamentally, the approach of application selecting a prefix that is based on some thing called prefix-cost, for which there is no published algorithm is not some thing I'm able to follow. > I agree it might be wise to consult 6man and also MIF. Ack; I don't know if MIF guys would have a clue about this, but 6man and Routing guys may give some sensible feedback. Sri From: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Date: Monday, October 26, 2015 at 6:22 PM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.com>>, "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>> Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt I don't understand why you think it needs to be so complicated. It seems much simpler than the other prefix coloring approaches I have seen being suggested, and much easier to see how applications would use the information. I agree it might be wise to consult 6man and also MIF. Perhaps Brian can suggest how to open the discussion to those other groups. -Pete From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Monday, October 26, 2015 6:14 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt We are attempting to solve the problem in the wrong layers and/or wrong protocols. Traditionally,
Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt
Right it's not about measuring latency (the MN can do that itself at the transport layer). It is really about the network topology and the business relationships between providers. If I am borrowing a home address from a remote provider, and they are charging me for it while I deliver it on-link to the current AR of the MN (using tunneling, routing, whatever) I need to somehow reflect that fact to the MN and discourage the use of the prefix for new connections. However, I am willing to keep it on-link for as long as the MN has old connections that are still using it. Similar considerations can apply even within the same provider if I have moved too far from the initial point of assignment - there is a cross-regional tunnel in place that is costing me OpEx to maintain. I would like to gently urge the MN to stop using that prefix, when it is convenient for the MN to do so. -Pete From: John Kaippallimalil Sent: Thursday, October 29, 2015 4:41 PM To: Sri Gundavelli (sgundave); Peter McCann; dmm@ietf.org Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt It does not have to be as dynamic or complex. Just the topology of the network and resources used in forwarding introduces enough variable costs. Also, backhaul network costs being insignificant is probably valid now, but with radio bandwidth increases of 100 -1000 times (some trials plan to exceed even this with cmw, mmw) in dense radio networks , backhaul costs and first hop route is going to be a big problem. In the draft we've referred to these requirements from NGMN in the Motivation section. At this point, I think we are assuming different architectural (and other) assumptions. Lets discuss in Yokohama. BR, John From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, October 29, 2015 2:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt I don't think this is about a new option, vs an extension to existing option in some draft. I'm trying to understand the practical use for that prefix-cost parameter. The idea that every base station/AP/some access node is constantly doing measurements on the high-speed backhaul links and using that measurement in gateway selection appears to be a very expensive proposition and the real value of that approach is the question here. The difference in the back haul measurements between a access gateway and any gateway will be insignificant as these are high-speed pipes; the difference is always the air interface, or the application server. We should discuss this in Yokohoma. Sri From: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Date: Thursday, October 29, 2015 at 11:58 AM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.com>>, "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>> Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt We need more than just a binary value. Those tunnels can be long, medium, short, or non-existent. We do in fact embed the prefix cost in korhonen-dmm-prefix-properties (we reference it in the draft). I don't think DHCP is the right protocol to carry this information. If you believe, as I think you do, that the prefix property will change upon handover to a new AR then we shouldn't tie the transmission of the information to the DHCP state machine. We should not force DHCP to run on every handover. -Pete From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, October 29, 2015 2:54 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Sure. But, if this all boils down to marking a prefix as a local prefix , or a remove prefix (as in this example), then its more a capability indicator and not a cost indicator. Prefix-cost can be viewed as a property as the value in there has no significance any more and it always converge to a binary value. I also suspect Jouni might be wondering as why his earlier draft, (draft-korhonen-dmm-local-prefix-01) cannot meet the requirement here, it can tell what is local prefix and what is remote prefix. I'm also thinking why the much more generic prefix property scheme (draft-bhandari-dhc-class-based-prefix, draft-korhonen-dmm-prefix-properties) does not help here. At least there, inherently there is an aspect of an application selecting a prefix based on its requirements and not have the network blindly assume the application requirement and select a gateway that it believes is the best for the application. Sri From: Peter McCa
Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt
I don't understand why you think it needs to be so complicated. It seems much simpler than the other prefix coloring approaches I have seen being suggested, and much easier to see how applications would use the information. I agree it might be wise to consult 6man and also MIF. Perhaps Brian can suggest how to open the discussion to those other groups. -Pete From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Monday, October 26, 2015 6:14 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt We are attempting to solve the problem in the wrong layers and/or wrong protocols. Traditionally, such aspects are managed in routing protocols, DNS layers or in vendor specific schemes. Some of the vendors such as Akamai has a entire business built around this for CDN selection. There are sophisticated measurement techniques. There are also other query based schemes with DNS. DNS SRV records are specifically introduced for such localized node selection; Directory services based on LDAP/MSFT AD use such schemes. We can certainly bring that complexity into the access gateway and into ND, and without being prescriptive on the approach, or how it even remotely helps in address selection on an application basis, but I do not see any one using it. I will not repeat my other comments, but I'm not convinced this even works, or if the choice of the protocol is right. I suggest we should get this reviewed in 6MAN WG and get some better feedback. cheers Sri From: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Date: Monday, October 26, 2015 at 8:18 AM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.com>>, "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>> Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt An MN may not use the lowest-cost prefix because it has an ongoing session with a previously-assigned, but now higher cost, prefix. We have to leave the address release decision up to the MN because the network does not have a reference count for the addresses. That only exists inside the MN. This problem space is very much like a routing protocol. There are multiple (inbound) routes that the MN is selecting from. The network needs to provide a hint about which prefix is the most local, direct path to the Internet. The network has the topology information, but we don't necessarily want to send a map of the operator's network to the MN. So, I think encapsulating this information in a single cost metric is both necessary and appropriate. -Pete From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Friday, October 23, 2015 11:22 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Ok. But, if you send multiple prefixes with different Prefix-Cost values, how will that be used is still the question ? As you said, Prefix-Cost is local to that operator, we don't publish the algorithm, its just a number, and and the MN only knows a bigger value means its most preferred. If I've two apps, why will I not ever use a best cost prefix ? Does this not all finally converge to "most-preferred" vs "not-preferred" tags and with Prefix-Cost value playing no role in the address selection ? I understand the point around selecting a gateway which has "shorter tunnel", but I'm afraid prefix-cost alone is not sufficient. This is about path characterization and it cannot be represented as a single parameter. If we want Apps to make meaningful use of it, there needs to be many additional parameters and more than that I do not believe ND is the right container for presenting such data. May be this should be part of routing protocols ? This is like bringing BGP attributes to Neighbor Discovery, IMO. Sri From: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Date: Friday, October 23, 2015 at 6:33 AM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.com>>, "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>> Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt We can't send just a single prefix (lowest cost), taking away the higher-cost prefixes, because the network doesn't know how many outstanding references (open sockets) there are for the high-cost prefix, and it doesn't know the damage it would
Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt
An MN may not use the lowest-cost prefix because it has an ongoing session with a previously-assigned, but now higher cost, prefix. We have to leave the address release decision up to the MN because the network does not have a reference count for the addresses. That only exists inside the MN. This problem space is very much like a routing protocol. There are multiple (inbound) routes that the MN is selecting from. The network needs to provide a hint about which prefix is the most local, direct path to the Internet. The network has the topology information, but we don't necessarily want to send a map of the operator's network to the MN. So, I think encapsulating this information in a single cost metric is both necessary and appropriate. -Pete From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Friday, October 23, 2015 11:22 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Ok. But, if you send multiple prefixes with different Prefix-Cost values, how will that be used is still the question ? As you said, Prefix-Cost is local to that operator, we don't publish the algorithm, its just a number, and and the MN only knows a bigger value means its most preferred. If I've two apps, why will I not ever use a best cost prefix ? Does this not all finally converge to "most-preferred" vs "not-preferred" tags and with Prefix-Cost value playing no role in the address selection ? I understand the point around selecting a gateway which has "shorter tunnel", but I'm afraid prefix-cost alone is not sufficient. This is about path characterization and it cannot be represented as a single parameter. If we want Apps to make meaningful use of it, there needs to be many additional parameters and more than that I do not believe ND is the right container for presenting such data. May be this should be part of routing protocols ? This is like bringing BGP attributes to Neighbor Discovery, IMO. Sri From: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Date: Friday, October 23, 2015 at 6:33 AM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.com>>, "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>> Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt We can't send just a single prefix (lowest cost), taking away the higher-cost prefixes, because the network doesn't know how many outstanding references (open sockets) there are for the high-cost prefix, and it doesn't know the damage it would cause by breaking those ongoing sessions. The MN needs to explicitly release a prefix when it is no longer using it. Why would you tell me that I am not allowed to distinguish between a long tunnel and a short tunnel? They impose dramatically different costs on the network operator, and we will need to inform the MN about this so it can move its applications off of the high-cost prefix and on to the lower cost prefixes. I also don't see the reason to expose the network mobility management scheme to the MN. Why does the MN care that it's a tunnel being used, and not a set of routing table entries? -Pete From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Friday, October 23, 2015 12:59 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt I've not payed attention to that discussion on the fixed/sustaining/nomadic address types. But, I don't see much relation to this specific extension around "prefix-cost" and the drafts dealing with colorometry. I thought the starting point here was about delivering a prefix-cost which is about characterizing of a path cost as some number or some representation of topological distance; its not dealing with properties or capabilities and at least the draft does not talk about that. Staying in that context, per my earlier question, its unclear how the end point will ever pick an address that has lower prefix-cost value, when there is another prefix with a better prefix-cost value. The prefix-cost has only one implied meaning, bigger the better. The same can be achieved by sending a single prefix was my point. Now, regarding the specific shade of grey that you are looking in my color palette :), I don't see an issue there. As long as you can give a property name for each of your fifty shades of grey and have a printed card for each of those colors, the AR will decorate the ND container with the right set of cards and ship it out on the wire. These properties have well defined meaning that can be used by ap
Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt
We can't send just a single prefix (lowest cost), taking away the higher-cost prefixes, because the network doesn't know how many outstanding references (open sockets) there are for the high-cost prefix, and it doesn't know the damage it would cause by breaking those ongoing sessions. The MN needs to explicitly release a prefix when it is no longer using it. Why would you tell me that I am not allowed to distinguish between a long tunnel and a short tunnel? They impose dramatically different costs on the network operator, and we will need to inform the MN about this so it can move its applications off of the high-cost prefix and on to the lower cost prefixes. I also don't see the reason to expose the network mobility management scheme to the MN. Why does the MN care that it's a tunnel being used, and not a set of routing table entries? -Pete From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Friday, October 23, 2015 12:59 AM To: Peter McCann; John Kaippallimalil; dmm@ietf.org Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt I've not payed attention to that discussion on the fixed/sustaining/nomadic address types. But, I don't see much relation to this specific extension around "prefix-cost" and the drafts dealing with colorometry. I thought the starting point here was about delivering a prefix-cost which is about characterizing of a path cost as some number or some representation of topological distance; its not dealing with properties or capabilities and at least the draft does not talk about that. Staying in that context, per my earlier question, its unclear how the end point will ever pick an address that has lower prefix-cost value, when there is another prefix with a better prefix-cost value. The prefix-cost has only one implied meaning, bigger the better. The same can be achieved by sending a single prefix was my point. Now, regarding the specific shade of grey that you are looking in my color palette :), I don't see an issue there. As long as you can give a property name for each of your fifty shades of grey and have a printed card for each of those colors, the AR will decorate the ND container with the right set of cards and ship it out on the wire. These properties have well defined meaning that can be used by applications for matching the app requirement with the address capabilities. We can certainly argue that we can define infinite # number of properties (with the long/short tunnel example) and we are back in square one, but thats a name space management issue and we will not allow such color definitions. This is different from the prefix-cost issue, where the algorithm is unknown and the value has no universal meaning and my point there its not helping the end point in address selection. Sri From: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> Date: Thursday, October 22, 2015 at 5:00 PM To: Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.com>>, "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>> Subject: RE: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Ok, now I think we are getting somewhere. I was assuming you were part of the consensus that has seemed to form around "fixed", "sustained", and "nomadic" as the only 3 colors. I hope we agree that those three values don't really mean anything when sent from the network to the host. They might make sense in some kind of internal operating system API, but that's a separate question. Now I think we are just debating the size and scope of the color pallette. In your example, you have a bit that represents "tunneling in effect". However, there are long tunnels and there are short tunnels. A tunnel from the previous base station to the current base station, which are connected by a single Ethernet cable, is no big deal. However, a tunnel to a foreign network where the prefix was originally assigned may be using up substantial resources and may be costing the visited operator real money due to interconnection fees. I would like to be able to distinguish between these two cases. In general, the MN just wants to know "how much pain am I causing the network operator by holding on to this prefix?" The MN doesn't need to know or care about what kind of mechanism (tunneling, routing, or carrier pigeon) is being used to direct packets destined for the IP address to his current point of attachment. He can just make use of a simple scalar value that represents the degree of the operator's desire to move him to a more local, less costly prefix. Simple administratively configured scalar values are used like this all the time in rou
Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt
cable or BBF network. The host and network mechanisms are in some way related: for example, host is dynamically configured with S14 or OMA-DM, and the network should use the same rules to determine what prefix cost information is sent by the AR in Router Advertisements. I do agree that the draft does not explicitly say about how the network side is handled (i.e., similar to the chapter on host considerations). We can add a section like "Network Considerations" and state how host/network work to deliver consistent prefix cost (but also that the values are out of scope) - would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Wednesday, October 14, 2015 12:38 PM To: John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt John: How would the AR know the cost of a prefix ? Assuming the AR is taking the role of a access gateway and the projected prefix is from a remote gateway, how would it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some arbitrary cost metric; those capabilities in the form of attributes allow the MN to pick up a right prefix. So, I'm not sure how the AR computes this cost and how the end points make use of this value. Sri From: dmm <dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org>> on behalf of John Kaippallimalil <john.kaippallima...@huawei.com<mailto:john.kaippallima...@huawei.com>> Date: Wednesday, October 14, 2015 at 9:19 AM To: "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>> Subject: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt Hi, We have posted a new version of the Prefix Cost draft (please see submission below). The comments addressed include that from the last meeting, as well as discussions on the reflector regarding how this cost can be provided to the host: 1. What is the motivation - what costs are being optimized [added entire chapter on Motivation] 2. Does this require additional signaling? [No additional signaling incurred in this mechanism - sub option of RA] 3. Does this impact L2 events? [Not responding to link layer /L2 events] 4. Is this addressing e2e aspects of flow, etc? [No e2e proposed; that is for MPTCP and others.] 5. What is host/application behavior when prefix cost changes? The updates provide some details on what can/should be done in the host. I think that detailed mechanisms should be addressed in a companion/other draft related to APIs, etc. But, it would be interesting to hear other views. Would appreciate comments and suggestions. John -Original Message- From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> [mailto:internet-dra...@ietf.org] Sent: Tuesday, October 13, 2015 2:37 PM To: John Kaippallimalil; Peter McCann; Peter McCann Subject: New Version Notification for draft-mccann-dmm-prefixcost-02.txt A new version of I-D, draft-mccann-dmm-prefixcost-02.txt has been successfully submitted by John Kaippallimalil and posted to the IETF repository. Name: draft-mccann-dmm-prefixcost Revision: 02 Title:Communicating Prefix Cost to Mobile Nodes Document date:2015-10-13 Group:Individual Submission Pages:9 URL: https://www.ietf.org/internet-drafts/draft-mccann-dmm-prefixcost-02.txt Status: https://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcost/ Htmlized: https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-mccann-dmm-prefixcost-02 Abstract: In a network implementing Distributed Mobility Management, it has been agreed that Mobile Nodes (MNs) should exhibit agility in their use of IP addresses. For example, an MN might use an old address for ongoing socket connections but use a new, locally assigned address for new socket connections. Determining when to assign a new address, and when to release old addresses, is currently an open problem. Making an optimal decision about address assignment and release must involve a tradeoff in the amount of signaling used to allocate the new addresses, the amount of utility that applications are deriving from the use of a previously assigned address, and the cost of maintaining an address that was assigned at a previous point of attachment. As the MN moves farther and farther from the initial point where an address was assigned, more and more resources are used to redirect packets destined for that IP address to its current location. The MN currently does not know the amount of resources used as this depends on mobility path and internal routing topology of the network(s) which are kno
Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02
Hi, Satoru, Thanks for the answers - I think I understand better now. Let me just confirm a few points below... Satoru Matsushima wrote: Hi Peter, On Sat, Mar 29, 2014 at 3:32 AM, Peter McCann peter.mcc...@huawei.com wrote: Ryuji, After viewing your slides from the presentation you did overnight (sorry I couldn'tbe on the call) I went back and re-read the draft-matushima- stateless-uplane-vepc-02draft. I am still confused about a number of things: Thanks. Let me try to answer your questions. You show in Figure 4, step 15 a Route Update (is this a BGP UPDATE?) going from the EPC-E to the core network RTR, containing a Destination of UE- prefix and a Next-Hop of EPC-E address. However, in Section 3.4, you describe the RTR as knowing only the PDN prefix, which is the same for all EPC-E, and the use of hot- potato routing to deliver the packets to the nearest EPC-E no matter the UE destination IP address. Which one is it? Are the UE prefixes advertised into the core or not? No, it isn't meant that specific routes to indicate each UEs prefix are advertised into the core. I'll try to improve that text in next revision of the draft. Yes please clarify because the current text seems to say that UE prefixes are advertised into the core. Assuming for now that the UE prefixes are not advertised into the core, but only the PDN prefixes are advertised, then that means that every EPC-E must know about every UE session, including the eNB F-TEID for every UE in the network, correct? Yes, it's correct. That's because any one of them at any time could receive a packet for the UE from the core. This doesn't seem scalable to me. I agree with you if a EPC-E has whole UE specific routes that exceed its capacity, it doesn't scale, yes. In the recent presentation through the webex, Ryuji were trying to explain that it's not intended to do. Routes contained in EPC-E will be limited/partitioned by operators policy, such as region, service, population scale, etc., I was a bit confused by the suggestion to partition by region, because there would be no mobility across regions if you partitioned in this way. That's because different regions would use different PDN prefixes. But, I suppose it would be ok to do this if you didn't need to support UE mobility across regions (or if you used OTT mobility such as client MIP for those cases). You seem to attempt to address this issue in Section 4.1 when you talk about multiple sets of EPC-E devices, each one dedicated to a given geographic region. Ah, no. Sec 4.1 is intended to explain just scalability issue, and how to deal that issues with routing techniques in operation. Ok, I guess in the most common case you would have several slices of EPC-E, each set serving a different PDN prefix and a different set of UEs. There would be one EPC-E from each slice, each representing a partition of the PDN prefixes, at each EPC-E deployment site between eNBs and core. A given UE's current location would need to be BGP UPDATEd to each of the EPC-E in the slice that covered that UE's PDN prefix. It seems to me that each set of EPC-E could cover no more than the scope covered by a singleSGW today, because they each have the same amount of state as an SGW. Essentially you have described how to build a replicated SGW with failover to different nodesbased on the re-convergence of BGP after a failure (presumably you could get the core network to react to the closure of a BGP TCP session). So I think this addresses the problem of fault-tolerance that has been identified with the tunnel-based solutions, but not really the scalability bottleneck problem. The nature of BGP makes easy to do that. I think Sec 3.4 would be right place to explain that. But I couldn't see that flavor of text in sec 4.1. Would you point which text in Sec 4.1 makes you confuse? It was the text in the penultimate paragraph that talked about partitioning by region. If you do that, there is no mobility across regions, right? But if you partition by PDN prefix (sets of UEs) then you can have a whole stack of EPC-E at each deployment site, covering the entire population of UEs. In fact, if you consider mobility from one set to another, if you want to keep the UE's IP address, you would need to broadcast the same set of PDN prefixes from all sets of EPC-E. In fact this would mean that all EPC-E throughout the network, even if they are in different sets, need to be prepared to handle packets for any UE and so they ALL would need the eNB F-TEIDs for ALL UEs. Please tell me where I have made a mistake. No, an EPC-E just only receives packets from v6 core network toward UEs that routes installed into EPC-E. Because of that an EPC-E should advertise
Re: [DMM] re-charter text updated
I think our extensions should be to the prefix information option and not DHCP. The properties of an address may change after a handover and we should not couple the DHCP state machine (which is about lease renewal) to the handover state machine. -Pete pierrick.se...@orange.com wrote: -Message d'origine- De : Jouni Korhonen [mailto:jouni.nos...@gmail.com] Envoyé : jeudi 20 mars 2014 10:00 À : SEITE Pierrick IMT/OLN Cc : Alper Yegin; dmm@ietf.org Objet : Re: [DMM] re-charter text updated On Mar 20, 2014, at 4:44 PM, pierrick.se...@orange.com wrote: -Message d'origine- De : dmm [mailto:dmm-boun...@ietf.org] De la part de Alper Yegin Envoyé : jeudi 20 mars 2014 09:42 À : Jouni Korhonen Cc : dmm@ietf.org Objet : Re: [DMM] re-charter text updated On Mar 20, 2014, at 10:30 AM, Jouni Korhonen wrote: On Mar 20, 2014, at 2:58 PM, Alper Yegin alper.ye...@yegin.org wrote: Hi Jouni, On Mar 20, 2014, at 6:03 AM, Jouni Korhonen wrote: o Mobility state exposing I-D. This would communication between the end host and the network. Maybe also covering the missing parts within the end host.. Are we OK with one I-D or how people want to see this? o .. There's the API aspect on the terminal (one I-D), and there is the MN-network interface ones (e.g., extending RA, DHCP, etc.) So you want an API document? I have some reservations documenting an APIs as-is. Could this be an extension to RFC5014? I'd see this approach feasible since there are even (partial) implementations of the RFC5014 in popular operating systems. Yes, we are talking about extensions to source address selection (RFC 5014). Ack. Then the subsequent thing. Each MN-NW interface would be one document, if I understand the above comment correctly? Which one(s) to do first? ND or/and DHCP? Yes. Both. Ack. Since we are coming up with I-D numbers, any preference on the protocols that we patch..? between ND and DHCP? DHCP.. I'd say ND first :-)... but, anyway, do we really need two different documents? Although, container differs, I guess extensions will be the same. Second the ND thing ;) Why two docs.. DHCP is usually easy going as you can practically shove a flock of pigeons into it and people are just fine. ND is always a different story ;) Ok, I got it... - JOuni Alper - Jouni Alper - JOuni Alper - Jouni On Mar 17, 2014, at 2:41 PM, Jouni Korhonen jouni.nos...@gmail.com wrote: Folks, I have updated the charter draft text slightly: https://github.com/jounikor/dmm-re- charter/blob/master/recharter_ draft.txt Basically: Added Sri's comment on PMIPv6 maintenance. Added Alper's comment of location of mobility functions. Added links to other IETF WGs on possible mobility enabling technologies. Added a comment that virtualised network functions are in scope. - Jouni ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ ___ ___ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. __ _ __ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or
Re: [DMM] Preparing for DMM future steps and rechartering
Hi, Brian, Brian Haberman wrote: Hi Pete, Speaking with no hat on... On 11/12/13 4:29 PM, Peter McCann wrote: Hi, Sri, Even if we agree that those services are necessary (and I would point out once again that most of them are not beneficial to the end-user) I don't think we should be architecting the network in such a way that we lose the basic benefits of IP (shortest path routing and fault-tolerance). We can implement those services without taking all the packets to a central location; maybe just the first packet or meta-information about the first packet can be taken to an SDN controller that can make some decision and pass it down to the user plane. I really don't think this is such fantastic science-fiction. ;) The degree to which this is science fiction really depends on what scope you think these host routes will have in the routing system. * Are you assuming mobility within a single enterprise or Autonomous System? Yes, at the most this will be one AS. * Limited mobility within a consortium of networks? No. At the most this will be one AS, possibly less depending on scalability. * Is this global mobility for any/all nodes? No. I think global mobility should be handled with client MIP because we should not assume any relationship between previous/next visited networks. The Boeing experiment (not science fiction, but also not scalable) tried global mobility with BGP: Dul, A., Global IP Network Mobility using Border Gateway Protocol (BGP), Available at: http://quark.net/docs/Global_IP_Network_Mobility_using_BGP.pdf This obviously wouldn't work for billions of MNs. But, with DMM people are starting to realize that MNs don't need completely stable global addresses that live forever. So I think DMM should focus on localized mobility management. Regards, Brian -Pete ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Preparing for DMM future steps and rechartering
Hi, Alex,
When it comes to injecting routes into the routing infrastructure,
I think we have to use the proxy model. It doesn't make sense for
the MN to be speaking to the access network's routing protocol. This
means the MAG will need to authenticate the MN and check that the
IP addresses assigned to that MN ID were in fact really assigned to
that MN. I think it can be done easily with forward/reverse DNS
lookups.
Sri, if we can make the tunnels a fall-back mechanism for use only
when the MN has moved too far to make the routing update scalable,
then yes, we can eliminate the PMIP signaling from the access network.
I think client MIP should be used when we need to fall back - especially
because there is likely to be no relationship between the previous and
new domains, other than the fact that they are both connected to the
Internet.
-Pete
Alexandru Petrescu wrote:
Sri,
Sorry if my mail was too direct. It is not my intention to suggest
getting rid of anything.
Frankly speaking I don't know what DMM is, and I still have to review
the draft-ietf-dmm-best-practices-gap-analysis-02
Whenever one says one particular protocol I have a problem with each.
For example, but just an example, I have growing problems articulating
an explanation of the lack of MIP deployment.
Deployment, testing and prototype interest are valuable indicators.
Alex
Le 11/11/2013 17:08, Sri Gundavelli (sgundave) a écrit :
Alex - So, the proposal is to get rid of the MIP signaling plane and
piggyback on some routing updates, or over OpenFlow ? So, what is
the result, we use a generic non-MIP interfaces and make them look
like MIP interfaces ? What is the point ? This is DMM ?
Regards Sri
On 11/11/13 7:51 AM, Alexandru Petrescu
alexandru.petre...@gmail.com wrote:
I think it may converge.
I am not sure whether we have reached a point where we can discuss
without assuming a particular protocol (i.e. neither MIP, nor BGP),
but I think we can discuss route update method vs tunnel-based
method.
We can also discuss whether new functionality is needed on the mobile
entity, vs whether the first-hop router does much on its behalf
('proxy'). Which may bring in a question of whether a Mobile Host or
a Mobile Router is considered.
Effects of route updates may be too heavy on a network ('route
churn') or less so; it may depend, among several factors, on the
topology and the addressing architecture of the fixed network.
Routing protocols are highly distributed concepts, yet many include
particularly designated entities, which have particular roles (not
all routers are equal) - these could host what we expect to be more
controlling points.
Alex
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] [netext] Chair review of I-D: draft-ietf-netext-pd-pmip (05)
Hi, Jouni, jouni korhonen wrote: Pete, On Nov 26, 2012, at 5:54 PM, Peter McCann wrote: [budget cut scale removal of text] hop router, and traffic is always tunneled directly back to that router. In contrast, PMIP has the MAG as the first hop router. This is a fundamental difference that IMHO makes it more likely to see a link flap on a MAG to MAG handover, even when the same LMA is reachable from both. If the LMA stays the same, the link does not flap. I don't see how you can make a blanket statement like this for all link layers that might be used for PMIP. In particular, it seems to require a knowledge, at the L2, of whether the current MAG can see the same LMA. This knowledge needs to be propagated across the link to the client, and used to determine whether the link down/up event propagates through the IP stack. Perhaps your particular implementation experience involved carrying such a signal but I cannot imagine that it holds true for every L2, especially if they were not designed with PMIP in mind. I am just reflecting the nature of existing point-to-point L2 technologies. They tend to be session oriented, ref PPP and 3GPP stuff. Even when a WLAN type of technology is twisted to resemble point-to-point (and with authentication) you can make it session aware.. with limitations. And if the whole user session is between UE and the LMA, then any leg losing the session usually torn down the whole pipe including your L2. My point is that L2 is torn down/rebuilt even when the LMA is reachable and the PMIP session stays up. I am curious to learn what point-to-point L2 technologies you have in mind? Something already on the field or on the drawing board? Take PPP as an example. The PPP session would be between the MN and the MAG. There would clearly need to be a new LCP/IPCP exchange between the MN and a new MAG, even if the new MAG could get back to the same LMA. In this case PPP experiences link down/ up but the PMIP session is preserved. This is distinct from the 3GPP link layer where the p2p session is between MN and PGW. The PGW is the first hop router. PMIP has the MAG as the first hop router. When you disconnect from one first hop router and connect to another first hop router, the link flaps unless you have taken special measures to hide this event from the IP stack. [smaller cost cut scale removal of text] I repeat what I said earlier. If the LMA changes the L2 session goes down, prefixes may change etc. It is a bit more than just link up/down because it also involves setting up a new PMIP session L2 session. (on L2 technologies I am concerned with). You seem to be implying that the L2 technology has a notion of a PMIP session. The layered protocol model would seem to discourage this, and I can imagine that many link layers are designed without PMIP in mind. I do not have a PMIP aware L2 in mind. See above. Just a point-to-point L2 that has a notion of session itself i.e. one has to explicitly set it up and it can be disconnected at will by either end. But in PMIP the L2 is terminated between MN and MAG. Change of MAG means tearing down one L2 session and establishing a new one. Hence it seems more natural to me to experience a link flap than to go to the extra effort to hide this from the IP stack in some special cases (which involve the network topology behind the MAG, something that is usually not visible to L2). [snip] Assuming RFC6543 is not used and we do assign different link- locals, then it is up to the LMA decide when to use which link-local. Two examples: each LMA has its own or each PMIP session gets its own unique link-local. Both cases have possibility of address collisions but are quite unlikely. I do not really care about coverage areas rather the case when something happened on the emulated home link and for that case the two examples would be sufficient. Note that I am not prompting such solution. Did you mean to say up to the MAG? I am not sure I like the idea of the LMA controlling the MAG's link-local address. No.. or lets say my wording was imprecise. Whether this feature is enabled depends on the MAG configuration. If MAG allows the LMA to generate the link-local, then LMA does it and MAG uses that address. In that case the LMA decides when to use which link-local address. It would still require coordination between the old LMA and the new LMA, precisely in those situations where no such coordination is possible (the PMIP domains are distinct and unconnected). It is just a matter of will. OUIs are invented and EUI-64 is big hefty number. Collision would be less probable than me winning in lottery. However, this would probably be a task to some other SDO to arrange than IETF. Sure, I agree this is possible. But, it seems even more natural to me to allow every MAG to have its own link-local address that is globally unique. I guess I am calling into question
Re: [DMM] Multicast requirements
jouni korhonen wrote: Folks, This mail is to kick off the discussion on multicast requirement(s) for the draft-ietf-dmm-requirements-02 document. I hope we can nail down the essential multicast requirement(s) as soon as possible. To me, multicast in a DMM environment means joining multicast groups directly from access routers. It means re-joining the multicast tree from a new access router after handover. I would hope that we can use existing MLD protocols between the MN and its first hop AR to accomplish this. -Pete ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00
Hi, Marco, Thanks for the response. See below. Marco Liebsch wrote: Hi Pete, please see inline for my response. -Original Message- From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Peter McCann Sent: Mittwoch, 7. November 2012 20:41 To: dmm@ietf.org Subject: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00 Let me ask a question to make sure I understand the approach this document takes to analyzing the problem space. In the Introduction, you state: The initial version of this draft introduces a basic set of FEs and interfaces between these FEs to support IP address continuity in DMM, without being specific to the used mobility management protocol, which operates below the mobility anchor. And later, you introduce the FE_MA to represent this mobility anchor. I *think* you are trying to define DMM as something that runs above another mobility management protocol. That would imply a solution and that is not intended. The four defined DMM FEs can be mapped to components of existing protocols. My intention is to define DMM FEs, which enable DMM use cases but are not dependent on a mobility protocol. So, some functions can be applied to existing components of, say, iBGP in a route reflector, or a LISP resolver. But some components can be placed on a Mobile IP Home Agent or even a Mobile Node. Then we can analyze if the function of the DMM FE is implicitly supported by the existing protocol or if an extension is needed. That's the rationale behind these FEs. The FE_MA is mentioned as existing component and assumed as topological anchor of the MN's IP address. Some or all DMM FEs may apply to the existing MA. Depends on the analysis we want to perform. Ok I understand that you want to put some of your components in the existing mobility anchor (and at least the FE_MA would be there) but you also seem to be distinguishing between a DMM protocol that runs *above* the FE_MA and another mobility protocol that runs *below* the FE_MA. Is that a correct interpretation? Would it be legal to set the FE_MA equal to the access router, and the other mobility management protocol to NULL? That is, would it be allowed in your framework to use *only* the DMM protocol to get packets to an AR, to which the MN is currently attached? Yes, legal from my perspective :-) Good. It seems to me that designating the leaf node in your architecture as containing FE_MA is confusing because there may in fact be no mobility protocol running between FE_MA and AR (they may be one and the same entity). Section 3 states: Imported HoA/HNP of a mobile node will be treated as identifier and non-routable IP address (prefix), as it probably does not match the new mobility anchor's location in the topology. I disagree. The old address (prefix) will need to be routable at least inside the new anchor point. If this anchor point is directly connected to the MN (i.e., it is the AR) then the route will be to a local link address. If this new anchor point uses a tunnel to get the packets to the MN, then the old address will be routable to the tunnel interface. The assumption is of course that below a mobility anchor (FE_MA) the mobility protocol performs location tracking and tunnel management or whatever. Sure, but at least one node needs to have a route for the old IP address, even if it is just a route to a local tunnel interface. The defined DMM FEs enable the required level of indirection above or at the mobility anchor. Right this reflects my understanding of your two-layer model. I am just wondering why we can't further decouple ourselves from the mobility protocol that may exist beneath the FE_MA. It may not exist or may only be at L2 (or L1). Elsewhere in Section 3: Forwarding can be for example accomplished by an IP tunnel to the egress function, address translation to a routable IP address or other means. I hope that other means can include installing an actual route for the destination IP on routers between the ingress and egress. Yes. Good. I'd be happy to provide a diagram and text to show how draft-mccann- dmm- flatarch can fit into this functional framework. In the language of your draft, I think that the FE_MAs are integrated with the ARs, the FE_MCTX is the DNS server that stores the UE's current address, FE_E is co-located on the currently serving AR, and FE_I and FE_IEC are made up of a distributed network of routers running BGP (there is no single point of failure for FE_I). I have that picture in mind, just lack of time caused mapping examples to be weak in version 00. I received other feedback and version 01 is actually there. I'd be happy if you contribute to the draft with our picture and text. By the way, the main motivation of the DMM FEs was to allow analysis beyond mobility protocols, hence including your solution proposal. I see the iBGP solution as hop-by-hop
[DMM] Comments on draft-zuniga-dmm-gap-analysis-02
Section 2.1.1 states: current Mobile IPv6 / NEMO specifications do not allow the use of multiple home agents by a mobile node simultaneously What exactly is the technical limitation prohibiting this simultaneous use? As I understand it, there is no problem running two simultaneous home addresses each of which can be bound to the same care-of address. Section 2.1.4 suggests that the Home Agent switch can be used to trigger a change of HA when there are no ongoing sessions that need address continuity. How is the HA supposed to determine that this condition holds? The knowledge about ongoing sessions is inside the MN. Section 2.1.5 talks about flow mobility but the relationship to DMM is not clear. Section 2.2: Service Data Gateway (SGW) I think this should be Serving Data Gateway. Also, you should talk about the tunnel between eNB and SGW. DMM will have the most impact if we can replace those tunneling protocols too. Section 2.2.1: On the other hand, as soon as the mobile node moves, the resulting path starts to deviate from the optimal one. You should note that this situation may be acceptable as long as the session is short-lived, and a new address is used for new sessions. Section 2.2.2 compares X2 to the PMIP local routing. I don't think this is a good comparison. X2 is used to forward traffic for a single mobile node between a previous and new eNB. In contrast, the local routing solutions are about routing traffic between two different MNs. Section 2.2.3, you state that SIPTO has no mechanism for seamless session continuity if you move out of the coverage area of a local PGW. But really, there is no technical reason why you couldn't open up a GTP tunnel to the old PGW from the new network. Note also there is a double negative in the last sentence of Section 2.2.3: cannot not survive. The draft seems to consider existing protocols only in isolation; however, I think there is something to be gained by considering combinations of the existing protocols. For example, a network-based mobility solution could be used for localized mobility management within a given domain (where the sub-optimality would be somewhat limited) and then a client-based mobility solution could be used for handling mobility outside of this domain. If a network-based mobility scheme is used to handle the client-based Care-of Address, then most of the disadvantages of the client-based mobility scheme (frequent updates over-the-air to the HA) disappear. -- Peter J. McCann Huawei Technologies (USA) peter.mcc...@huawei.com +1 908 541 3563 Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ 08807-2863 USA ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
[DMM] Comments on draft-liebsch-dmm-framework-analysis-00
Let me ask a question to make sure I understand the approach this document takes to analyzing the problem space. In the Introduction, you state: The initial version of this draft introduces a basic set of FEs and interfaces between these FEs to support IP address continuity in DMM, without being specific to the used mobility management protocol, which operates below the mobility anchor. And later, you introduce the FE_MA to represent this mobility anchor. I *think* you are trying to define DMM as something that runs above another mobility management protocol. Would it be legal to set the FE_MA equal to the access router, and the other mobility management protocol to NULL? That is, would it be allowed in your framework to use *only* the DMM protocol to get packets to an AR, to which the MN is currently attached? Section 3 states: Imported HoA/HNP of a mobile node will be treated as identifier and non-routable IP address (prefix), as it probably does not match the new mobility anchor's location in the topology. I disagree. The old address (prefix) will need to be routable at least inside the new anchor point. If this anchor point is directly connected to the MN (i.e., it is the AR) then the route will be to a local link address. If this new anchor point uses a tunnel to get the packets to the MN, then the old address will be routable to the tunnel interface. Elsewhere in Section 3: Forwarding can be for example accomplished by an IP tunnel to the egress function, address translation to a routable IP address or other means. I hope that other means can include installing an actual route for the destination IP on routers between the ingress and egress. I'd be happy to provide a diagram and text to show how draft-mccann-dmm-flatarch can fit into this functional framework. In the language of your draft, I think that the FE_MAs are integrated with the ARs, the FE_MCTX is the DNS server that stores the UE's current address, FE_E is co-located on the currently serving AR, and FE_I and FE_IEC are made up of a distributed network of routers running BGP (there is no single point of failure for FE_I). -- Peter J. McCann Huawei Technologies (USA) peter.mcc...@huawei.com +1 908 541 3563 Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ 08807-2863 USA ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] draft requirement REQ-4: compatibility
Hi, Jouni, jouni korhonen wrote: On May 7, 2012, at 9:04 PM, h chan wrote: REQ-4: compatibility The DMM solutions SHALL support existing network deployment with IPv6 (e.g. existing IPv6 address assignment), be compatible with other mobility protocols, and be interoperable with the network or the mobile hosts/routers that do not support the DMM enabling protocol so that the existing network deployments are unaffected. REQ-4M (Motivation for REQ-4) Motivation: The motivation of this requirement is to be able to work with network architectures of both hierarchical networks and flattened networks, so that the mobility management protocol possesses enough flexibility to support different networks, and so that the existing networks and hosts are not affected and do not break. Isn't the motivation just SHALL not break existing network deployments and end hosts ? Either the network or the host may not have any idea of the solutions developed in DMM. I think that's a reasonable simplification. We need a strategy for backwards compatibility. -Pete - JOuni OTHER related problem O-PS3: Complicated deployment with too many variants and extensions of MIP Deployment is complicated with many variants and extensions of MIP. When introducing new functions which may add to the complicity, existing solutions are more vulnerable to break. (The above has been drafted with contributions, inputs and discussions from various people. Additional contributions and comments are most welcome.) H Anthony Chan ___ 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 requirement REQ-5: Mobile IP based
Hi, Jouni, jouni korhonen wrote: On May 7, 2012, at 9:11 PM, h chan wrote: REQ-5: Mobile IP based The DMM solutions based on existing host- or network-based mobility protocols, such as Mobile IPv6 [RFC6275, ], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO [RFC3963], SHOULD be preferred, unless they fail to meet any of the other requirements. What about something on the lines with: A DMM solution that relies on a mobility protocol should be based on existing mobility protocol, such as .. Sounds good to me. -Pete - Jouni REQ-5M (Motivation for REQ-5) The motivation is to reuse the existing protocol first before considering new protocols. (The above has been drafted with contributions, inputs and discussions from various people. Additional contributions and comments are most welcome.) H Anthony Chan ___ 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] Review of draft-bernardos-dmm-distributed-anchoring-00
Hi, Carlos, Carlos Jesús Bernardos Cano wrote: Hi Pete, Sorry for the late reply. Please see inline below. On Wed, 2012-03-07 at 18:58 +, Peter McCann wrote: Hi, Carlos, Just a couple of response points below... Carlos Jesús Bernardos Cano wrote: Hi Pete, Thanks for the comments. Please see some comments inline below. On Tue, 2012-03-06 at 20:55 +, Peter McCann wrote: Hi, Carlos, Juan-Carlos, I have read draft-bernardos-dmm-distributed-anchoring-00, and I have a few comments. First, I want to bring up something that I think is common to several of the DMM proposals, and that is sub-optimal use of the backhaul resources. It seems that when you use an AR as an anchor point, and move to a new AR, the traffic for that session has to traverse the backhaul 3 times in each direction, like this: - | Rtr | / ^ -\ 1 / / 2 \ 3 v / v | AR || AR | Although it may seem at odds with the goal of distributing mobility to use the crossover router as the point of traffic redirection, it would make for much more optimal use of the backhaul resources. I believe it is possible to route the traffic more optimally with a standard off-the-shelf router at the crossover point (using mechanisms detailed in draft-mccann-dmm- flatarch-00). In our draft we don't make any assumption about the backhaul and access architecture. ARs might be also directly connected (in which case no Rtr would be traversed) if a network deployment allows that. In any case, the traffic redirection is supposed to happen for relatively short periods of time (otherwise the DMM advantages might vanish and it's just better to go for a centralized approach). I suppose I have a different view of how long one might keep an address that has been assigned by a first access router. There might be quite a bit of overhead involved with getting an address assigned, and you might want to delay getting a new address until, say, every 4th AR that you encounter. While I think it might be reasonable in some environments for neighboring ARs to have a direct IP hop between them, I think it is less likely that the 4th neighbor over will have a direct connection. And even direct neighbors I think are likely to be connected in a star topology via expensive and slow backhaul links to a router one layer up in the aggregation hierarchy. I guess this very much depends on the operator's architecture and the mobility pattern of the MN. Indeed it does, but I do not think we should require the MN to get a new IP address upon every attachment to an AR. Address allocation should be decoupled from mobility management. Second, I like the idea of moving the prefix assigned to the MN from one AR to another. However, why do we need to keep the AR's MAC address the same? IPv6 should handle the failover of a first-hop router from one instance to another with no problems. You see the same prefix advertised from a different MAC address; what's the big deal? You can just keep using the prefix as you did before, addressing packets to the new access router. This is basically inherited from PMIPv6 basic operation, in which the MN keeps seeing always the same router (i.e. same IPv6 link-local address and MAC address) while moving within the PMIPv6 domain. This is so to improve performance (there are no stale entries on the neigh cache) and also to avoid triggering any movement detection mechanism on the MN (changing the default router might be treated as such). We basically follow the same approach. Besides, by using a logical interface per anchoring router, it becomes easier to handle the prefix advertisement on the network side. At some layer of the stack the MN will know that it changed ARs. I don't see any particular reason why we have to hide the movement from the MAC layer. Besides, most wide-area cellular technologies will use The change is not hidden from the MAC layer, but from the IP layer. Ok, I guess the MAC layer sees the link change below it even though the MAC address of the AR is preserved. P2P links and won't have MAC addresses visible to the upper layers directly. Well, in this case the L2 change is by default hidden from the IP stack (if the new MAG shares the IP address from the old one). Right, I guess I am wondering why we can't just see the new router with a new IP address still advertising the old prefix. IPv6 stacks should be able to handle this. Third, I don't like the idea of having to ship so much state around the network through the HSS. In your draft you talk about (out-of-scope) mechanisms to get the prefix and the anchor gateway address to the new D-GW. There is also the complication of knowing which prior prefixes the MN wants to keep at its new attachment point. It seems to me
