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

Fred,

Le 08/06/2015 19:08, Templin, Fred L a écrit :
[...]

>>>> 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.)
>
> What I was thinking was that users could pay for different classes of
> service. Basic service could be a /64 (or /63 or /62). Premium
> service could be a /60. Super-premium could be a /56, etc.

Well it looks like a good idea.  It is a bit new compared to IPv4 in
cellular networks (there is no concept of premium service delivery of
several IPv4 addresses per single device, and there is no StdsTrack PD
for DHCPv4).  Do you think cellular operators may create such new
payment schemes for classes of service in IPv6?  Or rather migrate the
existing IPv4 payment schemes from IPv4 - a one to one mapping between
concepts, modulo the address length being bigger?

> Point being that the mechanism should support any prefix delegation
> size that the user has contracted with the service provider for; not
> just a fixed one-size-fits-all size for all users.

I agree - the mechanism is there.

Why the cellular operators dont respond to DHCPv6 Prefix Delegation
requests from the User Equipments?

Alex

>
> Thanks - Fred [email protected]
>
>>
>> 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