Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s
Le 11/06/2015 18:53, Templin, Fred L a écrit : Responding to two in one: -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tony Hain Sent: Thursday, June 11, 2015 9:47 AM To: 'Alexandru Petrescu'; 'Jouni Korhonen'; dmm@ietf.org Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Alexandru Petrescu wrote: Le 11/06/2015 18:02, Jouni Korhonen a écrit : 6/4/2015, 7:08 AM, Alexandru Petrescu kirjoitti: Le 04/06/2015 05:42, Templin, Fred L a écrit : Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Wednesday, June 03, 2015 8:36 AM To: Templin, Fred L; Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 20:21, Templin, Fred L a écrit : Hi Alex, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru Petrescu Sent: Friday, May 29, 2015 10:59 AM To: Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 15:30, Satoru Matsushima a écrit : Ah OK. thanks. Slightly off-topic, I think that there is still chance for tethering with single /64 if it is allocated as a off-link prefix. Yes, there is still such a chance. But it can not tether more than one single subnet. Connected vehicles need several subnets. How would it be if the vehicle received a single prefix, but it could be shorter than /64 (e.g., /56, /48. etc.)? Would the vehicle subnetting be satisfied if it received a shorter prefix from which many /64s could be allocated? Certainly yes. Each vehicle needs such a shorter-than-64 prefix allocated to it. For example, an automobile connecting to LTE receives a /62 from the operator and makes four /64s out of it: one for its CAN-entertainment, one for its CAN-safety, one for its WiFi and one for its Bluetooth. This is a MUST. Allocating a single /64 to a vehicle can not accommodate all these unbridgeable subnets. OK, that is good. Giving a mobile router something shorter than /64 should be no problem, at least up to practical limitations of the prefix delegation authority's available prefix space. DHCPv6 PD provides all that is needed to give out right-sized prefixes. I agree DHCP-PD provides the necessary tool. But unfortunately the cellular operators have not deployed DHCPv6-PD (although yes there is some DHCP-non-PD in some IPv6/4G deployments). The common thinking at operators and advisers is still that a /64 should be given to an User Equipment. This must change: the 3GPP specs and operator deployments must give /62 to UEs, and not /64. I think we are not in the position to force operators or 3GPP to do anything, unfortunately. The best we can do is to make sure the protocols we work here in IETF are not prohibiting better deployments (see e.g. RFC6603 effort). 3GPP specs are not the show stoppers here. I know this is frustrating. For example some operators I know offer IPv6 PD on their fixed side of business but have no plans for similar on the cellular side.. reasons are many. I assume that identofying a strong enough use case would be the key. I would like to discuss these use cases. Use cases of grouping devices under a unique cellular connection are very numerous: IPv6 automobiles, IPv6 tethering smartphones, IPv6 Things on Personal Area Networks. Yes, yes and yes. Also IPv6 airplanes. What is the use case when an airplane connects to a cellular operator? They are supposed to be on sattelite often, I guess. Alex All these devices need the cellular operator to deliver shorter-than-64 prefixes to a SIM connection. For lack of a better description, the cellular side of businesses suffer from bell head: thinking, where the UE is an application endpoint. Nothing more occurs to them, because that is the product they have always supported. A routing function implies higher aggregate data rates than they have built the system to handle. I have been in front of many of them holding up UE and saying, this is a ROUTER, get over it, and got nothing but blank stares back. Indeed. But, this is the ongoing dialogue that we need to continue no matter how many blank stares we get. Thanks - Fred fred.l.temp...@boeing.com The first use case on the list should be a wireline alternative/backup link for consumer CPE routers, and home control or security systems. That is simpler to support because the UE doesn't move around, so they can scale the infrastructure to align with demand without too much concern about that shifting quickly. Once the fear of downstream subnets is removed, working on the truly mobile use cases will be an easier mental hurdle to overcome. Tony ... ___ 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] vepc draft Rev. 04 - /62s to UE, not /64s
I was asked in private about this SIM connection, I clarify below. Le 11/06/2015 18:19, Alexandru Petrescu a écrit : Le 11/06/2015 18:02, Jouni Korhonen a écrit : 6/4/2015, 7:08 AM, Alexandru Petrescu kirjoitti: Le 04/06/2015 05:42, Templin, Fred L a écrit : Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Wednesday, June 03, 2015 8:36 AM To: Templin, Fred L; Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 20:21, Templin, Fred L a écrit : Hi Alex, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru Petrescu Sent: Friday, May 29, 2015 10:59 AM To: Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 15:30, Satoru Matsushima a écrit : Ah OK. thanks. Slightly off-topic, I think that there is still chance for tethering with single /64 if it is allocated as a off-link prefix. Yes, there is still such a chance. But it can not tether more than one single subnet. Connected vehicles need several subnets. How would it be if the vehicle received a single prefix, but it could be shorter than /64 (e.g., /56, /48. etc.)? Would the vehicle subnetting be satisfied if it received a shorter prefix from which many /64s could be allocated? Certainly yes. Each vehicle needs such a shorter-than-64 prefix allocated to it. For example, an automobile connecting to LTE receives a /62 from the operator and makes four /64s out of it: one for its CAN-entertainment, one for its CAN-safety, one for its WiFi and one for its Bluetooth. This is a MUST. Allocating a single /64 to a vehicle can not accommodate all these unbridgeable subnets. OK, that is good. Giving a mobile router something shorter than /64 should be no problem, at least up to practical limitations of the prefix delegation authority's available prefix space. DHCPv6 PD provides all that is needed to give out right-sized prefixes. I agree DHCP-PD provides the necessary tool. But unfortunately the cellular operators have not deployed DHCPv6-PD (although yes there is some DHCP-non-PD in some IPv6/4G deployments). The common thinking at operators and advisers is still that a /64 should be given to an User Equipment. This must change: the 3GPP specs and operator deployments must give /62 to UEs, and not /64. I think we are not in the position to force operators or 3GPP to do anything, unfortunately. The best we can do is to make sure the protocols we work here in IETF are not prohibiting better deployments (see e.g. RFC6603 effort). 3GPP specs are not the show stoppers here. I know this is frustrating. For example some operators I know offer IPv6 PD on their fixed side of business but have no plans for similar on the cellular side.. reasons are many. I assume that identofying a strong enough use case would be the key. I would like to discuss these use cases. Use cases of grouping devices under a unique cellular connection are very numerous: IPv6 automobiles, IPv6 tethering smartphones, IPv6 Things on Personal Area Networks. All these devices need the cellular operator to deliver shorter-than-64 prefixes to a SIM connection. I meant to say a device holding a single SIM card should be able to get a shorter-than-64 prefix from the cellular operator. This is to distinguish from computers featuring multiple SIM cards, or automobiles featuring multiple SIMs (car's SIM, passengers' SIMs). SIM stands for Subscriber Identification Module. Alex Alex - Jouni Alex Thanks - Fred fred.l.temp...@boeing.com Alex Thanks - Fred fred.l.temp...@boeing.com Alex But yes, I agree with you. cheers, --satoru On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu alexandru.petre...@gmail.com mailto:alexandru.petre...@gmail.com wrote: Hi, In addition to what Behcet says. I read the example below. I think it is just an example, but just to make sure. Please - do not allocate /64s to end users in a cellular network. Allocate at least /62s to end users. This is to allow the smartphone to perform tethering (small network of wifi devices connecting through the smartphone to the Internet). The assumption of /64 to end user is not good at all. (and yes, I agree that these /62s may be aggregated into a larger prefix and advertised upstream as a single prefix instead of multiple host-based routes). Yours, Alex Petrescu Le 26/05/2015 22:34, Behcet Sarikaya a écrit : Hi Satoru, Thanks for your reply. Let me continue the discussion with your text in Section 3.2 where you mention vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) that defines FPCP Agent function and Client function. I don't understand how you could justify defining a new forwarding
Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s
Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Friday, June 12, 2015 8:53 AM To: Templin, Fred L; Tony Hain; 'Jouni Korhonen'; dmm@ietf.org Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Hi Fred, Le 12/06/2015 17:24, Templin, Fred L a écrit : Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Friday, June 12, 2015 6:03 AM To: Templin, Fred L; Tony Hain; 'Jouni Korhonen'; dmm@ietf.org Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 11/06/2015 18:53, Templin, Fred L a écrit : Responding to two in one: -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tony Hain Sent: Thursday, June 11, 2015 9:47 AM To: 'Alexandru Petrescu'; 'Jouni Korhonen'; dmm@ietf.org Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Alexandru Petrescu wrote: Le 11/06/2015 18:02, Jouni Korhonen a écrit : 6/4/2015, 7:08 AM, Alexandru Petrescu kirjoitti: Le 04/06/2015 05:42, Templin, Fred L a écrit : Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Wednesday, June 03, 2015 8:36 AM To: Templin, Fred L; Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 20:21, Templin, Fred L a écrit : Hi Alex, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru Petrescu Sent: Friday, May 29, 2015 10:59 AM To: Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 15:30, Satoru Matsushima a écrit : Ah OK. thanks. Slightly off-topic, I think that there is still chance for tethering with single /64 if it is allocated as a off-link prefix. Yes, there is still such a chance. But it can not tether more than one single subnet. Connected vehicles need several subnets. How would it be if the vehicle received a single prefix, but it could be shorter than /64 (e.g., /56, /48. etc.)? Would the vehicle subnetting be satisfied if it received a shorter prefix from which many /64s could be allocated? Certainly yes. Each vehicle needs such a shorter-than-64 prefix allocated to it. For example, an automobile connecting to LTE receives a /62 from the operator and makes four /64s out of it: one for its CAN-entertainment, one for its CAN-safety, one for its WiFi and one for its Bluetooth. This is a MUST. Allocating a single /64 to a vehicle can not accommodate all these unbridgeable subnets. OK, that is good. Giving a mobile router something shorter than /64 should be no problem, at least up to practical limitations of the prefix delegation authority's available prefix space. DHCPv6 PD provides all that is needed to give out right-sized prefixes. I agree DHCP-PD provides the necessary tool. But unfortunately the cellular operators have not deployed DHCPv6-PD (although yes there is some DHCP-non-PD in some IPv6/4G deployments). The common thinking at operators and advisers is still that a /64 should be given to an User Equipment. This must change: the 3GPP specs and operator deployments must give /62 to UEs, and not /64. I think we are not in the position to force operators or 3GPP to do anything, unfortunately. The best we can do is to make sure the protocols we work here in IETF are not prohibiting better deployments (see e.g. RFC6603 effort). 3GPP specs are not the show stoppers here. I know this is frustrating. For example some operators I know offer IPv6 PD on their fixed side of business but have no plans for similar on the cellular side.. reasons are many. I assume that identofying a strong enough use case would be the key. I would like to discuss these use cases. Use cases of grouping devices under a unique cellular connection are very numerous: IPv6 automobiles, IPv6 tethering smartphones, IPv6 Things on Personal Area Networks. Yes, yes and yes. Also IPv6 airplanes. What is the use case when an airplane connects to a cellular operator? They are supposed to be on sattelite often, I guess. Airplanes have lots of links - some satellite yes, but there are also cellular link types such as this: http://aircell.com/ That is a cellular link on-board of a plane, I think. Maybe it requires a shorter-than-64 prefix from the satellite operator... Last I checked, Gogo/Aircell is based on a cellular ground network and gives passengers on board an Internet-capable WiFi service. Aircell also offers satcom services including Inmarsat and Iridium, but I was referring to the ground-based cellular network. But is there a use-case with plane that connects to a cellular network while taxiing ? I.e. slow speed, spend 1hour on the tarmac, connect the plane to Verizon, give
Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s
Hi Fred, Le 12/06/2015 17:24, Templin, Fred L a écrit : Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Friday, June 12, 2015 6:03 AM To: Templin, Fred L; Tony Hain; 'Jouni Korhonen'; dmm@ietf.org Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 11/06/2015 18:53, Templin, Fred L a écrit : Responding to two in one: -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tony Hain Sent: Thursday, June 11, 2015 9:47 AM To: 'Alexandru Petrescu'; 'Jouni Korhonen'; dmm@ietf.org Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Alexandru Petrescu wrote: Le 11/06/2015 18:02, Jouni Korhonen a écrit : 6/4/2015, 7:08 AM, Alexandru Petrescu kirjoitti: Le 04/06/2015 05:42, Templin, Fred L a écrit : Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Wednesday, June 03, 2015 8:36 AM To: Templin, Fred L; Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 20:21, Templin, Fred L a écrit : Hi Alex, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru Petrescu Sent: Friday, May 29, 2015 10:59 AM To: Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 15:30, Satoru Matsushima a écrit : Ah OK. thanks. Slightly off-topic, I think that there is still chance for tethering with single /64 if it is allocated as a off-link prefix. Yes, there is still such a chance. But it can not tether more than one single subnet. Connected vehicles need several subnets. How would it be if the vehicle received a single prefix, but it could be shorter than /64 (e.g., /56, /48. etc.)? Would the vehicle subnetting be satisfied if it received a shorter prefix from which many /64s could be allocated? Certainly yes. Each vehicle needs such a shorter-than-64 prefix allocated to it. For example, an automobile connecting to LTE receives a /62 from the operator and makes four /64s out of it: one for its CAN-entertainment, one for its CAN-safety, one for its WiFi and one for its Bluetooth. This is a MUST. Allocating a single /64 to a vehicle can not accommodate all these unbridgeable subnets. OK, that is good. Giving a mobile router something shorter than /64 should be no problem, at least up to practical limitations of the prefix delegation authority's available prefix space. DHCPv6 PD provides all that is needed to give out right-sized prefixes. I agree DHCP-PD provides the necessary tool. But unfortunately the cellular operators have not deployed DHCPv6-PD (although yes there is some DHCP-non-PD in some IPv6/4G deployments). The common thinking at operators and advisers is still that a /64 should be given to an User Equipment. This must change: the 3GPP specs and operator deployments must give /62 to UEs, and not /64. I think we are not in the position to force operators or 3GPP to do anything, unfortunately. The best we can do is to make sure the protocols we work here in IETF are not prohibiting better deployments (see e.g. RFC6603 effort). 3GPP specs are not the show stoppers here. I know this is frustrating. For example some operators I know offer IPv6 PD on their fixed side of business but have no plans for similar on the cellular side.. reasons are many. I assume that identofying a strong enough use case would be the key. I would like to discuss these use cases. Use cases of grouping devices under a unique cellular connection are very numerous: IPv6 automobiles, IPv6 tethering smartphones, IPv6 Things on Personal Area Networks. Yes, yes and yes. Also IPv6 airplanes. What is the use case when an airplane connects to a cellular operator? They are supposed to be on sattelite often, I guess. Airplanes have lots of links - some satellite yes, but there are also cellular link types such as this: http://aircell.com/ That is a cellular link on-board of a plane, I think. Maybe it requires a shorter-than-64 prefix from the satellite operator... But is there a use-case with plane that connects to a cellular network while taxiing ? I.e. slow speed, spend 1hour on the tarmac, connect the plane to Verizon, give passengers free WiFi to smartphones so use Internet to announce safe landing. This latter certainly requires a shorter-than-64 prefix from the cellular operator. Alex Thanks - Fred fred.l.temp...@boeing.com Alex All these devices need the cellular operator to deliver shorter-than-64 prefixes to a SIM connection. For lack of a better description, the cellular side of businesses suffer from bell head: thinking, where the UE is an application endpoint. Nothing more occurs to them, because that is the product they have always supported. A routing function implies higher aggregate data rates than they have built the system to handle. I have been in front of many of them holding up UE
Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s
6/4/2015, 7:08 AM, Alexandru Petrescu kirjoitti: Le 04/06/2015 05:42, Templin, Fred L a écrit : Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Wednesday, June 03, 2015 8:36 AM To: Templin, Fred L; Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 20:21, Templin, Fred L a écrit : Hi Alex, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru Petrescu Sent: Friday, May 29, 2015 10:59 AM To: Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 15:30, Satoru Matsushima a écrit : Ah OK. thanks. Slightly off-topic, I think that there is still chance for tethering with single /64 if it is allocated as a off-link prefix. Yes, there is still such a chance. But it can not tether more than one single subnet. Connected vehicles need several subnets. How would it be if the vehicle received a single prefix, but it could be shorter than /64 (e.g., /56, /48. etc.)? Would the vehicle subnetting be satisfied if it received a shorter prefix from which many /64s could be allocated? Certainly yes. Each vehicle needs such a shorter-than-64 prefix allocated to it. For example, an automobile connecting to LTE receives a /62 from the operator and makes four /64s out of it: one for its CAN-entertainment, one for its CAN-safety, one for its WiFi and one for its Bluetooth. This is a MUST. Allocating a single /64 to a vehicle can not accommodate all these unbridgeable subnets. OK, that is good. Giving a mobile router something shorter than /64 should be no problem, at least up to practical limitations of the prefix delegation authority's available prefix space. DHCPv6 PD provides all that is needed to give out right-sized prefixes. I agree DHCP-PD provides the necessary tool. But unfortunately the cellular operators have not deployed DHCPv6-PD (although yes there is some DHCP-non-PD in some IPv6/4G deployments). The common thinking at operators and advisers is still that a /64 should be given to an User Equipment. This must change: the 3GPP specs and operator deployments must give /62 to UEs, and not /64. I think we are not in the position to force operators or 3GPP to do anything, unfortunately. The best we can do is to make sure the protocols we work here in IETF are not prohibiting better deployments (see e.g. RFC6603 effort). 3GPP specs are not the show stoppers here. I know this is frustrating. For example some operators I know offer IPv6 PD on their fixed side of business but have no plans for similar on the cellular side.. reasons are many. I assume that identofying a strong enough use case would be the key. - Jouni Alex Thanks - Fred fred.l.temp...@boeing.com Alex Thanks - Fred fred.l.temp...@boeing.com Alex But yes, I agree with you. cheers, --satoru On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu alexandru.petre...@gmail.com mailto:alexandru.petre...@gmail.com wrote: Hi, In addition to what Behcet says. I read the example below. I think it is just an example, but just to make sure. Please - do not allocate /64s to end users in a cellular network. Allocate at least /62s to end users. This is to allow the smartphone to perform tethering (small network of wifi devices connecting through the smartphone to the Internet). The assumption of /64 to end user is not good at all. (and yes, I agree that these /62s may be aggregated into a larger prefix and advertised upstream as a single prefix instead of multiple host-based routes). Yours, Alex Petrescu Le 26/05/2015 22:34, Behcet Sarikaya a écrit : Hi Satoru, Thanks for your reply. Let me continue the discussion with your text in Section 3.2 where you mention vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) that defines FPCP Agent function and Client function. I don't understand how you could justify defining a new forwarding policy configuration protocol to do this Agent/Client functionality? Why not use similar Agent/Client models that are being defined rather than defining a new protocol? I think this point requires much stronger justification which I could not see in Section 3.2. Are you that we have to to reinvent the wheel, rather than reusing something that is already available? How are we going to reinvent that wheel also remains to be seen, I think. Regards, Behcet On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima satoru.matsush...@gmail.com mailto:satoru.matsush...@gmail.com wrote: Hi Bechet-san, Thank you for your question
Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s
Alexandru Petrescu wrote: Le 11/06/2015 18:02, Jouni Korhonen a écrit : 6/4/2015, 7:08 AM, Alexandru Petrescu kirjoitti: Le 04/06/2015 05:42, Templin, Fred L a écrit : Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Wednesday, June 03, 2015 8:36 AM To: Templin, Fred L; Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 20:21, Templin, Fred L a écrit : Hi Alex, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru Petrescu Sent: Friday, May 29, 2015 10:59 AM To: Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 15:30, Satoru Matsushima a écrit : Ah OK. thanks. Slightly off-topic, I think that there is still chance for tethering with single /64 if it is allocated as a off-link prefix. Yes, there is still such a chance. But it can not tether more than one single subnet. Connected vehicles need several subnets. How would it be if the vehicle received a single prefix, but it could be shorter than /64 (e.g., /56, /48. etc.)? Would the vehicle subnetting be satisfied if it received a shorter prefix from which many /64s could be allocated? Certainly yes. Each vehicle needs such a shorter-than-64 prefix allocated to it. For example, an automobile connecting to LTE receives a /62 from the operator and makes four /64s out of it: one for its CAN-entertainment, one for its CAN-safety, one for its WiFi and one for its Bluetooth. This is a MUST. Allocating a single /64 to a vehicle can not accommodate all these unbridgeable subnets. OK, that is good. Giving a mobile router something shorter than /64 should be no problem, at least up to practical limitations of the prefix delegation authority's available prefix space. DHCPv6 PD provides all that is needed to give out right-sized prefixes. I agree DHCP-PD provides the necessary tool. But unfortunately the cellular operators have not deployed DHCPv6-PD (although yes there is some DHCP-non-PD in some IPv6/4G deployments). The common thinking at operators and advisers is still that a /64 should be given to an User Equipment. This must change: the 3GPP specs and operator deployments must give /62 to UEs, and not /64. I think we are not in the position to force operators or 3GPP to do anything, unfortunately. The best we can do is to make sure the protocols we work here in IETF are not prohibiting better deployments (see e.g. RFC6603 effort). 3GPP specs are not the show stoppers here. I know this is frustrating. For example some operators I know offer IPv6 PD on their fixed side of business but have no plans for similar on the cellular side.. reasons are many. I assume that identofying a strong enough use case would be the key. I would like to discuss these use cases. Use cases of grouping devices under a unique cellular connection are very numerous: IPv6 automobiles, IPv6 tethering smartphones, IPv6 Things on Personal Area Networks. All these devices need the cellular operator to deliver shorter-than-64 prefixes to a SIM connection. For lack of a better description, the cellular side of businesses suffer from bell head: thinking, where the UE is an application endpoint. Nothing more occurs to them, because that is the product they have always supported. A routing function implies higher aggregate data rates than they have built the system to handle. I have been in front of many of them holding up UE and saying, this is a ROUTER, get over it, and got nothing but blank stares back. The first use case on the list should be a wireline alternative/backup link for consumer CPE routers, and home control or security systems. That is simpler to support because the UE doesn't move around, so they can scale the infrastructure to align with demand without too much concern about that shifting quickly. Once the fear of downstream subnets is removed, working on the truly mobile use cases will be an easier mental hurdle to overcome. Tony ... ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s
Responding to two in one: -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tony Hain Sent: Thursday, June 11, 2015 9:47 AM To: 'Alexandru Petrescu'; 'Jouni Korhonen'; dmm@ietf.org Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Alexandru Petrescu wrote: Le 11/06/2015 18:02, Jouni Korhonen a écrit : 6/4/2015, 7:08 AM, Alexandru Petrescu kirjoitti: Le 04/06/2015 05:42, Templin, Fred L a écrit : Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Wednesday, June 03, 2015 8:36 AM To: Templin, Fred L; Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 20:21, Templin, Fred L a écrit : Hi Alex, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru Petrescu Sent: Friday, May 29, 2015 10:59 AM To: Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 15:30, Satoru Matsushima a écrit : Ah OK. thanks. Slightly off-topic, I think that there is still chance for tethering with single /64 if it is allocated as a off-link prefix. Yes, there is still such a chance. But it can not tether more than one single subnet. Connected vehicles need several subnets. How would it be if the vehicle received a single prefix, but it could be shorter than /64 (e.g., /56, /48. etc.)? Would the vehicle subnetting be satisfied if it received a shorter prefix from which many /64s could be allocated? Certainly yes. Each vehicle needs such a shorter-than-64 prefix allocated to it. For example, an automobile connecting to LTE receives a /62 from the operator and makes four /64s out of it: one for its CAN-entertainment, one for its CAN-safety, one for its WiFi and one for its Bluetooth. This is a MUST. Allocating a single /64 to a vehicle can not accommodate all these unbridgeable subnets. OK, that is good. Giving a mobile router something shorter than /64 should be no problem, at least up to practical limitations of the prefix delegation authority's available prefix space. DHCPv6 PD provides all that is needed to give out right-sized prefixes. I agree DHCP-PD provides the necessary tool. But unfortunately the cellular operators have not deployed DHCPv6-PD (although yes there is some DHCP-non-PD in some IPv6/4G deployments). The common thinking at operators and advisers is still that a /64 should be given to an User Equipment. This must change: the 3GPP specs and operator deployments must give /62 to UEs, and not /64. I think we are not in the position to force operators or 3GPP to do anything, unfortunately. The best we can do is to make sure the protocols we work here in IETF are not prohibiting better deployments (see e.g. RFC6603 effort). 3GPP specs are not the show stoppers here. I know this is frustrating. For example some operators I know offer IPv6 PD on their fixed side of business but have no plans for similar on the cellular side.. reasons are many. I assume that identofying a strong enough use case would be the key. I would like to discuss these use cases. Use cases of grouping devices under a unique cellular connection are very numerous: IPv6 automobiles, IPv6 tethering smartphones, IPv6 Things on Personal Area Networks. Yes, yes and yes. Also IPv6 airplanes. All these devices need the cellular operator to deliver shorter-than-64 prefixes to a SIM connection. For lack of a better description, the cellular side of businesses suffer from bell head: thinking, where the UE is an application endpoint. Nothing more occurs to them, because that is the product they have always supported. A routing function implies higher aggregate data rates than they have built the system to handle. I have been in front of many of them holding up UE and saying, this is a ROUTER, get over it, and got nothing but blank stares back. Indeed. But, this is the ongoing dialogue that we need to continue no matter how many blank stares we get. Thanks - Fred fred.l.temp...@boeing.com The first use case on the list should be a wireline alternative/backup link for consumer CPE routers, and home control or security systems. That is simpler to support because the UE doesn't move around, so they can scale the infrastructure to align with demand without too much concern about that shifting quickly. Once the fear of downstream subnets is removed, working on the truly mobile use cases will be an easier mental hurdle to overcome. Tony ... ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https
Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s
For lack of a better description, the cellular side of businesses suffer from bell head: thinking, where the UE is an application endpoint. Nothing more occurs to them, because that is the product they have always supported. A routing function implies higher aggregate data rates than they have built the system to handle. I have been in front of many of them holding up UE and saying, this is a ROUTER, get over it, and got nothing but blank stares back. The first use case on the list should be a wireline alternative/backup link for consumer CPE routers, and home control or security systems. That is simpler to support because the UE doesn't move around, so they can scale the infrastructure to align with demand without too much concern about that shifting quickly. Once the fear of downstream subnets is removed, working on the truly mobile use cases will be an easier mental hurdle to overcome. Amen. I know that such backup solutions with routed IPv4 networks were done for enterprise access (not a standard but easily doable). Tony ... ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s
Fred, Le 08/06/2015 19:08, Templin, Fred L a écrit : [...] The common thinking at operators and advisers is still that a /64 should be given to an User Equipment. This must change: the 3GPP specs and operator deployments must give /62 to UEs, and not /64. Why not a /N instead of just a /62 or /64? N could be anything (62, 60, 56, 48, etc.) as long as it is a proper subset of the prefix space the operator has available for delegation. I agree that in general it's good to be more generic with the prefix length. But in this particular case we are too generic if we just say '/N'. The readers will assume '/64' to be a good example of N, and that is not so. We can't say 'non-/64' either, because it means too much. We could say N between /48 and /63 in one bit steps. But to be clear that /64 is forbidden. (I can imagine the pressure that may put on the operatos, but we may also think there are enough of these addresses and that the pressure is simply a misunderstanding.) What I was thinking was that users could pay for different classes of service. Basic service could be a /64 (or /63 or /62). Premium service could be a /60. Super-premium could be a /56, etc. Well it looks like a good idea. It is a bit new compared to IPv4 in cellular networks (there is no concept of premium service delivery of several IPv4 addresses per single device, and there is no StdsTrack PD for DHCPv4). Do you think cellular operators may create such new payment schemes for classes of service in IPv6? Or rather migrate the existing IPv4 payment schemes from IPv4 - a one to one mapping between concepts, modulo the address length being bigger? Point being that the mechanism should support any prefix delegation size that the user has contracted with the service provider for; not just a fixed one-size-fits-all size for all users. I agree - the mechanism is there. Why the cellular operators dont respond to DHCPv6 Prefix Delegation requests from the User Equipments? Alex Thanks - Fred fred.l.temp...@boeing.com Alex Thanks - Fred fred.l.temp...@boeing.com Alex Thanks - Fred fred.l.temp...@boeing.com Alex Thanks - Fred fred.l.temp...@boeing.com Alex But yes, I agree with you. cheers, --satoru On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu alexandru.petre...@gmail.com mailto:alexandru.petre...@gmail.com wrote: Hi, In addition to what Behcet says. I read the example below. I think it is just an example, but just to make sure. Please - do not allocate /64s to end users in a cellular network. Allocate at least /62s to end users. This is to allow the smartphone to perform tethering (small network of wifi devices connecting through the smartphone to the Internet). The assumption of /64 to end user is not good at all. (and yes, I agree that these /62s may be aggregated into a larger prefix and advertised upstream as a single prefix instead of multiple host-based routes). Yours, Alex Petrescu Le 26/05/2015 22:34, Behcet Sarikaya a écrit : Hi Satoru, Thanks for your reply. Let me continue the discussion with your text in Section 3.2 where you mention vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) that defines FPCP Agent function and Client function. I don't understand how you could justify defining a new forwarding policy configuration protocol to do this Agent/Client functionality? Why not use similar Agent/Client models that are being defined rather than defining a new protocol? I think this point requires much stronger justification which I could not see in Section 3.2. Are you that we have to to reinvent the wheel, rather than reusing something that is already available? How are we going to reinvent that wheel also remains to be seen, I think. Regards, Behcet On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima satoru.matsush...@gmail.com mailto:satoru.matsush...@gmail.com wrote: Hi Bechet-san, Thank you for your question. In step (15), I meant that EPC-E advertises prefix including UE assigned prefixes. For example, in the case of /64 prefixes assigned to UEs from a /56 space, that /56 is advertised by EPC-E to upstream routers. So the advertised route isn't host routes. Depends on configuration policy, but one case is that the source of that advertised /56 route might be statically configured in EPC-E. Regards, --satoru On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya sarikaya2...@gmail.com mailto:sarikaya2...@gmail.com wrote: Hi Matsushima-san, I have a question on your draft: In Sec. 3.2, page 11, you say In step (15), the EPC-E advertises routes to upstream routers ... Are these routes static/host routes? Regards, Behcet ___ dmm mailing list dmm@ietf.org mailto:dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org mailto:dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s
Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Tuesday, June 09, 2015 7:58 AM To: Templin, Fred L; Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Fred, Le 08/06/2015 19:08, Templin, Fred L a écrit : [...] The common thinking at operators and advisers is still that a /64 should be given to an User Equipment. This must change: the 3GPP specs and operator deployments must give /62 to UEs, and not /64. Why not a /N instead of just a /62 or /64? N could be anything (62, 60, 56, 48, etc.) as long as it is a proper subset of the prefix space the operator has available for delegation. I agree that in general it's good to be more generic with the prefix length. But in this particular case we are too generic if we just say '/N'. The readers will assume '/64' to be a good example of N, and that is not so. We can't say 'non-/64' either, because it means too much. We could say N between /48 and /63 in one bit steps. But to be clear that /64 is forbidden. (I can imagine the pressure that may put on the operatos, but we may also think there are enough of these addresses and that the pressure is simply a misunderstanding.) What I was thinking was that users could pay for different classes of service. Basic service could be a /64 (or /63 or /62). Premium service could be a /60. Super-premium could be a /56, etc. Well it looks like a good idea. It is a bit new compared to IPv4 in cellular networks (there is no concept of premium service delivery of several IPv4 addresses per single device, and there is no StdsTrack PD for DHCPv4). Do you think cellular operators may create such new payment schemes for classes of service in IPv6? Or rather migrate the existing IPv4 payment schemes from IPv4 - a one to one mapping between concepts, modulo the address length being bigger? I don't know much about the cellular operator business. I am confident AERO would be a good fit for that environment, but I have been more focused on enterprise networks, aviation networks, unmanned air system networks, etc. Taking aviation for example, I believe that airplanes will have many onboard addressable devices and networks. So, a /56 (or possibly even more) might be a natural prefix delegation unit for each airplane. Point being that the mechanism should support any prefix delegation size that the user has contracted with the service provider for; not just a fixed one-size-fits-all size for all users. I agree - the mechanism is there. OK. Why the cellular operators dont respond to DHCPv6 Prefix Delegation requests from the User Equipments? I don't know why - it is really easy to set up, and a natural way to get an arbitrary-length prefix delegation to the UE. Thanks - Fred fred.l.temp...@boeing.com Alex Thanks - Fred fred.l.temp...@boeing.com Alex Thanks - Fred fred.l.temp...@boeing.com Alex Thanks - Fred fred.l.temp...@boeing.com Alex Thanks - Fred fred.l.temp...@boeing.com Alex But yes, I agree with you. cheers, --satoru On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu alexandru.petre...@gmail.com mailto:alexandru.petre...@gmail.com wrote: Hi, In addition to what Behcet says. I read the example below. I think it is just an example, but just to make sure. Please - do not allocate /64s to end users in a cellular network. Allocate at least /62s to end users. This is to allow the smartphone to perform tethering (small network of wifi devices connecting through the smartphone to the Internet). The assumption of /64 to end user is not good at all. (and yes, I agree that these /62s may be aggregated into a larger prefix and advertised upstream as a single prefix instead of multiple host-based routes). Yours, Alex Petrescu Le 26/05/2015 22:34, Behcet Sarikaya a écrit : Hi Satoru, Thanks for your reply. Let me continue the discussion with your text in Section 3.2 where you mention vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) that defines FPCP Agent function and Client function. I don't understand how you could justify defining a new forwarding policy configuration protocol to do this Agent/Client functionality? Why not use similar Agent/Client models that are being defined rather than defining a new protocol? I think this point requires much stronger justification which I could not see in Section 3.2. Are you that we have to to reinvent the wheel, rather than reusing something that is already available? How are we going to reinvent that wheel also remains to be seen, I think. Regards, Behcet On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima satoru.matsush...@gmail.com mailto:satoru.matsush...@gmail.com wrote: Hi Bechet-san, Thank
Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s
Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Monday, June 08, 2015 9:43 AM To: Templin, Fred L; Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Hi Fred, Le 04/06/2015 17:10, Templin, Fred L a écrit : Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Thursday, June 04, 2015 7:09 AM To: Templin, Fred L; Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 04/06/2015 05:42, Templin, Fred L a écrit : Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Wednesday, June 03, 2015 8:36 AM To: Templin, Fred L; Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 20:21, Templin, Fred L a écrit : Hi Alex, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru Petrescu Sent: Friday, May 29, 2015 10:59 AM To: Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 15:30, Satoru Matsushima a écrit : Ah OK. thanks. Slightly off-topic, I think that there is still chance for tethering with single /64 if it is allocated as a off-link prefix. Yes, there is still such a chance. But it can not tether more than one single subnet. Connected vehicles need several subnets. How would it be if the vehicle received a single prefix, but it could be shorter than /64 (e.g., /56, /48. etc.)? Would the vehicle subnetting be satisfied if it received a shorter prefix from which many /64s could be allocated? Certainly yes. Each vehicle needs such a shorter-than-64 prefix allocated to it. For example, an automobile connecting to LTE receives a /62 from the operator and makes four /64s out of it: one for its CAN-entertainment, one for its CAN-safety, one for its WiFi and one for its Bluetooth. This is a MUST. Allocating a single /64 to a vehicle can not accommodate all these unbridgeable subnets. OK, that is good. Giving a mobile router something shorter than /64 should be no problem, at least up to practical limitations of the prefix delegation authority's available prefix space. DHCPv6 PD provides all that is needed to give out right-sized prefixes. I agree DHCP-PD provides the necessary tool. But unfortunately the cellular operators have not deployed DHCPv6-PD (although yes there is some DHCP-non-PD in some IPv6/4G deployments). That is a pity, because DHCPv6 PD (along with IPv6 ND and BGP) are all that are necessary for distributed mobility management. I agree. A dynamic routing protocol like BGP was demonstrated to feature distributed mobility management on a wide geographical scale. The common thinking at operators and advisers is still that a /64 should be given to an User Equipment. This must change: the 3GPP specs and operator deployments must give /62 to UEs, and not /64. Why not a /N instead of just a /62 or /64? N could be anything (62, 60, 56, 48, etc.) as long as it is a proper subset of the prefix space the operator has available for delegation. I agree that in general it's good to be more generic with the prefix length. But in this particular case we are too generic if we just say '/N'. The readers will assume '/64' to be a good example of N, and that is not so. We can't say 'non-/64' either, because it means too much. We could say N between /48 and /63 in one bit steps. But to be clear that /64 is forbidden. (I can imagine the pressure that may put on the operatos, but we may also think there are enough of these addresses and that the pressure is simply a misunderstanding.) What I was thinking was that users could pay for different classes of service. Basic service could be a /64 (or /63 or /62). Premium service could be a /60. Super-premium could be a /56, etc. Point being that the mechanism should support any prefix delegation size that the user has contracted with the service provider for; not just a fixed one-size-fits-all size for all users. Thanks - Fred fred.l.temp...@boeing.com Alex Thanks - Fred fred.l.temp...@boeing.com Alex Thanks - Fred fred.l.temp...@boeing.com Alex Thanks - Fred fred.l.temp...@boeing.com Alex But yes, I agree with you. cheers, --satoru On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu alexandru.petre...@gmail.com mailto:alexandru.petre...@gmail.com wrote: Hi, In addition to what Behcet says. I read the example below. I think it is just an example, but just to make sure. Please - do not allocate /64s to end users in a cellular network. Allocate at least /62s to end users. This is to allow the smartphone to perform tethering (small network of wifi
Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s
Le 04/06/2015 05:42, Templin, Fred L a écrit : Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Wednesday, June 03, 2015 8:36 AM To: Templin, Fred L; Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 20:21, Templin, Fred L a écrit : Hi Alex, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru Petrescu Sent: Friday, May 29, 2015 10:59 AM To: Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 15:30, Satoru Matsushima a écrit : Ah OK. thanks. Slightly off-topic, I think that there is still chance for tethering with single /64 if it is allocated as a off-link prefix. Yes, there is still such a chance. But it can not tether more than one single subnet. Connected vehicles need several subnets. How would it be if the vehicle received a single prefix, but it could be shorter than /64 (e.g., /56, /48. etc.)? Would the vehicle subnetting be satisfied if it received a shorter prefix from which many /64s could be allocated? Certainly yes. Each vehicle needs such a shorter-than-64 prefix allocated to it. For example, an automobile connecting to LTE receives a /62 from the operator and makes four /64s out of it: one for its CAN-entertainment, one for its CAN-safety, one for its WiFi and one for its Bluetooth. This is a MUST. Allocating a single /64 to a vehicle can not accommodate all these unbridgeable subnets. OK, that is good. Giving a mobile router something shorter than /64 should be no problem, at least up to practical limitations of the prefix delegation authority's available prefix space. DHCPv6 PD provides all that is needed to give out right-sized prefixes. I agree DHCP-PD provides the necessary tool. But unfortunately the cellular operators have not deployed DHCPv6-PD (although yes there is some DHCP-non-PD in some IPv6/4G deployments). The common thinking at operators and advisers is still that a /64 should be given to an User Equipment. This must change: the 3GPP specs and operator deployments must give /62 to UEs, and not /64. Alex Thanks - Fred fred.l.temp...@boeing.com Alex Thanks - Fred fred.l.temp...@boeing.com Alex But yes, I agree with you. cheers, --satoru On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu alexandru.petre...@gmail.com mailto:alexandru.petre...@gmail.com wrote: Hi, In addition to what Behcet says. I read the example below. I think it is just an example, but just to make sure. Please - do not allocate /64s to end users in a cellular network. Allocate at least /62s to end users. This is to allow the smartphone to perform tethering (small network of wifi devices connecting through the smartphone to the Internet). The assumption of /64 to end user is not good at all. (and yes, I agree that these /62s may be aggregated into a larger prefix and advertised upstream as a single prefix instead of multiple host-based routes). Yours, Alex Petrescu Le 26/05/2015 22:34, Behcet Sarikaya a écrit : Hi Satoru, Thanks for your reply. Let me continue the discussion with your text in Section 3.2 where you mention vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) that defines FPCP Agent function and Client function. I don't understand how you could justify defining a new forwarding policy configuration protocol to do this Agent/Client functionality? Why not use similar Agent/Client models that are being defined rather than defining a new protocol? I think this point requires much stronger justification which I could not see in Section 3.2. Are you that we have to to reinvent the wheel, rather than reusing something that is already available? How are we going to reinvent that wheel also remains to be seen, I think. Regards, Behcet On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima satoru.matsush...@gmail.com mailto:satoru.matsush...@gmail.com wrote: Hi Bechet-san, Thank you for your question. In step (15), I meant that EPC-E advertises prefix including UE assigned prefixes. For example, in the case of /64 prefixes assigned to UEs from a /56 space, that /56 is advertised by EPC-E to upstream routers. So the advertised route isn't host routes. Depends on configuration policy, but one case is that the source of that advertised /56 route might be statically configured in EPC-E. Regards
Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s
Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Thursday, June 04, 2015 7:09 AM To: Templin, Fred L; Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 04/06/2015 05:42, Templin, Fred L a écrit : Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Wednesday, June 03, 2015 8:36 AM To: Templin, Fred L; Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 20:21, Templin, Fred L a écrit : Hi Alex, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru Petrescu Sent: Friday, May 29, 2015 10:59 AM To: Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 15:30, Satoru Matsushima a écrit : Ah OK. thanks. Slightly off-topic, I think that there is still chance for tethering with single /64 if it is allocated as a off-link prefix. Yes, there is still such a chance. But it can not tether more than one single subnet. Connected vehicles need several subnets. How would it be if the vehicle received a single prefix, but it could be shorter than /64 (e.g., /56, /48. etc.)? Would the vehicle subnetting be satisfied if it received a shorter prefix from which many /64s could be allocated? Certainly yes. Each vehicle needs such a shorter-than-64 prefix allocated to it. For example, an automobile connecting to LTE receives a /62 from the operator and makes four /64s out of it: one for its CAN-entertainment, one for its CAN-safety, one for its WiFi and one for its Bluetooth. This is a MUST. Allocating a single /64 to a vehicle can not accommodate all these unbridgeable subnets. OK, that is good. Giving a mobile router something shorter than /64 should be no problem, at least up to practical limitations of the prefix delegation authority's available prefix space. DHCPv6 PD provides all that is needed to give out right-sized prefixes. I agree DHCP-PD provides the necessary tool. But unfortunately the cellular operators have not deployed DHCPv6-PD (although yes there is some DHCP-non-PD in some IPv6/4G deployments). That is a pity, because DHCPv6 PD (along with IPv6 ND and BGP) are all that are necessary for distributed mobility management. The common thinking at operators and advisers is still that a /64 should be given to an User Equipment. This must change: the 3GPP specs and operator deployments must give /62 to UEs, and not /64. Why not a /N instead of just a /62 or /64? N could be anything (62, 60, 56, 48, etc.) as long as it is a proper subset of the prefix space the operator has available for delegation. Thanks - Fred fred.l.temp...@boeing.com Alex Thanks - Fred fred.l.temp...@boeing.com Alex Thanks - Fred fred.l.temp...@boeing.com Alex But yes, I agree with you. cheers, --satoru On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu alexandru.petre...@gmail.com mailto:alexandru.petre...@gmail.com wrote: Hi, In addition to what Behcet says. I read the example below. I think it is just an example, but just to make sure. Please - do not allocate /64s to end users in a cellular network. Allocate at least /62s to end users. This is to allow the smartphone to perform tethering (small network of wifi devices connecting through the smartphone to the Internet). The assumption of /64 to end user is not good at all. (and yes, I agree that these /62s may be aggregated into a larger prefix and advertised upstream as a single prefix instead of multiple host-based routes). Yours, Alex Petrescu Le 26/05/2015 22:34, Behcet Sarikaya a écrit : Hi Satoru, Thanks for your reply. Let me continue the discussion with your text in Section 3.2 where you mention vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) that defines FPCP Agent function and Client function. I don't understand how you could justify defining a new forwarding policy configuration protocol to do this Agent/Client functionality? Why not use similar Agent/Client models that are being defined rather than defining a new protocol? I think this point requires much stronger justification which I could not see in Section 3.2. Are you that we have to to reinvent the wheel, rather than reusing something that is already available? How are we going to reinvent that wheel also remains to be seen, I think. Regards, Behcet
Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s
Le 29/05/2015 20:21, Templin, Fred L a écrit : Hi Alex, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru Petrescu Sent: Friday, May 29, 2015 10:59 AM To: Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 15:30, Satoru Matsushima a écrit : Ah OK. thanks. Slightly off-topic, I think that there is still chance for tethering with single /64 if it is allocated as a off-link prefix. Yes, there is still such a chance. But it can not tether more than one single subnet. Connected vehicles need several subnets. How would it be if the vehicle received a single prefix, but it could be shorter than /64 (e.g., /56, /48. etc.)? Would the vehicle subnetting be satisfied if it received a shorter prefix from which many /64s could be allocated? Certainly yes. Each vehicle needs such a shorter-than-64 prefix allocated to it. For example, an automobile connecting to LTE receives a /62 from the operator and makes four /64s out of it: one for its CAN-entertainment, one for its CAN-safety, one for its WiFi and one for its Bluetooth. This is a MUST. Allocating a single /64 to a vehicle can not accommodate all these unbridgeable subnets. Alex Thanks - Fred fred.l.temp...@boeing.com Alex But yes, I agree with you. cheers, --satoru On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu alexandru.petre...@gmail.com mailto:alexandru.petre...@gmail.com wrote: Hi, In addition to what Behcet says. I read the example below. I think it is just an example, but just to make sure. Please - do not allocate /64s to end users in a cellular network. Allocate at least /62s to end users. This is to allow the smartphone to perform tethering (small network of wifi devices connecting through the smartphone to the Internet). The assumption of /64 to end user is not good at all. (and yes, I agree that these /62s may be aggregated into a larger prefix and advertised upstream as a single prefix instead of multiple host-based routes). Yours, Alex Petrescu Le 26/05/2015 22:34, Behcet Sarikaya a écrit : Hi Satoru, Thanks for your reply. Let me continue the discussion with your text in Section 3.2 where you mention vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) that defines FPCP Agent function and Client function. I don't understand how you could justify defining a new forwarding policy configuration protocol to do this Agent/Client functionality? Why not use similar Agent/Client models that are being defined rather than defining a new protocol? I think this point requires much stronger justification which I could not see in Section 3.2. Are you that we have to to reinvent the wheel, rather than reusing something that is already available? How are we going to reinvent that wheel also remains to be seen, I think. Regards, Behcet On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima satoru.matsush...@gmail.com mailto:satoru.matsush...@gmail.com wrote: Hi Bechet-san, Thank you for your question. In step (15), I meant that EPC-E advertises prefix including UE assigned prefixes. For example, in the case of /64 prefixes assigned to UEs from a /56 space, that /56 is advertised by EPC-E to upstream routers. So the advertised route isn't host routes. Depends on configuration policy, but one case is that the source of that advertised /56 route might be statically configured in EPC-E. Regards, --satoru On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya sarikaya2...@gmail.com mailto:sarikaya2...@gmail.com wrote: Hi Matsushima-san, I have a question on your draft: In Sec. 3.2, page 11, you say In step (15), the EPC-E advertises routes to upstream routers ... Are these routes static/host routes? Regards, Behcet ___ dmm mailing list dmm@ietf.org mailto:dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org mailto: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
Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s
Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Wednesday, June 03, 2015 8:36 AM To: Templin, Fred L; Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 20:21, Templin, Fred L a écrit : Hi Alex, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru Petrescu Sent: Friday, May 29, 2015 10:59 AM To: Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 15:30, Satoru Matsushima a écrit : Ah OK. thanks. Slightly off-topic, I think that there is still chance for tethering with single /64 if it is allocated as a off-link prefix. Yes, there is still such a chance. But it can not tether more than one single subnet. Connected vehicles need several subnets. How would it be if the vehicle received a single prefix, but it could be shorter than /64 (e.g., /56, /48. etc.)? Would the vehicle subnetting be satisfied if it received a shorter prefix from which many /64s could be allocated? Certainly yes. Each vehicle needs such a shorter-than-64 prefix allocated to it. For example, an automobile connecting to LTE receives a /62 from the operator and makes four /64s out of it: one for its CAN-entertainment, one for its CAN-safety, one for its WiFi and one for its Bluetooth. This is a MUST. Allocating a single /64 to a vehicle can not accommodate all these unbridgeable subnets. OK, that is good. Giving a mobile router something shorter than /64 should be no problem, at least up to practical limitations of the prefix delegation authority's available prefix space. DHCPv6 PD provides all that is needed to give out right-sized prefixes. Thanks - Fred fred.l.temp...@boeing.com Alex Thanks - Fred fred.l.temp...@boeing.com Alex But yes, I agree with you. cheers, --satoru On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu alexandru.petre...@gmail.com mailto:alexandru.petre...@gmail.com wrote: Hi, In addition to what Behcet says. I read the example below. I think it is just an example, but just to make sure. Please - do not allocate /64s to end users in a cellular network. Allocate at least /62s to end users. This is to allow the smartphone to perform tethering (small network of wifi devices connecting through the smartphone to the Internet). The assumption of /64 to end user is not good at all. (and yes, I agree that these /62s may be aggregated into a larger prefix and advertised upstream as a single prefix instead of multiple host-based routes). Yours, Alex Petrescu Le 26/05/2015 22:34, Behcet Sarikaya a écrit : Hi Satoru, Thanks for your reply. Let me continue the discussion with your text in Section 3.2 where you mention vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) that defines FPCP Agent function and Client function. I don't understand how you could justify defining a new forwarding policy configuration protocol to do this Agent/Client functionality? Why not use similar Agent/Client models that are being defined rather than defining a new protocol? I think this point requires much stronger justification which I could not see in Section 3.2. Are you that we have to to reinvent the wheel, rather than reusing something that is already available? How are we going to reinvent that wheel also remains to be seen, I think. Regards, Behcet On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima satoru.matsush...@gmail.com mailto:satoru.matsush...@gmail.com wrote: Hi Bechet-san, Thank you for your question. In step (15), I meant that EPC-E advertises prefix including UE assigned prefixes. For example, in the case of /64 prefixes assigned to UEs from a /56 space, that /56 is advertised by EPC-E to upstream routers. So the advertised route isn't host routes. Depends on configuration policy, but one case is that the source of that advertised /56 route might be statically configured in EPC-E. Regards, --satoru On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya sarikaya2...@gmail.com mailto:sarikaya2...@gmail.com wrote: Hi Matsushima-san, I have a question on your draft
Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s
Ah OK. thanks. Slightly off-topic, I think that there is still chance for tethering with single /64 if it is allocated as a off-link prefix. But yes, I agree with you. cheers, --satoru On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu alexandru.petre...@gmail.com wrote: Hi, In addition to what Behcet says. I read the example below. I think it is just an example, but just to make sure. Please - do not allocate /64s to end users in a cellular network. Allocate at least /62s to end users. This is to allow the smartphone to perform tethering (small network of wifi devices connecting through the smartphone to the Internet). The assumption of /64 to end user is not good at all. (and yes, I agree that these /62s may be aggregated into a larger prefix and advertised upstream as a single prefix instead of multiple host-based routes). Yours, Alex Petrescu Le 26/05/2015 22:34, Behcet Sarikaya a écrit : Hi Satoru, Thanks for your reply. Let me continue the discussion with your text in Section 3.2 where you mention vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) that defines FPCP Agent function and Client function. I don't understand how you could justify defining a new forwarding policy configuration protocol to do this Agent/Client functionality? Why not use similar Agent/Client models that are being defined rather than defining a new protocol? I think this point requires much stronger justification which I could not see in Section 3.2. Are you that we have to to reinvent the wheel, rather than reusing something that is already available? How are we going to reinvent that wheel also remains to be seen, I think. Regards, Behcet On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima satoru.matsush...@gmail.com wrote: Hi Bechet-san, Thank you for your question. In step (15), I meant that EPC-E advertises prefix including UE assigned prefixes. For example, in the case of /64 prefixes assigned to UEs from a /56 space, that /56 is advertised by EPC-E to upstream routers. So the advertised route isn't host routes. Depends on configuration policy, but one case is that the source of that advertised /56 route might be statically configured in EPC-E. Regards, --satoru On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya sarikaya2...@gmail.com wrote: Hi Matsushima-san, I have a question on your draft: In Sec. 3.2, page 11, you say In step (15), the EPC-E advertises routes to upstream routers ... Are these routes static/host routes? Regards, Behcet ___ 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] vepc draft Rev. 04 - /62s to UE, not /64s
Le 29/05/2015 15:30, Satoru Matsushima a écrit : Ah OK. thanks. Slightly off-topic, I think that there is still chance for tethering with single /64 if it is allocated as a off-link prefix. Yes, there is still such a chance. But it can not tether more than one single subnet. Connected vehicles need several subnets. Alex But yes, I agree with you. cheers, --satoru On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu alexandru.petre...@gmail.com mailto:alexandru.petre...@gmail.com wrote: Hi, In addition to what Behcet says. I read the example below. I think it is just an example, but just to make sure. Please - do not allocate /64s to end users in a cellular network. Allocate at least /62s to end users. This is to allow the smartphone to perform tethering (small network of wifi devices connecting through the smartphone to the Internet). The assumption of /64 to end user is not good at all. (and yes, I agree that these /62s may be aggregated into a larger prefix and advertised upstream as a single prefix instead of multiple host-based routes). Yours, Alex Petrescu Le 26/05/2015 22:34, Behcet Sarikaya a écrit : Hi Satoru, Thanks for your reply. Let me continue the discussion with your text in Section 3.2 where you mention vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) that defines FPCP Agent function and Client function. I don't understand how you could justify defining a new forwarding policy configuration protocol to do this Agent/Client functionality? Why not use similar Agent/Client models that are being defined rather than defining a new protocol? I think this point requires much stronger justification which I could not see in Section 3.2. Are you that we have to to reinvent the wheel, rather than reusing something that is already available? How are we going to reinvent that wheel also remains to be seen, I think. Regards, Behcet On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima satoru.matsush...@gmail.com mailto:satoru.matsush...@gmail.com wrote: Hi Bechet-san, Thank you for your question. In step (15), I meant that EPC-E advertises prefix including UE assigned prefixes. For example, in the case of /64 prefixes assigned to UEs from a /56 space, that /56 is advertised by EPC-E to upstream routers. So the advertised route isn't host routes. Depends on configuration policy, but one case is that the source of that advertised /56 route might be statically configured in EPC-E. Regards, --satoru On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya sarikaya2...@gmail.com mailto:sarikaya2...@gmail.com wrote: Hi Matsushima-san, I have a question on your draft: In Sec. 3.2, page 11, you say In step (15), the EPC-E advertises routes to upstream routers ... Are these routes static/host routes? Regards, Behcet ___ dmm mailing list dmm@ietf.org mailto:dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org mailto: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] vepc draft Rev. 04 - /62s to UE, not /64s
Hi Alex, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru Petrescu Sent: Friday, May 29, 2015 10:59 AM To: Satoru Matsushima Cc: dmm Subject: Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s Le 29/05/2015 15:30, Satoru Matsushima a écrit : Ah OK. thanks. Slightly off-topic, I think that there is still chance for tethering with single /64 if it is allocated as a off-link prefix. Yes, there is still such a chance. But it can not tether more than one single subnet. Connected vehicles need several subnets. How would it be if the vehicle received a single prefix, but it could be shorter than /64 (e.g., /56, /48. etc.)? Would the vehicle subnetting be satisfied if it received a shorter prefix from which many /64s could be allocated? Thanks - Fred fred.l.temp...@boeing.com Alex But yes, I agree with you. cheers, --satoru On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu alexandru.petre...@gmail.com mailto:alexandru.petre...@gmail.com wrote: Hi, In addition to what Behcet says. I read the example below. I think it is just an example, but just to make sure. Please - do not allocate /64s to end users in a cellular network. Allocate at least /62s to end users. This is to allow the smartphone to perform tethering (small network of wifi devices connecting through the smartphone to the Internet). The assumption of /64 to end user is not good at all. (and yes, I agree that these /62s may be aggregated into a larger prefix and advertised upstream as a single prefix instead of multiple host-based routes). Yours, Alex Petrescu Le 26/05/2015 22:34, Behcet Sarikaya a écrit : Hi Satoru, Thanks for your reply. Let me continue the discussion with your text in Section 3.2 where you mention vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) that defines FPCP Agent function and Client function. I don't understand how you could justify defining a new forwarding policy configuration protocol to do this Agent/Client functionality? Why not use similar Agent/Client models that are being defined rather than defining a new protocol? I think this point requires much stronger justification which I could not see in Section 3.2. Are you that we have to to reinvent the wheel, rather than reusing something that is already available? How are we going to reinvent that wheel also remains to be seen, I think. Regards, Behcet On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima satoru.matsush...@gmail.com mailto:satoru.matsush...@gmail.com wrote: Hi Bechet-san, Thank you for your question. In step (15), I meant that EPC-E advertises prefix including UE assigned prefixes. For example, in the case of /64 prefixes assigned to UEs from a /56 space, that /56 is advertised by EPC-E to upstream routers. So the advertised route isn't host routes. Depends on configuration policy, but one case is that the source of that advertised /56 route might be statically configured in EPC-E. Regards, --satoru On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya sarikaya2...@gmail.com mailto:sarikaya2...@gmail.com wrote: Hi Matsushima-san, I have a question on your draft: In Sec. 3.2, page 11, you say In step (15), the EPC-E advertises routes to upstream routers ... Are these routes static/host routes? Regards, Behcet ___ dmm mailing list dmm@ietf.org mailto:dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org mailto: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] vepc draft Rev. 04 - /62s to UE, not /64s
Hi, In addition to what Behcet says. I read the example below. I think it is just an example, but just to make sure. Please - do not allocate /64s to end users in a cellular network. Allocate at least /62s to end users. This is to allow the smartphone to perform tethering (small network of wifi devices connecting through the smartphone to the Internet). The assumption of /64 to end user is not good at all. (and yes, I agree that these /62s may be aggregated into a larger prefix and advertised upstream as a single prefix instead of multiple host-based routes). Yours, Alex Petrescu Le 26/05/2015 22:34, Behcet Sarikaya a écrit : Hi Satoru, Thanks for your reply. Let me continue the discussion with your text in Section 3.2 where you mention vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP) that defines FPCP Agent function and Client function. I don't understand how you could justify defining a new forwarding policy configuration protocol to do this Agent/Client functionality? Why not use similar Agent/Client models that are being defined rather than defining a new protocol? I think this point requires much stronger justification which I could not see in Section 3.2. Are you that we have to to reinvent the wheel, rather than reusing something that is already available? How are we going to reinvent that wheel also remains to be seen, I think. Regards, Behcet On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima satoru.matsush...@gmail.com wrote: Hi Bechet-san, Thank you for your question. In step (15), I meant that EPC-E advertises prefix including UE assigned prefixes. For example, in the case of /64 prefixes assigned to UEs from a /56 space, that /56 is advertised by EPC-E to upstream routers. So the advertised route isn't host routes. Depends on configuration policy, but one case is that the source of that advertised /56 route might be statically configured in EPC-E. Regards, --satoru On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya sarikaya2...@gmail.com wrote: Hi Matsushima-san, I have a question on your draft: In Sec. 3.2, page 11, you say In step (15), the EPC-E advertises routes to upstream routers ... Are these routes static/host routes? Regards, Behcet ___ 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
