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

Reply via email to