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 list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
