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:[email protected]]
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:[email protected]] 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
[email protected]
Alex
Thanks - Fred
[email protected]
Alex
But yes, I agree with you.
cheers,
--satoru
On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu
<[email protected]
<mailto:[email protected]>> 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
<[email protected]
<mailto:[email protected]>> 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
<[email protected]
<mailto:[email protected]>>
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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
