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

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