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

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