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

[Dino Farinacci <[e-mail]>]

Cross posting to this list.

Dino

> On Sep 20, 2016, at 9:15 AM, Dino Farinacci <[e-mail]> wrote:
> 
> Copying the list.
> 
> Dino
> 
>> On Sep 20, 2016, at 8:10 AM, Behcet Sarikaya <[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]> 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>