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

[Behcet Sarikaya <[e-mail]>]

On Thu, May 11, 2017 at 9:31 AM, Behcet Sarikaya <[e-mail]>
wrote:

>
>
> On Wed, May 10, 2017 at 7:58 PM, Tom Herbert <[e-mail]> wrote:
>
>> 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.
>>
>> 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.
>>
>>
> Folks, these are Tom's personal thinking. Those that are not mentioned in
> the PS draft are not in scope.
>
>

Let me clarify. I apologize if I offended anybody. No offense folks.
We are not in the business of policing people.
In our list mails are written freely and people write whatever they think,
i.e. it is an IETF list.

Regards,

Behcet

> Behcet
>
>> 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.
>> >>
>>
>
>