Re: [Ideas] Comments to draft-vonhugo-5gangip-ip-issues-00

[<[e-mail]>]

Hi Dino,
Thanks for the detailed review  - we will come back to your comments when revising the draft next time!

Best Regards
Dirk

From: Dino Farinacci [mailto:[e-mail]]
Sent: Dienstag, 20. September 2016 19:07
To: [e-mail]; [e-mail]
Cc: von Hugo, Dirk; Padma Pillay-Esnault; Richard Li; AshwoodsmithPeter; Tom Herbert; David Meyer; [e-mail]
Subject: Re: Comments to draft-vonhugo-5gangip-ip-issues-00

Cross posting to this list.

Dino


On Sep 20, 2016, at 9:15 AM, Dino Farinacci <[e-mail]<mailto:[e-mail]>> wrote:

Copying the list.

Dino


On Sep 20, 2016, at 8:10 AM, Behcet Sarikaya <[e-mail]<mailto:[e-mail]>> wrote:

Hi Dino,

Please post your comments to the list, 5gangip.
We may have answers, so it is better to discuss these things on our list the draft was announced.
Actually the draft was intended to be a summary of the list discussion so far, we considered all the posts including from you when writing it.

Regards,

behcet

On Mon, Sep 19, 2016 at 6:03 PM, Dino Farinacci <[e-mail]<mailto:[e-mail]>> wrote:

I am copying others who may be interested in my commentary. Your ID text comes first indented and my comments follow.


Abstract

   This document discusses considerations related to open and upcoming
   issues with upcoming new communication systems denoted as 5G.  The

You could make this first sentence a bit more clear. How about:

This document discusses the problem space, use-cases and potential solutions related to supporting the next-generation mobile 5G communication infrastructure.


1.  Introduction

   This document focuses on IP architecture and protocol aspects related
   to upcoming new communication system dubbed as 5G.  Originally

It is not dubbed 5G, IT IS the 5th generation mobile infrastructure. I would use a more direct term.


   foreseen to be available from 2020 onwards such a converged ICT

Define ICT before using it.


   Other key improvements which are not always direct quantitatively
   measurable cover so-called soft features are also essential for 5G:

   o  Network scalability and flexibility

   o  Consistent customer experience

   o  Service and network trust, reliability and security

   o  Operational efficiency

   o  Openness for innovation

Do you want to include a bullet identifying slicing as a requirement. Because it appears as a solution to manage both UE and infrastructure resources as well as allowing for incremental deployability of new services. And you also mention it in section 7.

Also what is the hand-off latency? That is what is the tolerance for any packet loss. That needs to be quantified.


   In this case, mobility issue will arise.  A cell phone moves, but its
   identifier (ID) doesn't change.  Can we re-think about ID related
   protocols such as LISP?  Can we re-scope it to just mobility?  ID

Well draft-meyer-lisp-mn has been around since 2009 so we thought about this a long time ago. So LISP doesn’t need to change to support cell phone moves.

I would suggest rephrasing the above reference to LISP to “Can LISP be used for this use-case?”.


   plays a central role in mobility.  Can we design a new protocol, say
   ID-Oriented Networking Protocol?  In future, more and more mobile
   things are connected to the internet: connected cars, connected
   drones, etc.

Note a cell phone today has so many identifiers already factory installed. It would be a pity to not use them for identifying connections or nodes. And an IMEI could be embedded into an IPv6 address if either LISP or ILA is used.


   For more discussion on this see Section 8.

6.  Edge Network with no Tunneling

   In fixed network, PPPoE protocol [RFC2516] is used between the
   residential gateway and broadband network gateway to transport the
   residential users IP packets to the fixed network gateway to the
   Internet.  PPPoE protocol requires 8 octets of header in every IP
   packet, thereby reducing the MTU size by 8 octets to usually 1492
   octets.  PPPoE protocol is carried in Ethernet frames with 18 octet
   headers where the destination address is the broadband network
   gateway address.

This is why it is good to consider BOTH ILA (a translation based mechanism) and LISP (an encapsulation based mechanism). Note they can BOTH be used for the data-plane areas in the network where you need smaller headers. But note they can BOTH use ONE control plane. That is what is important.


von Hugo & Sarikaya      Expires March 18, 2017                 [Page 7]
Internet-Draft                5G IP Issues                September 2016


   In mobile network, IP packets are tunneled using GTP data plane
   protocol called GTP-U.  First eNodeB or the base station tunnels UE's
   IP packets to the Serving Gateway, in S1 GTP tunnel and then the
   serving gateway tunnels to the Packet Gateway, called S5 tunnel.
   Both of them are UDP tunnels which adds 8 octet header and GTP
   protocl header is 12 octets, so a total of 20 octets are used.  In
   addition also an IPSec header should be accounted for between eNodeB
   and SGW.

Why not more end-to-end? That is on each end of the TCP connection would be the most optimal but at least from eNodeB to PGW perhaps.


   Tunneling in both fixed and mobile networks has the purpose of
   directing the user traffic to the correct gateway.  As exemplarily
   shown above, however, tunneling adds a lot of overhead to the user IP
   packets and therefore inefficiencies arise including reducing the MTU
   size.

If you need to run ID/Loc separation in the UE itself, then use ILA. But if you don’t need to you can use LISP from sGW to pGW or all the way to to a data-center xTR or CPE xTR.

I had a slide in 5gangip that showed all combinations where encapsulation could go.

But note tunneling is not required (and I wouldn’t suggest it), to run over the RAN. That can easily be avoided.


   If tunneling can be avoided, i.e. if edge networks can be designed
   with no tunneling, a corrollary of this would be no gateways would be
   needed, leading to edge networks with no tunneling or no gateway.
   The means to avoid gateways and tunneling a direct end-to-end routing
   has to be established in the edge network.

   With routing support edge networks can direct the user traffic to the
   correct destinations, rather than tunneling to the gateways.  In
   order to deal with user mobility, ID-oriented networking protocol
   would be needed.  So it needs to be evaluated if using ID-oriented
   networking protocol with routing will lead to more efficient delivery
   of user IP packets in the edge network compared with 4G edge network
   techniques of tunneling with gateways.

You want the EPC (as well as the capital-I Internet) to not have to distribute and change state when a UE moves. It just can’t scale. And you will not get anything close to good handoff times.


8.  Location Identification Separation and Naming

   With both physical and logical mobility of (an extremely high number
   of) entities and virtualization of network functions the traditional
   usage of IP addresses for identification of name and address or
   logical entity and location as source or destination of data packets

Be careful how you use names in this context. “Names” are human readable strings and are typically used by applications. We should really call a “network layer name” an “ID” or “EID”. Thereby distinguishing the functions of DNS versus a network-based database. They each serve different purposes.

See an enclosed slide for how I describe this in LISP.


   becomes cumbersome.  New approaches to solve the issues are proposed
   in LISP WG in terms of [RFC6830] and ICN RG (see [RFC7476]) but also
   ILNP [RFC6740] and ILA [I-D.herbert-nvo3-ila] address this challenge.

   By separating a Routing LOCator (RLOC) from a unique Identity (EID)
   LISP keeps a single address to each session endpoint even in multi-
   homing but requires new mapping mechanisms at borders to the

It doesn’t matter WHERE the mapping is. The mechanisms (all of them) require a mapping function. Even if they are not map-n-encap proposals.


   Internet.  ILNP (and ILNP-based ILA) do neither tunneling and
   encapsulation nor require changes in higher layers (except the

In this context, you make it sound like tunneling and encapsulation are two different things. Is that what you intended?


   transport layer) re-using part of an (IPv6) Address as Identifier and
   Locator.

   LISP has two forms of split EID/RLOC collocated in same entity: EID
   mobile, RLOC static.  Predictive RLOCs can be used if LISP entity

Cite the predictive-rloc draft.

RLOC can be dynamic too. Like a LISP xTR on a cable router where the RLOC is reassigned by the serivce provider the router connects to.


   knows where the user going so that the system can mitigate mobility
   impacts.  LISP can be used between the Serving and Packet data
   Gateways.  Best solution is to keep LISP close to the moving entity
   with the functions as close to the edge as possible.

   ILNP defines minimal changes on IPv4 and IPv6, it requires changes on

ILNP does not work on an IPv4 host. It is an IPv6 only solution, as it is spec’ed right now. Also true for ILA. There aren’t even bits (and motivation) to split up a 32-bit address into ID and Location parts.


   the domain name system and the transport layer [RFC6740].  ILNP does
   not require any changes on the routing system or LTE core network.

Both ILNP and ILA require the routing system to route to the translated address. Just like RLOCs must be in the routing system. So it is a wash IMO.


   LISP requires routing system changes, it is implemented on the
   routers, possibly on the edge routers.  That means LISP requires
   changes on LTE core network.  ILNP does not use encapsulation so it
   is light weight.  LISP is UDP encapsulated so in IPv6, LISP messages
   incur 52 bytes of overhead.

This document should make it clear that if you are discussing ILNP and ILA and you want to use it for a host-based solution, then say so clearly. Because ILNP do have network proxies. And I’m not sure if ILA can do network proxies (or if Tom even wants to do it). And the document should make it clear, that if you are discussing LISP you want to use it as a router-based solution.

Because you are not just comparing a host versus router solution but AT THE SAME time a translation versus encapsulation. So to summarize:

o ILA is a host-based solution that uses translation.
o ILNP is a host or router based solution that uses translation.
o LISP is a host or router based solution that uses encapsulation.

And note above, we are talking about the data-plane only. And as I said, defining one control-plane could be used for all 5 combinations above.


   ILNP nodes send Locator Update messages which are ICMPv4/v6 message
   to its correspondent nodes when its Locator value changes during an
   active session.  Correspondent node could be a fixed node such as
   Google server which means ILNP has to be implemented by the fixed
   nodes as well.

   ILA is a major update to ILNP [I-D.herbert-nvo3-ila].  It is

And a good one. It decouples itself from any one control-plane and deals with not needing DNS since it has the SIR prefix.

To make things simpler and to have less combinations to consider, I would suggest talking solely about ILA and LISP. And more importantly, how one can be used without the other, or both at the same time. That is, ILA can be used to save header space, and LISP may be needed to run IPv6 over some IPv4 infrastructure.

And I can see a situation where ILA may run OVER LISP. That is ILA IPv6 end-to-end but LISP in the middle. So you have the complementary solution that is host-based and network-based. ILA could do host multi-homing and LISP could do ISP network-based multihoming.


   originally designed for network virtualization to be used in cloud
   networks.  ILA can encode a virtual network identifier (VNID) and
   virtual address as an ILNP identifier.  ILA can be adopted for
   mobility and it can be applied to LTE network, the result can be
   called mobile-ILA.  This effort is undergoing.  These aspects of ILA
   are described in [I-D.mueller-ila-mobility].

So can LISP. So I suggest you do full disclosure. ;-)


   Problem statement on the need for ID-oriented networking protocol,
   exploiting LISP, ILNP and ILA efforts.

I think the document should be stronger and say whatever needs to be done to ILA and LISP to make it work for 5G should be done in their respective working groups (and intentionally leave out ILNP since it is so similar to ILA).

Thanks,
Dino

<PastedGraphic-4.png>

[cid:[e-mail]0EF10]