Subject: [Ideas] Mobility usecase draft-padma-ideas-problem-statement-00.txt

From: Kiran Makhijani <[email-masked]>
Date: Tue, 04 Oct 2016 23:02:30 +0000

Hello authors,
+1 on the problem statement. I think a uniform approach to mapping system
framework is very much needed.
But  if it is ID specific there are many more functionalities related to
Identity in the networks than just the mapping systems. Is the scope only
limited to mapping function aspects?

I also have some questions in the mobility section.
- In 7.1.1, "we  assume that ID functionality is handled within the network
and is transparent to the UEs or hosts."
What kind of ID functionality is being assumed here?
- Figure in 7.1.1 assumes that MGW is only required for mobile networks.
Are you saying that Host1 and Host2 are not ID enabled and IDs are only
mappable in mobile networks. So, if UE does not need mobility, it need not
go through MGW?
- Can I assume that functional block "Mapping System" is missing from
figure? OR is it not same as the MGW?

1.  The new carrier provides the full locator (mapping to
       Base_station2) and the MGW sends directly to that locator

- Not sure what you said in this part and the lines that followed in 7.1.2.
Could you explain what is full locator (vs just locator) and only
significant in inter-provider case? a UE can move from one base station to
other in single provider network too. Why wont you need 'full locator'
there?

Thanks
Kiran

-- 
Kiran

---

From: Tom Herbert <[email-masked]>
Date: Fri, 28 Oct 2016 16:53:20 -0700

> limited to mapping function aspects?
For the purposes of this I would say that the scope is limited to
mapping function aspects. But, even with that scope it is going to be
hard to produce a mapping system without having some discussion as to
how IDs are generated and managed in the first place (like how do we
ensure uniqueness, ID namespaces, etc.). So in the end the scope
actually will be pretty broad it we're trying for a general solution.

> What kind of ID functionality is being assumed here?

I'd say this refers to the mapping of location to identifiers. A UE
might know its identity and give that do the network, but the mapping,
mobility related functions are more likely handled by the network.
This pragmatic in that we can't change all UEs (e.g. smart phones) to
participate in a new mobility protocol.

> - Figure in 7.1.1 assumes that MGW is only required for mobile networks. Are
> you saying that Host1 and Host2 are not ID enabled and IDs are only mappable
> in mobile networks. So, if UE does not need mobility, it need not go through
> MGW?

I thinks that's true based on the scalability problem I mentioned
above about UEs participating in mobility. Most likely they will live
behind a MGW (ILA router in ILA nomenclature) that does mapping and
forwarding for mobile nodes. If a MGW doesn't need mobility then it's
packets (directed to it) wouldn't need to go through MGW-- it just
looks like a non-mobile host at that point.

> figure? OR is it not same as the MGW?
MGW uses mapping system. The mapping system wouldn't be a discrete
node in the network. Although there might be devices that just provide
resolutions and mapping without implementing gateway functionality
(may like an NVA in nvo3 parlance).

> other in single provider network too. Why wont you need 'full locator'
I think we're making a subtle distinction that should probably be
spelled out. Consider that after migration UE.A wants to speak to UE.B
in a different carrier network. We need an MGW to resolve the address.
There's are two possibilities reference here:

1) Two mappings: UE.A sends packet to a local MGW. MGW maps
destination to an address of a MGW in the other provider. Packet
forwarded to that provider. Received by the MGW at that provider and
then a second mapping occurs to get packet to UE.B within that
provider.
2) One mapping: UE.A sends packet to a local MGW. The local MGW knows
the exact mapping for the address of UE.B in other provider (this is
what we meant by full locator). The packet is mapped and forwarded
direct to where UE.B without any further mapping.

The advantage of #1 is that providers don't need to share as much
information. For instance, if UE.B is moving around in the new
providers network, UE.A's network doesn't need to know about that. The
downside is that it results in more hops and triangular rouitng.

Tom

> Thanks
> Kiran
>
>
>
> --
> Kiran
>
> _______________________________________________
> Ideas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ideas
>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 28 Oct 2016 19:08:20 -0700

> downside is that it results in more hops and triangular rouitng.

Tom, LISP supports both models but #1 is more popular due to NATs are in the data path. 

Dino