Re: [Ideas] [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

[Tom Herbert <[e-mail]>]

On Wed, May 10, 2017 at 10:36 PM, Uma Chunduri <[e-mail]> wrote:
> In-line [Uma]:
>
> --
> Uma C.
>
> -----Original Message-----
> From: Tom Herbert [mailto:[e-mail]]
> Sent: Wednesday, May 10, 2017 5:58 PM
> To: Uma Chunduri <[e-mail]>
> Cc: Behcet Sarikaya <[e-mail]>; Lorenzo Colitti
> <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [5gangip] FW: New Version Notification for
> draft-xyx-5gip-ps-00.txt
>
> On Wed, May 10, 2017 at 5:10 PM, Uma Chunduri <[e-mail]>
> wrote:
>> + IDEAS
>>
>> https://tools.ietf.org/html/draft-padma-ideas-use-cases-00
>>
>> Section 7 covers this use case - I saw you are part of this (may be
>> this use case didn't come from you)
>>
>> This is being worked out  and solution would be put forth soon..
>>
> Okay, I think I see the confusion.
>
> [Uma]: I don't see any confusion.
>                I was just saying the solution you described here
> https://www.ietf.org/mail-archive/web/5gangip/current/msg00488.html
>                doesn't solve IP address change case (UPF change) but only
> addresses (R)AN mobility.
>
> In an Identifier/Locator split there are two addresses that are associate
> with a node. One is the identifier that expresses the logical and persistent
> address of the node ("who")-- this what applications see and what might
> returned from DNS if an addressed is looked by domain name. The other
> address is the locator, this expresses where the node is current at
> ("where"). As a mobile node moves from place to place it's location changes
> so it's locator changes. But, it's identifier address does not change-- that
> uniquely identifies the node regardless of where it's at. In order to send
> to a node (by it's identifier address, a some point in the path, someone
> needs to know to that to reach the addressed node the packet has to be sent
> to its locator address. So there is a mapping from identifier to locator and
> then packet is forwarded to locator address (by encapsulation, segment
> routing, ILA, etc.). This really equivalent to virtual to physical address
> mapping, or home address to mobile address.
> So it's really the locator address for a node that changes, not the the
> identifier. The system needs to ensure that packets delivered to the
> application always get the identifier address and that keeps source address
> persistent.
>
> [Uma]: Precisely  and I don't see how you get that stable identifier in ILA
> where you split Identity and Locator (ILA) logically  in the same UE address
> where your host on the other end is communicating to (in your example
> https://www.ietf.org/mail-archive/web/5gangip/current/msg00488.html )
>

The procedures are described in the ILA draft also
(https://datatracker.ietf.org/doc/draft-herbert-nvo3-ila). For
instance Scenario 7 shows Internet host to tenant system.
>
> Tom
>
>>
>> --
>> Uma C.
>>
>>
>> -----Original Message-----
>> From: Tom Herbert [mailto:[e-mail]]
>> Sent: Wednesday, May 10, 2017 5:00 PM
>> To: Uma Chunduri <[e-mail]>
>> Cc: Behcet Sarikaya <[e-mail]>; Lorenzo Colitti
>> <[e-mail]>; [e-mail]; [e-mail]
>> Subject: Re: [5gangip] FW: New Version Notification for
>> draft-xyx-5gip-ps-00.txt
>>
>> On Wed, May 10, 2017 at 4:47 PM, Uma Chunduri <[e-mail]>
>> wrote:
>>>
>>>         >No, the source address does not change, TCP connections don't
>>> break.
>>>
>>> Source address can change if UE moves from UPF serving area.
>>> But, now I see your case is (R)AN mobility case (same UPF serving area).
>>>
>>>         >Please see my example I posted previously. Overlay networks
>>> (tunnels) are used between EnodeBs and gateways.
>>>                 >A distributed mapping service is run that these nodes
>>> share, so the Internet can communicate with mobile hosts and mobile hosts
>>> can communicate between themselves.
>>>                >This method is transparent to hosts including UEs and
>>> there are no changes need to transport layer. It's a fairly straightforward
>>> use of tunneling once an efficient mapping system is in place.
>>>
>>> I get that.
>>>
>>> Then this is may be good for 4G, but I guess we are talking about 5G here
>>> and I assumes PGW/UPF mobility and hence the Source IP address change is
>>> considered in your solution.
>>>
>> In that case the TCP connection would break regardless. Transport layer
>> mobility, like QUIC, might then be solution.
>>
>>> --
>>> Uma C.
>>>
>