Subject: Re: [lisp] I-D ACTION:draft-ietf-lisp-introduction-04.txt

From: "Victor Moreno (vimoreno)" <[email-masked]>
Date: Fri, 1 Aug 2014 21:30:48 +0000

Hi Alberto, Damien,

A few suggestions for the intro doc:

Overview/Basic Approach (currently 6 and 6.1):
- Not in the current text: Spell out very clearly and upfront the concept of *separation* of location and identity.
- With the concept of location/identity separation clear, then proceed to introduce RLOCs and EIDs as manifestations of such concepts.
- Highlight that these are not mandatorily IP addresses (could be almost anything).
- Build upon this to introduce the notion of RLOCs and EIDs as forming two distinct address spaces
- Finally introduce LISP as the mechanisms to handle the mappings that correlate the two address spaces. May be a good segway into the Basic functionality section that follows.

Basic Functionality (6.2):
- I think it is worth adding to this section the notion of the destination based policies manifested as priorities and weights. Since this is an architectural doc, we may want to abstract this policy notion enough to accommodate other/future policy options that may arise.
- The pull nature of the mechanism is introduced in 6.3 currently. I think this is an important attribute and may be worth considering bringing it forward to 6.2.

Initial Applications (7):
- Fully agree that the section needs to be moved back if we keep it.
- Most use cases will probably fall out of charter at this point, making this section very short until a future re-charter allows more use cases. IMO we need text to allow for those future use cases that are currently out of charter without having to re-open this architecture document. One option is to keep the text on the use cases that is currently in the document. Another option is to include general text to allow future use cases. The latter may be required regardless.
- IMO, just keep the use cases in any order.

8.2. Regarding EID-block vs. prefix. I kind of like EID-block in support of the AF agnostic characteristics of LISP. Prefixes (I think) are tightly coupled with IP, once we have MAC addresses or other addresses prefix may not be the best choice.

10.  Part II

   {{comment from editors: is that the role of an introductory document
   to enter in such level of details and discuss (mostly) all fields of
   the protocol? }}

IMO not in detail and we should probably be a bit more selective in terms of which fields we do discuss in this doc vs. which we do not. Thus outlining the moving parts, at a high level,  and providing references to the documentation with the relevant details may be helpful to those starting with LISP. In general, this second part should be much more succinct in my opinion.

Regarding any other “Suggestions by editors", I agree with all the editor suggestions in version 04 with any comments/exceptions noted above.

Thanks for moving this forward.

Regards,

-v

On Jul 28, 2014, at 1:28 PM, Albert Cabellos <[email-masked]<mailto:[email-masked]>> wrote:

Fabio,

Please see below:

On Fri, Jul 25, 2014 at 10:21 PM, Fabio Maino <[email-masked]<mailto:[email-masked]>> wrote:
Albert, Damien,
please find my comments below.

Network Working Group                         A. Cabellos-Aparicio (Ed.)
Internet-Draft                         Technical University of Catalonia
Intended status: Informational                           D. Saucez (Ed.)
Expires: January 17, 2015                                          INRIA
                                                            July 16, 2014

       An Architectural Introduction to the LISP Location-Identity
                            Separation System
                   draft-ietf-lisp-introduction-04.txt

Abstract

    This document is an introductory overview of the Locator/ID
    Separation Protocol, it describes the major concepts and functional
    sub-systems of LISP and the interactions between them.

Status of This Memo

    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is athttp://datatracker.ietf.org/drafts/current/<http://datatracker.ietf.org/drafts/current/>.

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

    This Internet-Draft will expire on January 17, 2015.

Copyright Notice

    Copyright (c) 2014 IETF Trust and the persons identified as the
    document authors.  All rights reserved.

    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
    carefully, as they describe your rights and restrictions with respect
    to this document.  Code Components extracted from this document must
    include Simplified BSD License text as described in Section 4.e of
    the Trust Legal Provisions and are provided without warranty as
    described in the Simplified BSD License.

Cabellos-Aparicio (Ed.) Expires January 17, 2015                [Page 1]

Internet-Draft              LISP Introduction                  July 2014

Table of Contents

    1.  Prefatory Note  . . . . . . . . . . . . . . . . . . . . . . .   4
    2.  Part I  . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
    3.  Initial Glossary  . . . . . . . . . . . . . . . . . . . . . .   5
    4.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   6
    5.  Deployment Philosophy . . . . . . . . . . . . . . . . . . . .   7
      5.1.  Economics . . . . . . . . . . . . . . . . . . . . . . . .   7
      5.2.  Maximize Re-use of Existing Mechanism . . . . . . . . . .   8
    6.  LISP Overview . . . . . . . . . . . . . . . . . . . . . . . .   8
      6.1.  Basic Approach  . . . . . . . . . . . . . . . . . . . . .   9
      6.2.  Basic Functionality . . . . . . . . . . . . . . . . . . .   9
      6.3.  Mapping from EIDs to RLOCs  . . . . . . . . . . . . . . .  11
      6.4.  Interworking With Non-LISP-Capable Endpoints  . . . . . .  11
      6.5.  Security in LISP  . . . . . . . . . . . . . . . . . . . .  12
    7.  Initial Applications  . . . . . . . . . . . . . . . . . . . .  13
      7.1.  Provider Independence . . . . . . . . . . . . . . . . . .  13
      7.2.  Multi-Homing  . . . . . . . . . . . . . . . . . . . . . .  13
      7.3.  Traffic Engineering . . . . . . . . . . . . . . . . . . .  14
      7.4.  Routing . . . . . . . . . . . . . . . . . . . . . . . . .  15
      7.5.  Mobility  . . . . . . . . . . . . . . . . . . . . . . . .  15
      7.6.  Traversal Across Alternate IP Versions  . . . . . . . . .  15
      7.7.  Virtual Private Networks  . . . . . . . . . . . . . . . .  16
      7.8.  Local Uses  . . . . . . . . . . . . . . . . . . . . . . .  16
    8.  Major Functional Subsystems . . . . . . . . . . . . . . . . .  17
      8.1.  Data Plane - xTRs Overview  . . . . . . . . . . . . . . .  17
        8.1.1.  Mapping Cache Performance . . . . . . . . . . . . . .  18
      8.2.  Control Plane - Mapping System Overview . . . . . . . . .  18
        8.2.1.  Mapping System Organization . . . . . . . . . . . . .  19
        8.2.2.  Interface to the Mapping System . . . . . . . . . . .  20
        8.2.3.  Indexing Sub-system . . . . . . . . . . . . . . . . .  20
    9.  Examples of operation . . . . . . . . . . . . . . . . . . . .  22
      9.1.  An Ordinary Packet's Processing . . . . . . . . . . . . .  22
      9.2.  A Mapping Cache Miss  . . . . . . . . . . . . . . . . . .  23
    10. Part II . . . . . . . . . . . . . . . . . . . . . . . . . . .  24
    11. Design Approach . . . . . . . . . . . . . . . . . . . . . . .  24
    12. xTRs  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  25
      12.1.  When to Encapsulate  . . . . . . . . . . . . . . . . . .  25
      12.2.  UDP Encapsulation Details  . . . . . . . . . . . . . . .  26
      12.3.  Header Control Channel . . . . . . . . . . . . . . . . .  26
        12.3.1.  Mapping Versioning . . . . . . . . . . . . . . . . .  26
        12.3.2.  Echo Nonces  . . . . . . . . . . . . . . . . . . . .  27
        12.3.3.  Instances  . . . . . . . . . . . . . . . . . . . . .  27
      12.4.  Probing  . . . . . . . . . . . . . . . . . . . . . . . .  28
      12.5.  Mapping Lifetimes and Timeouts . . . . . . . . . . . . .  28
      12.6.  Mapping Gleaning in ETRs . . . . . . . . . . . . . . . .  29
      12.7.  MTU Issues . . . . . . . . . . . . . . . . . . . . . . .  29
      12.8.  Security of Mapping Lookups  . . . . . . . . . . . . . .  29

Cabellos-Aparicio (Ed.) Expires January 17, 2015                [Page 2]

Internet-Draft              LISP Introduction                  July 2014

      12.9.  ITR Mapping Cache Performance  . . . . . . . . . . . . .  30
    13. The Mapping System  . . . . . . . . . . . . . . . . . . . . .  31
      13.1.  The Mapping System Interface . . . . . . . . . . . . . .  32
        13.1.1.  Map-Request Messages . . . . . . . . . . . . . . . .  32
        13.1.2.  Map-Reply Messages . . . . . . . . . . . . . . . . .  32
        13.1.3.  Map-Register and Map-Notify Messages . . . . . . . .  33
      13.2.  The DDT Indexing Sub-system  . . . . . . . . . . . . . .  34
      13.3.  Reliability via Replication  . . . . . . . . . . . . . .  35
      13.4.  Security of the DDT Indexing Sub-system  . . . . . . . .  35
      13.5.  Extended Capabilities  . . . . . . . . . . . . . . . . .  36
      13.6.  Performance of the Mapping System  . . . . . . . . . . .  36
    14. Multicast Support in LISP . . . . . . . . . . . . . . . . . .  37
      14.1.  Basic Concepts of Multicast Support in LISP  . . . . . .  37
      14.2.  Initial Multicast Support in LISP  . . . . . . . . . . .  38
    15. Deployment Issues and Mechanisms  . . . . . . . . . . . . . .  39
      15.1.  LISP Deployment Needs  . . . . . . . . . . . . . . . . .  39
      15.2.  Interworking Mechanisms  . . . . . . . . . . . . . . . .  40
        15.2.1.  Proxy LISP Routers . . . . . . . . . . . . . . . . .  40
        15.2.2.  LISP-NAT . . . . . . . . . . . . . . . . . . . . . .  42
      15.3.  Use Through NAT Devices  . . . . . . . . . . . . . . . .  42
      15.4.  LISP and Core Internet Routing . . . . . . . . . . . . .  43
    16. Fault Discovery/Handling  . . . . . . . . . . . . . . . . . .  43
      16.1.  Handling Missing Mappings  . . . . . . . . . . . . . . .  44
      16.2.  Outdated Mappings  . . . . . . . . . . . . . . . . . . .  44
        16.2.1.  Outdated Mappings - Updated Mapping  . . . . . . . .  44
        16.2.2.  Outdated Mappings - Wrong ETR  . . . . . . . . . . .  44
        16.2.3.  Outdated Mappings - No Longer an ETR . . . . . . . .  45
      16.3.  Erroneous Mappings . . . . . . . . . . . . . . . . . . .  45
      16.4.  Verifying ETR Liveness . . . . . . . . . . . . . . . . .  45
      16.5.  Verifying ETR Reachability . . . . . . . . . . . . . . .  46
    17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  46
    18. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  47
    19. Security Considerations . . . . . . . . . . . . . . . . . . .  47
    20. References  . . . . . . . . . . . . . . . . . . . . . . . . .  47
      20.1.  Normative References . . . . . . . . . . . . . . . . . .  47
      20.2.  Informative References . . . . . . . . . . . . . . . . .  49
    Appendix A.  Glossary/Definition of Terms . . . . . . . . . . . .  52
    Appendix B.  Other Appendices . . . . . . . . . . . . . . . . . .  55
      B.1.   A Brief History of Location/Identity Separation  . . . .  55
      B.2.  A Brief History of the LISP Project . . . . . . . . . . .  56
      B.3.  Old LISP 'Models' . . . . . . . . . . . . . . . . . . . .  56
      B.4.  The ALT Mapping Indexing Sub-system . . . . . . . . . . .  57
      B.5.  Early NAT Support . . . . . . . . . . . . . . . . . . . .  58
    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  59

Cabellos-Aparicio (Ed.) Expires January 17, 2015                [Page 3]

Internet-Draft              LISP Introduction                  July 2014

1.  Prefatory Note

    {{Suggestion by editors: Remove all the sections before "LISP
    Overview" and write a straight-to-the-point introduction}}

    {{Suggestion by editors: The draft should focus on describing the
    LISP architecture and avoid comparing loc/id split architectures with
    other approaches}}

Agree: my suggestion is to view this as a doc for a reader new to LISP that needs to be introduced to the architecture. At the end of the doc the reader will be familiar with the basic aspects of LISP, and able to navigate through the RFCs. The document should be kept as short and as "dry" as possible. If the reader wants to know more, after reading this doc, he will know where to go for the details.

    This document is the first of a pair which, together, form what one
    would think of as the 'architecture document' for LISP (the
    'Location-Identity Separation Protocol').  Much of what would
    normally be in an architecture document (e.g. the architectural
    design principles used in LISP, and the design considerations behind
    various components and aspects of the LISP system) is in the second
    document, the 'Architectural Perspective on LISP' document.
    [I-D.ietf-lisp-perspective]

    This 'Architectural Introduction' document is primarily intended for
    those who are unfamiliar with LISP, and want to start learning about
    it.  It is intended primarily for those working on LISP, but those
    working with LISP, and more generally anyone who wants to know more
    about LISP, may also find this document useful.

    This document is intended to both be easy to follow and it is
    structured as a series of phases, each covering the entire system,
    but with ever-increasing detail.  Reading only the first part of the
    document will give a good high-level view of the system; reading the
    complete document should provide a fairly detailed understanding of
    the entire system.

    People who just want to get an idea of how LISP works might only read
    the first part; they can stop reading either just before, or just
    after Section 9.  People who are going to go on and read the protocol
    specifications (perhaps to implement LISP) should read the entire
    document.

    This document is a descriptive document, not a protocol
    specification.  Should it differ in any detail from any of the LISP
    protocol specification documents, they take precedence for the actual
    operation of the protocol.

2.  Part I

Cabellos-Aparicio (Ed.) Expires January 17, 2015                [Page 4]

Internet-Draft              LISP Introduction                  July 2014

3.  Initial Glossary

let's stick to the RFCs glossary. Since this is a first-to-read doc there should be a minimal definition section, but definitions should mostly be cut and paste from the RFCs.

Agree, this will make easier to read the rest of the RFCs.

    This initial glossary defines a few general terms which will be
    useful to have in hand when commencing reading this document.  A
    complete glossary is available in Appendix A.

    A note about style: initial usage of a term defined in the glossary
    is denoted with double quotation marks (").  Other uses of quotations
    (e.g. for quotations, euphemisms, etc) use single quotation marks
    (').

    o  Name: a name refers to an identifier for an object or entity.
       Names have both semantics (meaning) and syntax (form) [RFC1498].

    o  Namespace: A group of names with matching semantics and syntax;
       they usually, but not always, refer to members of a class of
       identical objects.

    o  Mapping: a binding between two names, one in each of two
       namespaces.

    o  Delegation Hierarchy: an abstract rooted tree (in the graph theory
       sense of the term) which is a virtual representation of the
       delegation of a namespace into smaller and smaller blocks, in a
       recursive process.

    o  Node: The general term used to describe any sort of communicating
       entity; it might be a physical or a virtual host, or a mobile
       device of some sort.  It includes both entities which forward
       packets, and entities which create or consume packets.

    o  Switch, Packet Switch: A packet switch, in the general meaning of
       that term.  A device which takes in packets from its interfaces
       and forwards them on, either to a next-hop switch, or to the final
       destination.  They may operate at either the network layer (e.g.
       ARPANET), or internetwork layer.  [Baran][Heart][RFC1812]

    o  Endpoint, end-end communication entity: The fate-sharing region at
       one end of an end-end communication; the collection of state
       related to both the reliable end-end communication channel, and
       the applications running there.  [Chiappa]

    o  Address: In this document, in current IP (IPv4 or IPv6) and
       similar networking suites, a "name" which has mixed semantics, in
       that it includes both identity ('who') and location ('where')
       semantics.  [Atkinson]

Cabellos-Aparicio (Ed.) Expires January 17, 2015                [Page 5]

Internet-Draft              LISP Introduction                  July 2014

    o  Address Block, Block: A contiguous section of a namespace (e.g.,
       IP addresses that belong to the same prefix).

    o  Identifier: a name which has identity semantics.

    o  Locator: name with only location semantics and not necessarily
       carried in every packet [RFC1992].

    o  Site: A collection of hosts, routers, and networks under a single
       administrative control.

    o  LISP site: a site separated from the rest of the network by LISP
       routers.

    o  LISP node: A network element implementing LISP functionality; this
       means it can process some subset of LISP control and planes
       traffic.

    o  LISP router: A network element implementing LISP data-plane
       functionality, i.e., a LISP node which can forward user traffic.

    o  LISP host: A host which is behind (from the point of view of the
       rest of the network) a LISP router.

4.  Background

    It has gradually been realized in the networking community that
    networks, especially large networks, should deal quite separately
    with the identity and location of an endpoint - basically, who an
    endpoint is, and where it is ([RFC1498] [RFC4984]).

    At the moment of this writing, in both IPv4 and IPv6, IP addresses
    indicate both where the named node is, as well as identify it for
    purposes of end-end communication; i.e. it has both location and
    identity properties.  However, the separation of those two properties
    is a step which has been identified by the IRTF as a necessary
    evolutionary architectural step for the Internet [RFC6115] and the
    on-going LISP project is an attempt to provide a viable path towards
    this separation.

    As an add-on to a large existing system, it has had to make certain
    compromises.  (For a good example, see [I-D.ietf-lisp-perspective],
    Section "Residual Location Functionality in EIDs".  However, if it
    reaches near-ubiquitous deployment, it will have two important
    consequences.

    First, in effectively providing separation of location and identity,
    along with providing a distributed directory of the mappings between

Cabellos-Aparicio (Ed.) Expires January 17, 2015                [Page 6]

Internet-Draft              LISP Introduction                  July 2014

    them, 'Wheeler's Law' ('All problems in computer science can be
    solved by another level of indirection') will come into play, and the
    Internet technical community will have a new, immensely powerful,
    tool at its disposal.  The fact that the namespaces on both sides of
    the mapping are global ones maximizes the power of that tool.  (See
    [I-D.ietf-lisp-perspective], Section "Need for a Mapping System", for
    more on this.)

    Second, because of a combination of the flexible capability built
    into LISP, and the breaking of the unification of location and
    identity names, further architectural evolution of the Internet
    becomes easily available; for example, new namespaces for location or
    identity could be designed and deployed.  In other words, LISP is not
    a point solution to meet a particular need, but hopefully an 'escape
    hatch' which will allow further significant enhancement to the
    Internet's overall architecture.  (See [Future] for more on this.)

5.  Deployment Philosophy

    {{Suggestion by editors: Remove the entire section, it can be
    summarized by the last paragraph.  Furthermore the arguments used in
    this sections are hard to follow since LISP has not been described
    yet.}}

    The deployment philosophy was a major driver for the design of LISP
    (architecture and engineering).

    Experience over the last several decades has shown that having a
    viable deployment model for a new design is a key to the adoption of
    the solution.  In general, it is comparatively easy to conceive of
    new network designs, but much harder to devise approaches which will
    actually get deployed throughout the global network.  A new design
    may be fantastic but if it can not be successfully deployed (for
    whatever factors), it is useless.

    LISP aims to achieve the near-ubiquitous deployment necessary for
    maximum exploitation of an architectural upgrade by i) minimizing the
    amount of change needed (most existing hosts and routers can operate
    unmodified); and ii) by providing significant benefits to early
    adopters.

5.1.  Economics

    {{Suggestion by editors: Remove this section, this has not been
    discussed by the WG}}

    A key factor in successful adoption is economics: does the new design
    have benefits which outweigh its costs?

Cabellos-Aparicio (Ed.) Expires January 17, 2015                [Page 7]

Internet-Draft              LISP Introduction                  July 2014

    More importantly, this balance needs to hold for early adopters -
    because if they do not receive benefits to their adoption, the sphere
    of earliest adopters will not expand, and it will never get to
    widespread deployment.

    This is particularly true of architectural enhancements, which are
    far less likely to be an addition which one can bolt onto the side of
    existing mechanisms, and often offer their greatest benefits only
    when widely (or ubiquitously) deployed.

    Maximizing the cost-benefit ratio obviously has two aspects.  First,
    on the cost side, by making the design as inexpensive as possible,
    which means in part making the deployment as easy as possible.
    Second, on the benefit side, by providing many new capabilities,
    which is best done not by loading the design up with lots of features
    or options (which adds complexity), but by making the addition
    powerful through deeper flexibility.  The LISP community believes
    LISP has met both of these goals.

5.2.  Maximize Re-use of Existing Mechanism

    {{Suggestion by editors: Remove/Summarize the entire section, the
    arguments used in this section are hard to follow since LISP has not
    been described yet.}}

Remove. This doc is not a guide to good protocol design. The concept that LISP is deployable incrementally should be mentioned in the document though, possibly with a reference to the deployment RFC.

Agreed, we´ll include an (ultra-short) section describing the design principles of LISP, incremental deployment is of course one of them.

    One key part of reducing the cost of a new design is to minimize the
    amount of change required to existing, deployed, devices: the fewer
    devices need to be changed, and the smaller the change to those that
    do, the greater the likelihood of deployment.

    Designs which absolutely require forklift upgrades to large amounts
    of existing gear are far less likely to succeed - because they have
    to have extremely large benefits to make their very substantial costs
    worthwhile.

    It is for this reason that LISP, in most cases, initially requires no
    changes to almost all existing devices in the Internet (both hosts
    and routers); LISP functionality needs to be added in only a few
    places ( Section 15.1)

6.  LISP Overview

    LISP is an incrementally deployable architectural upgrade to the
    existing Internet infrastructure, one which provides separation of
    location and identity.  It thus starts to separate the names used for
    identity and location of nodes, which are currently unified in IP
    addresses.

Cabellos-Aparicio (Ed.) Expires January 17, 2015                [Page 8]

Internet-Draft              LISP Introduction                  July 2014

6.1.  Basic Approach

    {{Suggestion by editors: Merge this section with the previous one
    (LISP Overview)}}

Agree: across the document, as done in the RFCs, I'd suggest to focus on describing the protocol architecture and how it works rather than on more generic considerations about the LISP philosophy.

    In LISP, the first key concept is that nodes have both an identifier
    called an Endpoint IDentifier (EID) and an associated Routing Locator
    (RLOC).  A node may be associated with more than one RLOC, or the
    RLOC may change over time (e.g., if the node is mobile), but it would
    normally always have the same EID.

    The second key concept is that if one wants to be as forward-looking
    as possible, conceptually one should think of the two kinds of names
    (EIDs and RLOCs) as naming different classes of entities.

    On the one hand, EIDs are used to name nodes - or rather, their end-
    end communication entities.  RLOC(s), on the other hand, name
    interfaces, i.e. places to which the system of routers sends packets.

    This distinction, the formal recognition of different kinds of
    entities ("endpoints" and interfaces), and their association with the
    two different classes of names, is also important.  Clearly
    recognizing interfaces and endpoints as distinctly separate classes
    of objects is another improvement to the existing Internet
    architecture.

    An important insight in LISP is that it initially uses existing IP
    addresses for both of these kinds of names, as opposed to some
    similar earlier deployment proposals for separation of location and
    identity (e.g.  [RFC1992]), which proposed using a new namespace for
    locators.  This choice minimizes LISP's deployment cost, as well as
    providing the ability to easily interact with un-modified hosts and
    routers.

    The capability to use namespaces other than IP addresses for both
    kinds of names is already built in LISP, which is expected to greatly
    increase the long-term benefits, flexibility, and power of LISP
    ([AFI], [I-D.ietf-lisp-lcaf]).

6.2.  Basic Functionality

    {{Suggestion by editors: Rewrite this section: It is using non-
    standard terminology to refer to standard LISP concepts ('enhance'
    instead of encapsulate) It is using subjective terms (e.g., 'near'
    the source) It is missing key LISP aspects such as that RLOC packets
    are forwarded in the RLOC space }}

Make sure a figure with the basic elements of the protocol architecture (possibly similar to figure 1) is introduced as early as possible.

Cabellos-Aparicio (Ed.) Expires January 17, 2015                [Page 9]

Internet-Draft              LISP Introduction                  July 2014

    The basic operation of LISP, as it currently stands, is quite simple.
    LISP augmented packet switches, "LISP routers", near the source and
    destination of packets intercept traffic, and 'enhance' the packets
    for the trip between the LISP switches.

    The LISP router near the original source (the Ingress Tunnel Router,
    or ITR ) looks up additional information about the destination of the
    packet, and then wraps the packet in an outer header, one which
    contains additional information related to LISP operation.

    The LISP router near the destination, the (the Egress Tunnel Router,
    or ETR) removes that header, leaving the original, un-modified,
    packet to be sent on to the original destination node.

    The overall processing is shown below, in Figure 1:

     /-----------------\                       ---
     |     Mapping     |                        |
     .     System      |                        |  Control
    -|                 |`,                      |  Plane
  ,' \-----------------/  .                     |
                      /                         \                   ---
     ,..,           -        _,..--..,,         `,         ,..,      |
   /     `        ,'      ,-`          `',        .      /     `     |
  /        \ +-----+    ,'                `,    +--'--+ /        \   |
  |  EID   |-| xTR |---/        RLOC        ,---| xTR |-|  EID   |   |  Data
  | Space  |-|     |---|       Space        |---|     |-| Space  |   |  Plane
  \        / +-----+   .                   /    +-----+ \        /   |
   `.    .'             `.                ,'             `.    .'    |
     `'-`                 `.,          ,.'                 `'-`     ---
                             ``''--''``
   LISP Site (Edge)            Core              LISP Site (Edge)

                   Figure.- An schema of the LISP Architecture

                      Figure 1: Basic LISP Packet Flow

    To retrieve that additional information, the ITR uses the information
    in the original packet about the identity of its ultimate
    destination, i.e. the destination EID address.  It uses the
    destination EID to look up the current location (the RLOC) of that
    EID.

    The lookup is performed through a mapping system, which is the heart
    of LISP: it is a distributed directory of mappings from EIDs to

Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 10]

Internet-Draft              LISP Introduction                  July 2014

    RLOCs.  The destination RLOC(s) is (are) normally the address(es) of
    the ETR(s) near the ultimate destination.

    The ITR then generates a new outer header for the original packet,
    with that header containing the ETR's RLOC as the wrapped packet's
    destination, and the ITR's own address (i.e. the RLOC usually
    associated with the original source) as the wrapped packet's source,
    and sends it off.

    When the packet arrives at the ETR, that outer header is stripped
    off, and the original packet is forwarded to the original ultimate
    destination for normal processing.

    Return traffic is handled similarly, often (depending on the
    network's configuration) with the original ITR and ETR switching
    roles.  The ETR and ITR functionality is usually co-located in a
    single LISP router; these are normally denominated as xTRs.

6.3.  Mapping from EIDs to RLOCs

    The mappings from EIDs to RLOCs are provided by a distributed, and
    potentially replicated, database, the "mapping database", which is
    the heart of LISP.  Here, and in other places in LISP, the
    replication is not a deep architectural concept, simply an
    engineering device to obtain reliability via potential redundancy.

    Entities which need EID-to-RLOC mappings get them from the mapping
    system, which is a collection of sub-systems through which clients
    can find and obtain mappings as discussed in more details in
    Section 8.2 and Section 13.

    Mappings are normally distributed via a pull mechanism (i.e., not
    pre-loaded, but requested on demand).  Once obtained by an ITR, they
    are cached for performance reasons.

6.4.  Interworking With Non-LISP-Capable Endpoints

    It is clearly crucial to provide the capability for easy
    interoperation between "LISP hosts" - i.e. they are behind xTRs, and
    their EIDs are in the mapping database - and existing non-LISP-using
    hosts (often called 'legacy' hosts) or legacy "sites".

    To allow interoperation between devices hosted in a LISP site and
    devices not belonging to a LISP site (non-LISP site), an interworking
    mechanism based on proxies has been designed.  Proxy ITRs (PITR)
    encapsulate packets sent from non-LISP sites to LISP sites while
    Proxy ETRs (PETR) decapsulate packets sent from LISP sites to non-
    LISP sites.  More details are given in Section 15.2.1.

Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 11]

Internet-Draft              LISP Introduction                  July 2014

6.5.  Security in LISP

    {{Suggestion by editors: Rewrite this section: (first 3 paragraphs)
    It contains a general discussion as well as strong statements that
    are not supported by any WG document.  (last 3 paragraphs) It
    enumerates the security mechanisms specified in LISP but does not
    describe them.}}

Agree. I think that the security considerations section of RFC6830 may provide a guide to the items you may want to touch in this document. Point the reader to the RFCs when possible. Move broader security considerations to the Security Section referencing lisp-threats where needed.

Agreed.

    To provide a brief overview of security in LISP, it is definitely
    understood that LISP needs to be highly _securable_, especially in
    the long term; over time, the attacks mounted by 'bad guys' are
    becoming more and more sophisticated.  So LISP, like DNS, needs to be
    _capable_ of providing 'the very best' security there is.

    At the same time, there is a conflicting goal: it must be deployable
    at a a viable cost.  That means two things: First, as an experiment,
    we cannot expect to create the complete security apparatus which we
    might see in the finished product, including both design and
    implementation.  Second, security needs to be flexible, so that we
    don't overload the users with more security than they need at any
    point.

    To accomplish these divergent goals, the approach taken is to first
    analyze what LISP needs for security.  [I-D.ietf-lisp-threats].
    Then, steps can be taken to ensure that the appropriate 'hooks' (such
    as packet fields) are included at an early stage, when doing so is
    still easy.  Over time, additional mechanisms will be fully
    specified, implemented, and deployed.

    LISP does already include a number of security mechanisms; in
    particular, requesting mappings can be secured (see Section 12.8,
    "Security of Mapping Lookups"), as can registering of xTRs (see
    Section 13.1.3, "Map-Register and Map-Notify Messages"); the key
    database of the mapping system is also secured (see Section 13.4,
    "Security of the DDT Indexing Sub-system").

    The existing security mechanisms, and their configuration (which is
    mostly manual at this point) currently in LISP are felt to be
    adequate for the needs of the on-going early stages of deployment;
    experience will indicate when improvements are required (within the
    constraints of the conflicting goal given above).

    For more on LISP's security philosophy; see
    [I-D.ietf-lisp-perspective], Section 7 "Security", where it is laid
    out in some detail.

Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 12]

Internet-Draft              LISP Introduction                  July 2014

7.  Initial Applications

    {{Suggested by editors: Move this section after section 8, the
    applications should not be described before LISP has been fully
    described.

    {{Suggested by Noel: Reorder the whole section in popularity order?}}

    As previously mentioned, it is felt that LISP will provide even the
    earliest adopters with some useful capabilities, and that these
    capabilities will drive early LISP deployment.

    It is very imporant to note that even when used only for
    interoperation with existing un-modified hosts, use of LISP can still
    provide benefits to the site which has deployed it - and, perhaps
    even more importantly, can do so to both sides.  This characteristic
    acts to further enhance the utility for early adopters of LISP.

    Note also that this section only lists some early applications and
    benefits.  See [I-D.ietf-lisp-perspective], in the Section "Goals of
    LISP", for a more extensive discussion of some of what LISP might
    ultimately provide.

7.1.  Provider Independence

    Provider independence (i.e. the ability to easily change one's
    Internet Service Provider) is a good example of the utility of
    separating location and identity.

    To limit global routing table size addresses need to be aggregated.
    To that aim networks can use provider aggregatable addresses
    ([RFC4116]) which means that the IP prefixes of networks are sub-
    prefixes of their provider.  This solutions allows to reduce
    scalability issues of the global routing table but it means that when
    a network switches providers it has to re-number all its devices
    which is known to be complex in current networks [RFC5887].

    Having separate namespaces for location and identity greatly reduces
    the problems involved with re-numbering; an organization which moves
    retains its EIDs (which are how most other parties refer to its
    nodes), but is allocated new RLOCs, and the mapping system can
    quickly provide the updated mapping from the EIDs to the new RLOCs.

7.2.  Multi-Homing

    {{Suggested by editors: This section should be extended, it is
    unclear the benefits that LISP brings to multihoming (.e.g, traffic
    engineering, decoupled multihoming from the data-plane).

Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 13]

Internet-Draft              LISP Introduction                  July 2014

    Multi-homing is another place where the value of separation of
    location and identity became apparent.  There are several different
    sub-flavours of the multi-homing problem - e.g. depending on whether
    one wants open TCP connections to keep working, etc - and other axes
    as well (e.g. site multi-homing versus host multi-homing).

    In particular, for the 'keep open connections up' case, without
    separation of location and identity, with most currently deployed
    implementations, the only currently feasible approach is to use
    provider-independent addressses - which moves the problem into the
    global routing system, with attendant costs.  This approach is also
    not really feasible for host multi-homing.

7.3.  Traffic Engineering

    {{Suggestion by editors: Merge this section with the previous one, TE
    is not practical without multihoming}}

    {{Needs a fix - not sure what.}}

    Traffic engineering (TE) [RFC3272], desirable though this capability
    is in a global network, is currently somewhat problematic to provide
    in the Internet.  The problem, fundamentally, is that this capability
    was not forseen when the Internet was designed, so the support for it
    via hacks is neither clean, nor flexible.

    TE is, fundamentally, a routing issue.  However, the current Internet
    routing architecture, which is basically the Baran design of fifty
    years ago [Baran] (a single large, distributed computation), is ill-
    suited to provide TE.  The Internet seems a long way from adopting a
    more-advanced routing architecture, although the basic concepts for
    such have been known for some time.  [RFC1992]

    Although the identity-location mapping layer is thus a poor place,
    architecturally, to provide TE capabilities, it is still an
    improvement over the current routing tools available for this purpose
    (e.g. injection of more-specific routes into the global routing
    table).

    In addition, instead of the entire network incurring the costs
    (through the routing system overhead), when using a mapping layer to
    provide TE, the overhead is limited to those who are actually
    communicating with that particular destination.

    LISP includes a number of features in the mapping system to support
    TE. (described in Section 8.2, "Control Plane - Mapping System
    Overview", below); more details about using LISP for TE can be found
    in [I-D.farinacci-lisp-te].

Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 14]

Internet-Draft              LISP Introduction                  July 2014

    Also, a number of academic papers have explored how LISP can be used
    to do TE, and how effective it can be.  See the online LISP
    Bibliography ([Bibliography]) for information about them.

7.4.  Routing

    {{Suggestion by editors: Remove this section, LISP is not a routing
    protocol.}}

    Multi-homing and Traffic Engineering are both, in some sense, uses of
    LISP for routing, but there are many other routing-related uses for
    LISP.

    One of the major original motivations for the separation of location
    and identity in general, and thus LISP, was to reduce the growth of
    the routing tables in the "Internet core", the part where routes to
    _all_ ultimate destinations must be available.  LISP is expected to
    help with this; for more detail, see Section 15.4, "LISP and Core
    Internet Routing", below.

    LISP may also have more local applications in which it can help with
    routing; see, for instance, [CorasBGP].

7.5.  Mobility

    {{Suggestion by editors: Remove this section, mobility is not in
    charter.}}

    Mobility is yet another place where separation of location and
    identity is a key part of a clean, efficient and high-functionality
    solution.  Considerable experimentation has been completed on doing
    mobility with LISP.

    The mobility provided by LISP allows active sessions to survive moves
    (provided of course that there is not a period of inaccessibility
    which exceeds a timeout).  LISP mobility also will typically have
    better packet stretch (i.e. increase in path length) compared to
    traditional mobility schemes, which use a home agent.

7.6.  Traversal Across Alternate IP Versions

    Note that LISP inherently supports intermixing of various IP versions
    for packet carriage; IPv4 packets might well be carried in IPv6, or
    vice versa, depending on the network's configuration.

    This capability allows an island of operation of one type to be
    automatically tunneled over a stretch of infrastucture which only
    supports the other type.

Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 15]

Internet-Draft              LISP Introduction                  July 2014

7.7.  Virtual Private Networks

    {{Suggestion by editors: Remove this section, not covered by any WG
    document}}

    L2 and L3 {{Need to add text here - This used to be part of 'Local'
    below, but we decided this was so important it deserved its own
    section.  Maybe move this up further, as it seems to be the most
    important 'early adopter' application?}}

    The mapping-and-encapsulation nature of LISP makes it a perfect
    candidate for VPN solutions.  In this case, private parts of the VPN
    form LISP sites and the IP addresses of devices in the private parts
    are composing EID spaces.  The interconnection between the LISP sites
    is the public network and IP addresses in the interconnection compose
    the RLOC space.  A major advantage of using LISP to construct VPN
    resides in the simplicity of the configurations: each xTR (i.e., VPN
    end) is configured to query the mapping system to retrieve mappings
    making the glue between the public (RLOC space) and the private (EID
    space) of the VPN.

    This includes support of multi-tenancy where several private networks
    can be carried over the same underlayer network.  Thanks to the
    instance-id field, multi-tenant network can even use the exact same
    addresses as the xTR distinguishes the tenant based on the value of
    the instance-id.  The multiple address family support in LISP
    mappings also allows to build private networks using a different
    addressing family than the carrier (e.g., IPv6 over IPv4).

7.8.  Local Uses

    {{Suggestion by editors: Remove this section.  The section contains a
    general discussion about the applicability of LISP in intra-domain
    scenarios, however it does not describe any specific application.}}

    LISP has a number of use cases which are within purely
    organizationally-local contexts, i.e. not in the larger Internet.
    These fall into two categories: uses seen on the Internet (above),
    but here on a private (and usually small scale) setting; and
    applications which do not have a direct analog in the larger
    Internet, and which apply only to local deployments.

    Among the former are multi-homing and IP version traversal. {{This
    was marked to be deleted - why?  The next part doesn't make sense
    without this first?}}

    Among the latter class, non-Internet applications which have no
    analog on the Internet, are the following example applications:

Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 16]

Internet-Draft              LISP Introduction                  July 2014

    virtual machine mobility in data centers; non-IP EID types such as L2
    MAC addresses, or application specific data.

    Several of the applications listed in this section are the ones which
    have been most popular for LISP in practise; these include virtual
    networks, and virtual machine mobility.

    These often show a synergistic tendency, in that a site which
    installs LISP to do one, often finds that then becomes a small matter
    to use it for the second.  Given all the things which LISP can do, it
    is hoped that this synergistic effect will continue to expand LISP's
    uses.

    {{Preceeding paragraphs should probably get moved up into VPN
    section?}}

8.  Major Functional Subsystems

    {{Suggestion by editors: This section should appear before since it
    describes key aspects of LISP (e.g., LISP decoupled control and data-
    plane).}}

Yes, possibly where the first figure is.

    LISP has two major functional sub-systems: the xTRs which form the
    data-plane of LISP; and the mapping system which forms the control
    plane that maintains and distributes the mapping database.

    The purpose and operation of each is described at a high level below,
    and then, later on, in a fair amount of detail, in separate sections
    on each (Section 12 and Section 13).

8.1.  Data Plane - xTRs Overview

    {{Suggestion by editors: Extend this section, it misses key LISP
    data-plane aspects, such as the map-cache.}}

    xTRs are routers that have been augmented with extra functionality in
    both the data and control planes.  The data plane functions in ITRs
    include deciding which packets need to be given LISP processing
    (since packets to non-LISP hosts may be sent as they are); i.e.
    looking up the mapping; encapsulating (wrapping) the packet; and
    sending it to the ETR.

    This encapsulation is done using UDP [RFC0768], along with an
    additional outer IP header (to hold the source and destination
    RLOCs).  To the extent that traffic engineering features are in use
    for a particular EID, the ITRs implement them as well.

Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 17]

Internet-Draft              LISP Introduction                  July 2014

    In the ETR, the data plane simply decapsulates (unwraps) the packets,
    and forwards the it to the destination.

    Control plane functions in ITRs include: asking for EID-to-RLOC
    mappings via Map-Request packets; handling the returning reply
    control messages (i.e., Map-Reply packets), which contain the EID-to-
    RLOC mapping; managing the local mapping cache and checking for the
    reachability of destination ETR's RLOCs.

    In the ETR, control plane functions include participating in the
    reachability tests (see Section 16.4); interacting with the mapping
    sub-system to let it know what mapping this ETR can provide (see
    Section 8.2.2); and answering Map-Request packets from ITRs for those
    mappings.

8.1.1.  Mapping Cache Performance

    {{Suggestion by editors: Push this section further in the document,
    the cache performance is not a "Major LISP subsystem"}}

    As mentioned, studies have been performed to verify that caching
    mappings in ITRs is viable, in practical engineering terms.  These
    studies not only verified that such caching is feasible, but also
    provided some insight for designing ITR "mapping caches".

    Briefly, they took lengthy traces of all packets leaving a large
    site, over a period of a week or so, and used those to drive
    simulations which showed how many mappings would be required.  It
    also allowed analysis of how much control traffic (for loading needed
    mappings) would result, using various cache sizes and replacement
    algorithms.  These studies provide an insight into how well LISP can
    be expected to perform, and scale, over time.

    A more extended look at the results us given below, in Section 12.9,
    "xTR Mapping Cache Performance".

8.2.  Control Plane - Mapping System Overview

    {{Suggestion by editors: Rewrite: Replace EID block terminology
    (along with its description) with the very common term "prefix".
    Describe Map-Request/Map-Reply LISP signaling messages.}}

    The mapping system's entire purpose is to give ITRs on-demand access
    to the mapping database, which is a distributed, and potentially
    replicated, database which holds mappings between EIDs (identity) and
    RLOCs (location), along with needed ancillary data (e.g. lifetimes).

Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 18]

Internet-Draft              LISP Introduction                  July 2014

    To be exact, it contains mappings between EID blocks and RLOCs (the
    block size is given explicitly, as part of the syntax).  Support for
    blocks is both for minimizing the administrative configuration
    overhead, as well as for operational efficiency; e.g. when a group of
    EIDs are behind a single xTR.  In IP blocks are delimited by their IP
    prefix.

    However, the block may be, and sometimes is, as small as a single
    EID.  However, since mappings are only loaded upon demand, if smaller
    blocks become predominant, then the increased size of the overall
    database is far less problematic than if the Internet's routing
    tables came to be dominated by such small entries.

    A particular EID (or EID block) may be associated to than one RLOC,
    and may change the association with time.

    Also, in general, throughout LISP, the address family of EIDs and
    RLOCs is explicitly mentioned in control packet.

    Finally, the mapping from an EID (or EID block) contains not just the
    RLOC(s), but also (for each RLOC for any given EID entry) priority
    and weight fields (to allow allocation of load between several RLOCs
    at a given priority); this allows a certain amount of traffic
    engineering to be accomplished with LISP.

8.2.1.  Mapping System Organization

    {{Suggestion by editors: Rewrite: Describe key Mapping System
    components: Map-Server/Map-Resolver}}

    The mapping system is split into three functional sub-systems.

    The first is the actual mappings themselves, collectively the mapping
    database; they are held by the ETRs, and an ITR which needs a mapping
    gets it (effectively) directly from the ETR.  This co-location of the
    authoritative version of the mappings, and the forwarding
    functionality which it describes, is an instance of fate-sharing.
    [Clark]

    To find the appropriate ETR(s) to query for the mapping, the second
    two sub-systems form an indexing system, itself also based on a
    distributed, potentially replicated database.  It provides
    information on which ETR(s) are authoritative sources for the various
    EID-to-RLOC mappings which are available.  The two sub-systems which
    form it are the client interface sub-system, and indexing sub-system
    (which holds and provides the actual information).

Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 19]

Internet-Draft              LISP Introduction                  July 2014

8.2.2.  Interface to the Mapping System

    {{Suggestion by editors: has been rewritten: This section should
    appear earlier since it describes key LISP components (Map-Request/
    Map-Reply/Map-Server/Map-Resolver}}

    The client interface to the indexing system from an ITR's point of
    view is not with the indexing sub-system directly; rather, it is
    through the Map-Resolvers (MRs) and Map-Servers (MSs).

    To obtain the mapping for an EID, the ITRs sends Map-Request packet
    to an MR.  The MR then uses the indexing sub-system to allow it to
    forward the Map-Request to an appropriate Map-Server (MS), which in
    turn sends the Map-Request on to the appropriate ETR.  The latter is
    authoritative for the actual mappings for the EID.

    The ETR then sends the mappings for that EID in the form of aMap-
    Reply packets, which is sent directly to the ITR, without passing
    through the indexing sub-system and MR.  The details of the indexing
    sub-system are thus hidden from the ITRs.

    Note that in proxy mode, the MS replies on behalf of the ETR.  When
    this the case, the map-replies is tagged to indicate that the answer
    is not delivered from the authoritative ETR but from the MS instead.

    The interface to the indexing system from an ETR's point of view is
    made through MSes.  ETRs send Map-Register packets to their
    designated MSes.  The effect of a Map-Register is to inform the MS
    about the mappings maintained by ETRs such that the MS can transmit
    the Map-Requests is receives to the appropriate ETRs.

    The MS optionally replies Map-Register packets with a Map-Notify
    packet to confirm the registration.  The details of the indexing sub-
    system are thus likewise hidden from ETRs.

    The fact that the details of the indexing sub-system are entirely
    hidden from xTRs gives considerably flexibility to this aspect of
    LISP.  As long as any potential indexing sub-system can track where
    mappings are, it could potentially be used; this would allow the
    actual indexing sub-system to be replaced without needing to modify
    the xTRs.

8.2.3.  Indexing Sub-system

    {{suggestion by editor: rename the section to "DDT"}}

I think this section should briefly describe both ALT (mostly by reference to RFC 6836) and  DDT (by reference to LISP-DDT, with way fewer details on DDT than in the current document). "Indexing System" (as a component of the mapping system, together with the mapping database) may be a good name for this section.

"Index subsystem" is not a term used in ALT or DDT. What about "Mapping Database"?

    The current indexing sub-system is the Delegated Database Tree (DDT),
    which is conceptually similar to DNS ([I-D.ietf-lisp-ddt],

Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 20]

Internet-Draft              LISP Introduction                  July 2014

    [RFC1034]).  DDT replaces the earlier LISP+ALT indexing sub-system
    ([RFC6836]).  The seamless migration to DDT while LISP+ALT was
    previously used validated the concept of having a client-interface
    sub-system between the indexing sub-system, and the clients.

8.2.3.1.  DDT Overview

    Conceptually, DDT is similar to the DNS, in DDT the delegation of the
    EID namespace is instantiated as a delegation hierarchy, a tree of
    DDT nodes, starting with the root DDT node.  Each vertex is
    responsible for a block of the EID namespace.

    The root node is responsible for the entire EID space; any DDT node
    can delegate part(s) of its EID block to child DDT node(s).  The
    child node(s) can in turn further delegate (necessarily smaller)
    blocks of namespace to their children, through as many levels as are
    needed (for operational, administrative, etc, needs).

    Just as with DNS, any particular vertex in the DDT delegation tree
    may be instantiated in one or more DDT servers.  Multiple (redundant)
    servers for a given node would be used for reasons of performance,
    reliability, and robustness.  Obviously, all the servers which
    instantiate a particular nodes in the tree have to have identical
    data about that node.

8.2.3.2.  Use of DDT by MRs

    An MR which wants to find a mapping for a particular EID first
    interacts with the DDT servers which instantiate the nodes of the
    LISP delegation hierarchy tree, discovering (by querying the servers
    for information about DDT nodes) the chain of delegations which cover
    that EID.  Eventually it is directed to an MS, which is servicing an
    ETR which is authoritative for that EID.

    Also, again like DNS, MRs may cache information they receive about
    the delegations in the delegation tree.  This means that once an MR
    has been in operation for a while, it will usually have much of the
    delegation information cached locally (especially the top levels of
    the delegation tree).  This allows them, when passed a request for a
    mapping by an ITR, to usually forward the mapping request to the
    appropriate MS without having to interact with all the DDT servers on
    the path down the delegation tree, in order to find any particular
    mapping.

    Thus, a typical resolution cycle would usually involve looking at
    some locally cached delegation information, perhaps loading some
    missing delegation entries into their delegation cache, and finally
    sending the Map-Request to the appropriate MS.

Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 21]

Internet-Draft              LISP Introduction                  July 2014

    It should also be noted that the delegation tree is fairly static,
    since it reflects EID block allocations, which are themselves fairly
    static.  This stability has several important consequences.  First,
    it increases the performance of the mapping system, since the sub-
    system almost never needs to be re-queried for information about
    intermediate vertices.  {{comment from editor: does not understand
    the next sentence...}}Second, it is not necessary to include a
    mechanism to find out-dated delegations.  [LISP-TREE]

    This contrasts with the mappings, which may change at a high rate -
    changes which have no impact on the indexing sub-system.  The
    potentially high dynamics of mappings explains why mappings are
    delivered directly from ETRs (or MSes in proxy mode) to ITRs and
    hence not cached at the MR level.  LISP is designed to make sure that
    changes in the mappings are detected and acted upon fairly quickly;
    this allows LISP to provide a number of capabilities, such as
    mobility.

9.  Examples of operation

    To aid in comprehension, a few examples are given of user packets
    traversing the LISP system.  The first shows the processing of a
    typical user packet which is LISP forwarded, i.e. what the vast
    majority of user packets will see.  The second shows what happens
    when the first packet to a previously-unseen ultimate destination (at
    a particular ITR) is to be processed by LISP.

9.1.  An Ordinary Packet's Processing

    {{Suggestion by editors: This section should be earlier in the
    document structure, examples are important -particularly for
    engineers- to explain how systems work}}

    This case follows the processing of a typical , {{comment from
    editors: text missing}} when the packet has made its way through the
    local site to an ITR, which in this case is a border router for the
    site, the border router looks up the destination address - an EID -
    in its local mapping cache.  For EIDs which are IP addresses, this
    lookup uses the IP longest prefix matching algorithm.

    It finds a mapping, which instructs it to wrap the packet in an outer
    header - an IP packet, containing a UDP packet which contains a LISP
    header - and then the user's original packet (see Section 12.2 for
    the reasons for this particular choice).  The destination address in
    the outer header is set by the ITR to the RLOC of the destination
    ETR.

Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 22]

Internet-Draft              LISP Introduction                  July 2014

    The encapsulated packet is then sent off through the RLOC space
    (e.g., Internet), using normal Internet routing.

    On arrival at the destination ETR, the ETR will notice that it is
    listed as the destination in the outer header.  It will examine the
    packet, detect that it is a LISP packet, and unwrap it.  It will then
    examine the header of the user's original packet, and forward it
    internally, through the local site, to the ultimate destination.

    At the ultimate destination, the packet will be processed, and may
    produce a return packet, which follows the exact same process in
    reverse - with the exception that the roles of the ITR and ETR are
    swapped.

9.2.  A Mapping Cache Miss

    {{Suggestion by editors: (same as previous section)}}

    If a host sends a packet, and it gets to the ITR, and the ITR
    determines that it does not yet have a mapping cache entry which
    covers that destination EID, then additional processing ensues; it
    has to look up the mapping in the mapping system (as previously
    described in Section 6.2).

    The overall processing is shown below, in Figure 2:

                   -----            -----
                  |     |    3     |     |
    Map Resolver  |     | -------> |     |  Map Server
                  |     |          |     |
                   -----            -----
                     ^                |
    Key:             |                |
                     |                |
    -- = Control     |                |
    == = Data        |                |
                  2  |       5        |  4
                     |      ---       |
    Host A           |    /     \     |            Host B
                     |  |_       \    V
     -----          -----          \ -----          -----
    |     |   1    |     |    6     |     |   7    |     |
    |     | =====> | ITR | =======> | ETR | =====> |     |
    |     |        |     |          |     |        |     |
     -----          -----            -----          -----

                 Figure 2: Packet flow with missing mapping

Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 23]

Internet-Draft              LISP Introduction                  July 2014

    1.  Source-EID sends packet (to Dest-EID) to ITR

    2.  ITR sends Map-Request to Map-Resolver

    3.  Map-Resolver delivers Map-Request to Map-Server

    4.  Map-Server delivers Map-Request to ETR

    5.  ETR returns Map-Reply to ITR; ITR caches EID-to-RLOC(s) mapping

    6.  ITR uses mapping to encapsulate to ETR; sends user packet to ETR

    7.  ETR decapsulates packet, delivers to Dest-EID

    The ITR first sends a Map-Request packet, giving the destination EID
    it needs a mapping for, to its MR.  The MR will look in its cache of
    delegation information to find the vertex which is the most specific
    in the delegation tree for that destination EID .  If it does not
    have the address of an appropriate MS, it will query the DDT system,
    recursively if need be, in order to eventually find the address of
    such an MS.

    When it has the MS's address, it will send the Map-Request on to the
    MS, which then usually sends it on to an appropriate ETR.  The ETR
    sends a Map-Reply to the ITR which needs the mapping; from then on,
    processing of user packets through that ITR to that ultimate
    destination proceeds as above.

    To the best of our knowledge, in all LISP implementations, the
    original user packet will have been discarded, and not queued waiting
    for the mapping to be returned.  When the host retransmits such a
    packet, the mapping will be there, and the packet will be forwarded.
    Alternatively, it might have been forwarded using a PITR to avoid
    being dropped (Section 6.4).

10.  Part II

    {{comment from editors: is that the role of an introductory document
    to enter in such level of details and discuss (mostly) all fields of
    the protocol? }}

No.
It should just describe the architecture of the entire LISP system, making it easier to read the rest of the LISP specifications and providing a *basis* for discussion about the details of the LISP protocols.

11.  Design Approach

    {{Suggestion by editors: Remove this section, it does not describe/
    discuss anything relevant, it is only providing a reference to
    another non-WG document.}}

Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 24]

Internet-Draft              LISP Introduction                  July 2014

    Before describing LISP's components in more detail below, it it worth
    pointing out that what may seem, in some cases, like odd (or poor)
    design approaches do in fact result from the application of a
    thought-through, and consistent, design philosophy used in creating
    them. {{Subjective: maybe JMH, Dino can help with better words?}}

    This design philosophy is covered in detail in
    [I-D.ietf-lisp-perspective], Section "Design"), and readers who are
    interested in the 'why' of various mechanisms should consult that;
    reading it may make clearer the reasons for some engineering choices
    in the mechanisms given here.

12.  xTRs

    As mentioned above (in Section 8.1), xTRs are the essential LISP data
    plane elements.  This section explores some advanced topics related
    to xTRs.

    {{Suggestion by editors: remove next paragraph, brings nothing)}}

    Careful rules have been specified for both TTL and ECN [RFC3168] to
    ensure that passage through xTRs does not interfere with the
    operation of these mechanisms.  In addition, care has been taken to
    ensure that traceroute works when xTRs are involved.

12.1.  When to Encapsulate

    An ITR knows that an ultimate destination is running LISP (remember
    that the actual destination machine itself probably knows nothing
    about LISP), and thus that it should perform LISP processing on a
    packet (including potential encapsulation) if it has an entry in its
    local mapping cache that covers the destination address (it is then
    called an EID).

    Conversely, if the cache contains a negative entry (indicating that
    the ITR has previously attempted to find a mapping that covers this
    EID, and it has been informed by the mapping system that no such
    mapping exists), it knows the ultimate destination is not running
    LISP, and the packet can be forwarded natively (i.e. not LISP-
    encapsulated).

    Note that the ITR cannot simply depend on the appearance, or non-
    appearance, of the destination in the routing tables in the Internet
    core, as a way to tell if a destination is a LISP node or not.  That
    is because mechanisms to allow interoperation of LISP sites and
    legacy sites necessarily involve advertising LISP sites' EIDs into
    the Internet core; in other words, LISP sites which need to

Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 25]

Internet-Draft              LISP Introduction                  July 2014

    interoperate with legacy nodes will appear in the Internet core
    routing tables, along with non-LISP sites.

12.2.  UDP Encapsulation Details

    Use of UDP (instead of, say, a LISP-specific protocol number) was
    driven by the fact that many routers and middle boxes filter out
    unknown protocols, so adopting a non-UDP encapsulation would have
    compromised the initial deployment of LISP.

    The UDP source port used for encapsulating packet is computed with a
    5-way hash of the original source and destination in the inner
    header, along with the ports, and the protocol.  This is because many
    ISPs use multiple parallel paths (so-called Equal Cost Multi-Path),
    and load-share across them.  Using such a hash in the source-port in
    the outer header both allows LISP traffic to be load-shared, and also
    ensures that packets from individual connections are delivered in
    order (since most ISPs try to ensure that packets for a particular
    flow follow a single path, and hence do not become disordered).

    The UDP checksum is zero because the inner packet usually already has
    a end-end checksum, and the outer checksum adds no value ([Saltzer]).
    {{Suggestion by editors: not sure that next statement is correct}} In
    most exising hardware, computing such a checksum (and checking it at
    the other end) would also present a major load, for no benefit.

12.3.  Header Control Channel

    {{Suggestion by editors: Rewrite this section to improve readability,
    use standard terminology (e.g., Cache Coherence/Reachability instead
    of "Header Control Channel").  Split the mechanisms depending on its
    goal (cache coherence/reachability) and describe them under the same
    context.}}

    LISP provides a multiplexed channel in the encapsulation header.  It
    is mostly (but not entirely) used for control purposes.  The general
    concept is that the header starts with a flags field, and it also
    includes two data fields, the contents and meaning of which vary,
    depending on which flags are set.  This allows these fields to be
    multiplexed among a number of different low-duty-cycle functions,
    while minimizing the space overhead of the LISP.

12.3.1.  Mapping Versioning

    One important use of the multiplexed control channel is mapping
    versioning; i.e. the discovery of when the mapping cached in an ITR
    is outdated.  To allow an ITR to discover this, identifying sequence
    numbers are applied to different versions of a mappping [RFC6834].

Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 26]

Internet-Draft              LISP Introduction                  July 2014

    This allows an ITR to easily discover when a cached mapping has been
    updated by a more recent variant.

    Version numbers are available in control messages (Map-Replies), but
    the initial concept is that to limit control message overhead, the
    versioning mechanism should primarily use the multiplexed user data
    header control channel.

    Versioning can operate in both directions: an ITR can advise an ETR
    what version of a mapping it is currently using (so the ETR can
    notify it if there is a more recent version), and ETRs can let ITRs
    know what the current mapping version is (so the ITRs can request an
    update, if their copy is outdated).

12.3.2.  Echo Nonces

    Another important use of the header control channel is for a
    mechanism known as the Nonce Echo, which is used as an efficient
    method for ITRs to check the reachability of neighbour ETRs.

    Basically, an ITR which has to determine that an ETR is up, and
    reachable, sends a nonce to that ETR, carried in the encapsulation
    header; when that ETR (also acting as an ITR) sends some other user
    data packet back to the ITR (acting in turn as an ETR), that nonce is
    carried in the header of that packet, allowing the original ITR to
    confirm that its packets are reaching that ETR.

    Note that a lack of a response is not necessarily proof that
    something has gone wrong - but it strongly suggests that something
    has, so other actions (e.g. a switch to an alternative ETR, if one is
    listed; a direct probe; etc) are advised.  (See Section 16.5 for more
    about Echo Nonces.)

12.3.3.  Instances

    {{Suggestion by editors: Move and extend this section: - Instance ID
    is not a cache-coherence/reachability algorithm.  Describe where and
    what is the Instance ID field Explain its applications}}

    The LISP data-plane header is also used to support VPN and multi-
    tenant networks.  Since there is only one destination UDP port used
    for carriage of user data packets, and the source port is used for
    multiplexing, there is no other way to differentiate among different
    destination EID spaces (which are often overlapped in VPNs and multi-
    tenant networks).

Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 27]

Internet-Draft              LISP Introduction                  July 2014

12.4.  Probing

    RLOC-Probing is a mechanism method that an ITR can use to determine
    with that an ETR is up and reachable from the ITR.  As a side-
    benefit, it gives RTT estimates.

    To probe the reachability of an RLOC, an ITR sends a specially marked
    Map-Request directly to the ETR it wishes information about; that ETR
    sends back a specially marked Map-Reply.  A Map-Request message and a
    Map-Reply message are used, rather than a special probing control-
    message pair, because as a side-benefit the ITR can discover if the
    mapping has been updated since it cached it.

    {{Suggestion from editors: remove the following sentence as it is not
    motivated by strong arguments}} The probing mechanism is rather
    heavy-weight and expensive (compared to mechanisms like the Echo-
    Nonce), since it costs a control message from each side, so it should
    only be used sparingly.

    If the number of active neighbour ETRs of the ITR is large, use of
    RLOC-Probing to check on their reachability will result in
    considerable control traffic; such control traffic has to be spread
    out to prevent a load peak.

    Obviously, if RLOC-Probing is the only mechanism being used to detect
    unreachable neighbour ETRs, the rate at which RLOC-Probing is done
    will control the timeliness of the detection of loss of reachability.
    There is thus a tradeoff between overhead and responsiveness,
    particular when an ITR has a large fanout of neighbour ETRs.

12.5.  Mapping Lifetimes and Timeouts

    {{Suggestion by editors: Remove this section, TTL is a simple well-
    known concept, we suggest to include a sentence (and hence remove
    this section) in the control-plane section stating that mappings
    include a TTL.

    Mappings come with a Time-To-Live, which indicate how long the
    creator of the mapping expects them to be useful for.

    Mappings might also be discarded before the TTL expires, depending on
    what strategies the ITR is using to maintain its cache; if the
    maximum cache size is fixed, or the ITR needs to reclaim memory,
    mappings which have not been used recently may be discarded.  (After
    all, there is no harm in so doing; a future reference will merely
    cause that mapping to be reloaded.)

    {{Contents may change before TTL expires?}}

Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 28]

Internet-Draft              LISP Introduction                  July 2014

12.6.  Mapping Gleaning in ETRs

    {{Suggestion by editors: Remove this section, gleaning is discouraged
    since it rises many security concerns.}}

    As an optimization to the mapping acquisition process, ETRs are
    allowed to glean mappings from incoming user data packets, and also
    from incoming Map-Request control messages.  This is not secure, and
    so any such mapping must be verified by sending a Map-Request to get
    an authoritative mapping.

    The value of gleaning is that most communications are two-way, and so
    if host A is sending packets to host B (therefore needing B's
    EID->RLOC mapping), very likely B will soon be sending packets back
    to A (and thus needing A's EID->RLOC mapping).  Without gleaning,
    this would sometimes result in a delay, and the dropping of the first
    return packet; this is felt to be very undesirable.

12.7.  MTU Issues

    Several mechanisms have been proposed for dealing with packets which
    are too large to transit the path from a particular ITR to a given
    ETR.

    In one, called the stateful approach, the ITR keeps a per-ETR record
    of the maximum size allowed, and sends an ICMP Too Big message to the

_______________________________________________
lisp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lisp

---

From: Florin Coras <[email-masked]>
Date: Mon, 04 Aug 2014 01:21:57 -0700

Albert, Damien,

There's not much to add to what previous reviewers have already 
mentioned. Overall, I agree with the editorial recommendations, 
especially those in favor of simplifying the discourse. I'm also of 
opinion that the document should be a concise description of LISP and 
only offer a high-level description of problems that it solves or it may 
solve. In this sense, I agree with Victor's point that more general text 
that allows for future use cases might be needed.

Thanks for moving this forward. I'm looking forward to reviewing the 
next revision.

Florin

On 8/1/14 2:30 PM, Victor Moreno (vimoreno) wrote:
> - Not in the current text: Spell out very clearly and upfront the 
> concept of *separation* of location and identity.
> - With the concept of location/identity separation clear, then proceed 
> to introduce RLOCs and EIDs as manifestations of such concepts.
> - Finally introduce LISP as the mechanisms to handle the mappings that 
> correlate the two address spaces. May be a good segway into the Basic 
> functionality section that follows.
>
> - I think it is worth adding to this section the notion of the 
> destination based policies manifested as priorities and weights. Since 
> this is an architectural doc, we may want to abstract this policy 
> notion enough to accommodate other/future policy options that may arise.
> - The pull nature of the mechanism is introduced in 6.3 currently. I 
> think this is an important attribute and may be worth considering 
> bringing it forward to 6.2.
>
> - Most use cases will probably fall out of charter at this point, 
> making this section very short until a future re-charter allows more 
> use cases. IMO we need text to allow for those future use cases that 
> are currently out of charter without having to re-open this 
> architecture document. One option is to keep the text on the use cases 
> that is currently in the document. Another option is to include 
> general text to allow future use cases. The latter may be required 
> regardless.
> 8.2. Regarding EID-block vs. prefix. I kind of like EID-block in 
> support of the AF agnostic characteristics of LISP. Prefixes (I think) 
> are tightly coupled with IP, once we have MAC addresses or other 
> addresses prefix may not be the best choice.
>
> 10.  Part II
>
> IMO not in detail and we should probably be a bit more selective in 
> terms of which fields we do discuss in this doc vs. which we do not. 
> Thus outlining the moving parts, at a high level,  and providing 
> references to the documentation with the relevant details may be 
> helpful to those starting with LISP. In general, this second part 
> should be much more succinct in my opinion.
>
> Regarding any other “Suggestions by editors", I agree with all the 
> editor suggestions in version 04 with any comments/exceptions noted above.
>
> On Jul 28, 2014, at 1:28 PM, Albert Cabellos 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>> Fabio,
>>
>> Please see below:
>>
>>
>>             Drafts is athttp://datatracker.ietf.org/drafts/current/
>>         <http://datatracker.ietf.org/drafts/current/>.
>>
>>     Agree: my suggestion is to view this as a doc for a reader new to
>>     LISP that needs to be introduced to the architecture. At the end
>>     of the doc the reader will be familiar with the basic aspects of
>>     LISP, and able to navigate through the RFCs. The document should
>>     be kept as short and as "dry" as possible. If the reader wants to
>>     know more, after reading this doc, he will know where to go for
>>     the details.
>>
>>
>>
>>
>>     let's stick to the RFCs glossary. Since this is a first-to-read
>>     doc there should be a minimal definition section, but definitions
>>     should mostly be cut and paste from the RFCs.
>>
>>
>>     Remove. This doc is not a guide to good protocol design. The
>>     concept that LISP is deployable incrementally should be mentioned
>>     in the document though, possibly with a reference to the
>>     deployment RFC.
>>
>>
>> Agreed, we´ll include an (ultra-short) section describing the design 
>> principles of LISP, incremental deployment is of course one of them.
>>
>>
>>     Agree: across the document, as done in the RFCs, I'd suggest to
>>     focus on describing the protocol architecture and how it works
>>     rather than on more generic considerations about the LISP philosophy.
>>
>>     Make sure a figure with the basic elements of the protocol
>>     architecture (possibly similar to figure 1) is introduced as
>>     early as possible. 
>>
>>
>>
>>
>>
>>
>>            `.    .'             `.                ,'         `.    .'
>>            |
>>     Agree. I think that the security considerations section of
>>     RFC6830 may provide a guide to the items you may want to touch in
>>     this document. Point the reader to the RFCs when possible. Move
>>     broader security considerations to the Security Section
>>     referencing lisp-threats where needed.
>>
>>
>> Agreed.
>>
>>
>>     I think this section should briefly describe both ALT (mostly by
>>     reference to RFC 6836) and  DDT (by reference to LISP-DDT, with
>>     way fewer details on DDT than in the current document). "Indexing
>>     System" (as a component of the mapping system, together with the
>>     mapping database) may be a good name for this section.
>>
>>
>>     It should just describe the architecture of the entire LISP
>>     system, making it easier to read the rest of the LISP
>>     specifications and providing a *basis* for discussion about the
>>     details of the LISP protocols.
>>
>>
>>         11.  Design Approach
>>
>> [email-masked] <mailto:[email-masked]>
> [email-masked]