Re: Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt

On Wed, Jul 17, 2013 at 12:10 AM, Bruno Mongazon-Cazavet <
[email protected]> wrote:

> Le 16/07/2013 16:27, Peter McCann a écrit :
>
>  Satoru Matsushima wrote:
>>
>>> Hi Peter,
>>>
>>> On 2013/07/16, at 3:49, Peter McCann <[email protected]> wrote:
>>>
>>>> I guess I don't understand the "PDN Prefix" and "subnet ID" fields
>>>> that you have in Figure 4.  You state:
>>>>
>>>>    Each PDN is assumed to have single or several prefixes (called PDN
>>>>    prefix) used to generate UE's address.  Followed by the PDN prefix in
>>>>    Figure 4, there is 16-bit TEID assigned for a UE's session at SGW on
>>>>    the control plane.  TEID is 16 bits identifier in GTP header to
>>>>    distinguish each bearer.  The remaining bits are filled by subnet ID.
>>>>    The prefix is allocated per UE and used for address assignment by
>>>>    SLAAC or DHCPv6.
>>>> Is Figure 4 supposed to be the Next Hop or the Destination?  I assumed
>>>> it was Next Hop because it has the TEID encoded in it.  However, some
>>>> of the above paragraph leads me to believe it is about the UE's user
>>>> plane IP address.
>>>>
>>>>  The figure 4 illustrates UE's prefix so it shows the destination.
>>> Encoding TEID is just a seed to create UE's prefix in the stateless-pd
>>> manner.
>>>
>> Doesn't the TEID change on every eNB handover?  I thought the UE's prefix
>> should remain constant across handovers.
>>
>
>
If you use stateless-pd rule for UE's prefix generation, the embedded TEID
is SGW assigned one. So the delegated prefix is stable during across eNB
handover. Please see the section 3.3 in update version of the draft.
Anycast routing no longer requires hand-over between SGW in virtualized EPC.



> Yes TEID changes on handover and when UE exits Idle-Mode (it has
> previously entered).


Thanks, we haven't mention about in the case of Idle-Mode exit. will update
with it in a next version. It would be in control-plane awareness section.



>
>
>>  We hasn't illustrate yet how to encode the TEID in next-hop.
>>> But as we mentioned in the document, we expect BGP remote next-hop as
>>> the way to encode it in the sub-TLV of the remote next-hop attribute.
>>>
>> I would think that the Next-Hop would change on mobility events, but the
>> Destination would remain the same (UE prefix).  Why is this not the case?
>>
>
Yes, exactly.

cheers,
--satoru

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm