Re: [lisp] I-D Action: draft-ietf-lisp-introduction-06.txt

[Dino Farinacci <[e-mail]>]

>        Title           : An Architectural Introduction to the Locator/ID Separation Protocol (LISP)
>        Authors         : Albert Cabellos
>                          Damien Saucez
> 	Filename        : draft-ietf-lisp-introduction-06.txt
> 	Pages           : 25
> 	Date            : 2014-10-2

Thanks for the update guys. Here are some final (I hope) editorial comments. Thanks for the huge and timely effort.

> 
>    By taking advantage of such separation between location and identity
>    LISP offers Traffic Engineering, multihoming, and mobility among
>    others benefits.  Additionally, LISP's approach to solve the routing
>    scalability problem [RFC4984] is that with LISP the Internet core is
>    populated with RLOCs while Traffic Engineering mechanisms are pushed
>    to the Mapping System.  With this RLOCs are quasi-static (i.e., low
>    churn) and hence, the routing system scalable [Quoitin].

You may want to add ".... while EIDs can roam anywhere with no churn to the underlying routing system."

>    This document describes the LISP architecture, its main operational
>    mechanisms as its design rationale.  It is important to note that
>    this document does not specify or complement the LISP protocol.  The
>    interested reader should refer to the main LISP specifications
>    [RFC6830] and the complementary documents [RFC6831],[RFC6832],
>    [RFC6833],[RFC6834],[RFC6835], [RFC6836] for the protocol

There are 9 RFCs published right at this moment. You should list all of them now that you have the chance. That is, add to the list RFC7052.

Also, put a whitespace character after each comma in the list.

> 2.  Definition of Terms
> 
>    This document describes the LISP architecture and does not define or
>    introduce any new term.  The reader is referred to
>    [RFC6830],[RFC6831],[RFC6832],[RFC6833],[RFC6834],[RFC6835],
>    [RFC6836],[RFC7215] for the LISP definition of terms.

Also, put a whitespace character after each comma in the list. And add RFC7052 as well.

> 
> 3.  LISP Architecture
> 
>    This section presents the LISP architecture, it first details the
>    design principles of LISP and then it proceeds to describe its main
>    aspects: data-plane, control-plane, and inetrworking mechanisms.
> 
> 3.1.  Design Principles
> 
>    The LISP architecture is built on top of four basic design
>    principles:
> 
>    o  Locator/Identifier split: By decoupling the overloaded semantics
>       of the current IP addresses the Internet core can be assigned
>       identity meaningful addresses and hence, can use aggregation to
>       scale.  Devices are assigned with identity meaningful addresses
>       that are independent of their topological location.

I wonder if you should add "... relatively opaque identity meaningful ...".

>    o  Overlay architecture: Overlays route packets over the current
>       Internet, allowing deployment of new protocols without changing
>       the current infrastructure hence, resulting into a low deployment
>       cost.
> 
>    o  Decoupled data and control-plane: Separating the data-plane from
>       the control-plane allows them to scale independently and use
>       different architectural approaches.  This is important given that
>       they typically have different requirements.

And as we are seeing with the trends going on in the industry that many data-planes are being developed at a faster rate than the control-planes. Just wondering if we should state that this separation of data-plane and control-plane allows architecturally for other data-planes to be added.

>    o  Incremental deployability: This principle ensures that the
>       protocol interoperates with the legacy Internet while providing
>       some of the targeted benefits to early adopters.
> 
> 3.2.  Overview of the Architecture
> 
>    LISP splits architecturally the core from the edge of the Internet by
>    creating two separate namespaces: Endpoint Identifiers (EIDs) and
>    Routing LOCators (RLOC).  The edge consists of LISP sites (e.g., an

Change "RLOC" to "RLOCs".

>    analogy to Provider Independent (PI [RFC4116]) addresses.  Because of
>    this, EIDs are usually only routable at the edge.

Maybe add to emeblish "... at the edge with in LISP site.". Its a good segway into the this next sentence:

>   With LISP, LISP sites (edge) and the core of the Internet are
>   interconnected by means of LISP-capable routers (e.g., border
>   routers) using tunnels.  When packets originated from a LISP site are


>    flowing towards the core network, they ingress into an encapsulated
>    tunnel via an Ingress Tunnel Router (ITR).  When packets flow from
>    the core network to a LISP site, they egress from an encapsulated
>    tunnel to an Egress Tunnel Router (ETR).  An xTR is a router with can

Change "with" to "which".

>    perform both ITR and ETR operations.  In this context ITRs
>    encapsulate packets while ETRs decapsulate them, hence LISP operates
>    as an overlay to the current Internet core.

Change "to" to "on top of".

>   interface of an ITR or ETR.  Typically RLOCs are numbered from
>    topologically aggregatable blocks assigned to a site at each point to
>    which it attaches to the global Internet.  The topology is defined by
>    the connectivity of networks, in this context RLOCs can be though as

Change "though" to "thought of".

>    configured at the LISP-capable routers servicing the site.
>    Furthermore, the mappings also include traffic engineering policies
>    and can be configured to achieve multihoming and load balancing.  The
>    LISP Mapping System is conceptually similar to the DNS that would be
>    accessed by ETRs to register mappings and by ITRs to retrieve them.

The last sentence doesn't read clearly. How about just saying the LISP Mapping System is similar conceptually to the DNS where it is organized as a distributed multi-organization network database. Then go on to say that ETRs register mappings and ITRs retrieve mappings.

>    Finally, the LISP architecture emphasizes a cost effective
>    incremental deployment.  Given that LISP represents an overlay to the
>    current Internet architecture, endhosts as well as intra and inter-
>    domain routers remain unchanged, and the only required changes to the
>    existing infrastructure are to routers connecting the EID with the
>    RLOC space.  Such LISP capable routers, in most cases, only require a
>    software upgrade.  Additionally, LISP requires the deployment of an
>    independent Mapping System, such distributed database is a new
>    network entity.
> 
>    The following describes a simplified packet flow sequence between two
>    nodes that are attached to LISP sites.  Client hostA wants to send a
>    packet to server hostB.

Capitalize hostA and hostB since that is how you have it labeled in the diagram and description part.

>    LISP-encapsulated packets also include a LISP header (after the UDP
>    header and before the original IP header).  The LISP header is
>    prepended by ITRs and striped by ETRs.  It carries reachability
>    information (see more details in Section 4.2) and the Instance ID
>    field.  The Instance ID field is used to distinguish traffic to/from
>    different tenant address spaces at the LISP site and that may use
>    overlapped but logically separated EID addressing.
> 
>    Overall, LISP encapsulated data packets carry 4 headers [RFC6830]
>    ("outer" to "inner"):

LISP carries 3 headers. That is it prepends 3 headers. You shouldn't count the header the source host put on it. I know you want to talk about the inner IP header because it contains EIDs, so I would say in the above sentence:

"Overall, LISP works on 4 headers, the inner header the source constructed, and the 3 headers a LISP encapsulator prepends:"

>   Finally, in some scenarios Recursive and/or Re-encapsulating tunnels
>    can be used for Traffic Engineering and re-routing.  Re-encapsulating
>    tunnels are consecutive LISP tunnels and occur when an ETR removes a
>    LISP header and then acts as an ITR to prepend another one.  On the

I would change to "... when a decapsulator (an ETR action) removes ..." and "... acts as an encapsultor (an ITR action) to prepend ...".

> 3.3.2.  LISP Forwarding State
> 
>    ITRs retrieve from the LISP Mapping System mappings between EID
>    prefixes and RLOCs that are used to encapsulate packets.  Such
>    mappings are stored in a local cache -called the Map-Cache- for

Why is there hyphens. Can you please remove them?

> 3.4.  Control-Plane
> 
>    The LISP control-plane, specified in [RFC6833], provides a standard
>    interface to register, request, and resolve mappings.  The LISP

This makes it sounds like "request" and "resolve" are two different operations. Can you just say "... interface to request and register mappings.".

> 
>    Map-Resolver:  A network infrastructure component that interfaces
>       ITRs with the Mapping System by proxying queries and -in some
>       cases- responses.

I would say "receive queries and sends negative replies".

But why don't you order the messages first and then refer to them when you define the Map-Server and Map-Resolver afterwards?

>    Map-Notify:  When requested by the ETR, this message is sent by the
>       Map-Server in response to a Map-Register to acknowledge the
>       correct reception of the mapping and convey the latest Map-Server
>       state on the EID to RLOC mapping.

Everyone I have talked to would like to see we document somewhere, even in general form, the fact that in some cases a Map-Notify can be sent to previous RLOCs when an EID is registered by a new set of RLOCs. Can we add such a sentence and document LISP closer to reality?

>    Map-Request:  This message is used by ITRs or Map-Resolvers to
>       resolve the mapping of a given EID.

This message is also used by ETRs to request an ITR to do a Mapping System request. This message is also used by ITRs to probe the underlying path to an ETR.

>    The LISP WG has explored application of the following distributed
>    system techniques to the Mapping System architecture: graph-based
>    databases in the form of LISP+ALT [RFC6836], hierarchical databases
>    in the form of LISP-DDT [I-D.ietf-lisp-ddt], monolithic databases in
>    the form of LISP-NERD [RFC6837] and flat databases in the form of
>    LISP-DHT [I-D.cheng-lisp-shdht],[I-D.mathy-lisp-dht].  Furthermore it
>    is worth noting that, in some scenarios such as private deployments,
>    the Mapping System can operate as logically centralized.  In such
>    cases it is typically composed of a single Map-Server/Map-Resolver.

If you are going to be exhaustive (which I think you did by listing all the mapping database transport systems above), I would like you to include LISP-EMACs which was a query based system that used multicast on an alternative topology similar to LISP-ALT.

>    LISP defines two entities to provide inetrworking:
> 
>    Proxy Ingress Tunnel Router (PITR):  PITRs provide connectivity from
>       the legacy Internet to LISP sites.  PITRs announce in the global
>       routing system blocks of EID prefixes (aggregating when possible)
>       to attract traffic.  For each incoming data-packet, the PITR LISP-

Change to "For each incoming packet from a source not in a LISP site (a non-EID) ....".

>    Time-To-Live (TTL):  Each mapping contains a TTL set by the ETR, upon
>       expiration of the TTL the ITR has to refresh the mapping by
>       sending a new Map-Request.  Typical values for TTL defined by LISP
>       are 24h.

Change to "24 hours".

>    It is worth noting that RLOC probing and Echo-nonce can work
>    together.  Specifically if a nonce is not echoed, an ITR could RLOC-
>    probe to determine if the path is up because the return bidirectional
>    path may have failed or the return path is not used, that is there is
>    only a unidirectional path.

I think you didn't capture my comment. You should say "determine if the path is up when you cannot tell the difference between a failed bidirectional path or the return path is not used (a unidirectional path)".

>   Nevertheless, LISP can be used to enable seamless IP mobility when
>    LISP is directly implemented in the endpoint.  Each endpoint is then

Or when the endpoint roams to an attached xTR.

>    an xTR and the EID address is the one presented to the network stack
>    used by applications while the RLOC is the address gathered from the
>    network when it is visited.
> 
>    Whenever the device changes of RLOC, the ITR updates the RLOC of its

"... the xTR ...", because ITRs don't register.

> 6.  Multicast
> 
>    LISP also supports transporting IP multicast packets sent from the
>    EID space, the operational changes required to the multicast
>    protocols are documented in [RFC6831].
> 
>    In such scenarios, LISP may create multicast state both at the core
>    and at the sites (both source and receiver).  When signaling is used
>    create multicast state at the sites, LISP routers unicast encapsulate

"... is used to create multicast ..."

>    PIM Join/Prune messages from receiver to source sites.  At the core,
>    ETRs build a new PIM Join/Prune message addressed to the RLOC of the
>    ITR servicing the source.  An simplified sequence is shown below
> 
>    1.  An end-host willing to join a multicast channel sends an IGMP
>        report.  Multicast PIM routers at the LISP site propagate PIM
>        Join/Prune messages (S-EID, G) towards the ETR.
> 
>    2.  The join message flows to the ETR, upon reception the ETR builds
>        two join messages, the first one unicast LISP-encapsulates the
>        original join message towards the RLOC of the ITR servicing the
>        source.  This message creates multicast state at the source site.

"... creates (S-EID, G) multicast state ..."

>    LISP also support non-PIM mechanisms to maintain multicast state.

"LISP can also support ..."

>    flexibility and a performance gap of several order of magnitude can
>    be observed between the slow and the fast paths.  As a consequence,
>    the way data-plane events are notified to the control-plane must be
>    though carefully so to not overload the slow path and rate limiting

Change "though" to "thought".

>    should be used as specified in [RFC6830].
> 
>    Care must also be taken so to not overload the mapping system (i.e.,
>    the control plane infrastructure) as the operations to be performed
>    by the mapping system may be more complex than those on the data-
>    plane, for that reason [RFC6830] recommends to rate limit the sending
>    of messages to the mapping system.
> 
>    To improve resiliency and reduce the overall number of messages
>    exchanged, LISP offers the possibility to leak control informations,

Change to "information".

> 8.  Use Cases
> 
> 8.1.  Traffic Engineering
> 
>    BGP is the standard protocol to implement inter-domain routing.  With
>    BGP, routing informations are propagated along the network and each
>    autonomous system can implement its own routing policy that will
>    influence the way routing information are propagated.  The direct
>    consequence is that an autonomous system cannot precisely control the
>    way the traffic will enter the network.
> 
>    As opposed to BGP, a LISP site can strictly impose via which ETRs the
>    traffic must enter the network even though the path followed to reach

... must enter the the LISP site network ..."

>    the ETR is not under the control of the LISP site.  This fine control
>    is implemented with the mappings.  When a remote site is willing to
>    send traffic to a LISP site, it retrieves the mapping associated to
>    the destination EID via the mapping system.  The mapping is sent
>    directly by an authoritative ETR of the EID and is not altered by any
>    intermediate network.
> 
>    A mapping associates a list of RLOCs to an EID prefix.  Each RLOC
>    corresponds to an interface of an ETR that is able to correctly

Or a set of ETRs.

> 8.2.  LISP for IPv6 Co-existence
> 
>    LISP encapsulations permits to transport packets using EIDs from a

>    given address family (e.g., IPv6) with packets with addresses
>    belonging to another address family (e.g., IPv4).  The absence of
>    correlation between the address family of RLOCs and EIDs makes LISP a
> 

"... from other address families ..."

> 
> 
> Cabellos & Saucez (Ed.)  Expires April 26, 2015                [Page 19]
> Internet-Draft              LISP Introduction               October 2014
> 
> 
>    candidate to allow, e.g., IPv6 to be deployed when all of the core
>    network may not have IPv6 enabled.
> 
>    For example, two IPv6-only data centers could be interconnected via
>    the legacy IPv4 Internet.  If their border routers are LISP capable,
>    sending packets between the data center is done without any form of
>    translation as the native IPv6 packets (in the EID space) will be
>    LISP encapsulated and transmitted over the IPv4 legacy Internet by
>    the mean of IPv4 RLOCs.
> 
> 8.3.  LISP for Virtual Private Networks
> 
>    It is common to operate several virtual networks over the same
>    physical infrastructure.  In such virtual private networks, it is
>    essential to distinguish to which virtual network a packet belongs

Change "... to distinguish to which" to "... to dinguish which ...".

> 8.4.  LISP for Virtual Machine Mobility in Data Centers
> 
>    A way to enable seamless virtual machine mobility in data center is
>    to conceive the datacenter backbone as the RLOC space and the subnet
>    where servers are hosted as forming the EID space.  A LISP router is
>    placed at the border between the backbone and each subnet.  When a
>    virtual machine is moved to another subnet, it can (temporarily) keep
>    the address of the subnet it was hosted before the move so to allow

The above seems misleading. It sounds like the subnet is traveling. But what is traveling with the host is a single address. I would change to "... it can keep the address it had before the move.".

>    ongoing communications to subsist.  When a subnet detects the

Change "subsist" to "continue without a transport layer connection reset.".

>    presence of a host with an address that does not belong to the subnet

Change to "When an xTR detects a source address received on a subnet to be an address not assigned to the subnet, it registers the address to the Mapping System".

Thanks a ton and a great effort,
Dino