Re: 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.

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