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
_______________________________________________ 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
