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.)
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
