Re: vepc draft Rev. 04 - /62s to UE, not /64s

Hi Fred,

Le 04/06/2015 17:10, Templin, Fred L a écrit :
> Hi Alex,
>
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email protected]] 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:[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).
>
> 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 [email protected]
>
>> 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