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

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.

But yes, I agree with you.

cheers,
--satoru

On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu <
[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]> 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]
>>> >
>>> 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]
>> 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