Subject: Re: [lisp] Comments on draft-ietf-lisp-introduction-01

From: "Michiel Blokzijl (mblokzij)" <[email-masked]>
Date: Sun, 4 Aug 2013 18:37:48 +0000

Hello everyone,

Here's part II, with comments on sections 4-6.

General comments:
- I'd consider moving some of the "other attempts failed to recognise X.." bits into their own section, or possibly into another document. I think these somewhat fall into the category of "LISP in the context of the history of the internet" :)
- After reading more of this document, I think it starts to sound more like "A survey on LISP"?

I hope my comments don't come across as overly negative..

4. LISP Overview

   LISP is an incrementally deployable architectural upgrade to the
   existing Internet infrastructure, one which provides separation of
   location and identity.  The separation is usually not perfect, for
   reasons which are driven by the deployment philosophy (above), and
   explored in a little more detail elsewhere (in [Perspective], Section
   "Namespaces-EIDs-Residual").

The first bit is probably OK, the second one I think doesn't add much value here, apart from saying that "if you want to look at some imperfections, go here". I'd move it into a later section if you need to discuss it at all.

   LISP separates the functions of location and identity of nodes (a
   nebulous term, deliberately chosen for use in this document precisely
   because its definition is not fixed - you will not go far wrong if
   you think of a node as being something like a host), which are
   currently intermingled in IPvN addresses.  (This document uses the
   meaning for 'address' proposed in [Atkinson], i.e. a name with mixed
   location and identity semantics.)

So in RFC6115 nodes were defined as either routers or hosts (section 1.2, 1.). What else are you thinking about? I think the bracketed bit just confuses readers, and I think it can be removed.

I'm not sure whether location and identity are 'functions' of IPvN addresses, rather than, say, properties. Are you saying that the location is a function that takes as input an IP address and produces as output.. a location description? I guess you could look at it in that way.

Again, I don't think that the 'intermingled' is very clear here. I also think that this paragraph is a bit repetitive; the separation is already identified in the preceding paragraph, and apart from the definition of address I don't think it adds much.

4.1 Basic approach

   In LISP, nodes have both a 'locator' (a name which says _where_ in
   the network's connectivity structure the node is), called an 'RLOC'
   (short for 'routing locator'), and an 'identifier' (a name which
   serves only to provide a persistent handle for the node), called an
   'EID' (short for 'endpoint identifier').

Style comment: I think it's better to spell acronyms out the first time they're being used, and then provide the abbreviation in brackets.

   A node may have more than one RLOC, or its RLOC may change over time
   (e.g. if the node is mobile), but it would normally always keep the
   same EID.

A node may also have more than 1 EID, e.g. one for v4 and one (or more) for v6. Maybe it's worthwhile saying "EID(s)", or is that confusing?

   Technically, one should probably say that ideally, the EID names the
   node (or rather, its end-end communication stack, if one wants to be
   as forward-looking as possible), and the RLOC(s) name interface(s).
   (At the moment, in reality, the situation is somewhat more complex,
   as will be explained elsewhere (in [Perspective<http://tools.ietf.org/html/draft-ietf-lisp-introduction-01#ref-Perspective>], Section
   "Namespaces-EIDs-Residual".)

I think both of the sentences in brackets are confusing, and don't aid the reader much. The RLOCs naming the interfaces applies only to a small subset of devices in the LISP EID (address) space, namely the (P)xTRs, for the hosts in a LISP site the RLOCs name their xTRs' interfaces.

   This second distinction, of _what_ is named by the two classes of
   name, is necessary both to enable some of the capabilities that LISP
   provides (e.g the ability to seamlessly support multiple interfaces,
   to different networks), and is also a further enhancement to the
   architecture.  Faailing to clearly recognize both interfaces and
   communication stacks as distinctly separate classes of things is
   another failing of the existing Internet architecture (again, one
   inherited from the previous generation of networking).

I think it would be better to talk about use-cases later in the document (I'm referring to the seamless multihoming).

typo: Faailing => Failing

I'm sure you guys know more about this, but I don't think that interfaces and communication stacks are completely separate "classes of things" (the word "things" would also bother me a little in standards documents, but I'm sure you know more about the expected style than I do). After all, L2 is a part of the communication stack, and that's to some degree bound to interfaces.

   A novelty in LISP is that it uses existing IPvN addresses (initially,
   at least) for both of these kinds of names, thereby minimizing the
   deployment cost, as well as providing the ability to easily interact
   with unmodified hosts and routers.

Good - not sure 'novelty' is the right word though. Maybe say something like.. "In order to minimise deployment costs, LISP supports existing IPvN addresses for both of these kinds of names, as well as other future address family types. The former facilitates the interaction with unmodified hosts and routers."

4.2

The first few paragraphs of this section take the reader from the abstract concept of 'intercepting' and 'augmenting' packets to the actual encapsulation process in multiple stages. I think this makes the whole process sound more mysterious than it actually is, but it's probably OK.

   The LISP device near the original source (the Ingress Tunnel Router,
   or 'ITR') uses the information originally in the packet about the
   identity of its ultimate destination, i.e. the destination address,
   which in LISP is the EID of the ultimate destination.  It uses the
   destination EID to look up the current location (the RLOC) of that
   EID.

I'd try and simplify the sentence a little bit, the destination bit is quite repetitive. Something like: The LISP device near the original source (…) extracts the destination address from the packet, which in this context is an Endpoint ID. It then looks up the current location of this destination 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
   RLOCS.  The destination RLOC will be (initially at least) the address
   of the LISP device near the ultimate destination (the Egress Tunnel
   Router, or 'ETR').

This is inconsistent with what 4.1 says about what RLOCs should ideally be.

   {{Is it worth distinguishing between 'mapping' and 'binding'?  Should
   the document pick one term, and stick with it?}}

To be honest, I'm not sure what the difference is. I looked at RFC6830, and it only uses the word binding in 2 places, the more useful one of which is this: "A map request for any endpoint will return a binding for the entire mobile prefix" (the other is in the context of mobile IP).. just a few sentences above that reference, it discusses the "validity of an EID-to-RLOC mapping for a longer time". The word 'mapping' occurs 173 times.. I'd prefer to know the difference between the two before giving an opinion, but my inclination would be to aim for consistency with the other RFCs.

4.3

I think it would be better to stick with 'mapping system', which was used in the previous paragraph, rather than using the term 'mapping database'.

   Mappings are requested on need, not (generally) pre-loaded; in other
   words, mapping are distributed via a 'pull' mechanism.  Once obtained
   by an ITR, they are cached by the ITR, to limit the amount of control
   traffic to a practicable level.  (The mapping system will be
   discussed in more detail below, in Section 6.2<http://tools.ietf.org/html/draft-ietf-lisp-introduction-01#section-6.2> and Section 10<http://tools.ietf.org/html/draft-ietf-lisp-introduction-01#section-10>)

I'd change 'on need' to 'on demand', and maybe state that the caching is also done for performance reasons (you don't want to drop every other packet).

   Extensive studies, including large-scale simulations driven by
   lengthy recordings of actual traffic at several major sites, have
   been performed to verify that this 'pull and cache' approach is
   viable, in practical engineering terms.  (This subject will be
   discussed in more detail in Section 6.1.1<http://tools.ietf.org/html/draft-ietf-lisp-introduction-01#section-6.1.1>, below.)

This is interesting. I'm not sure if I'd put it into a "further reading" section though.

4.4

I probably would've summarised the first two paragraphs into a sentence and merged it with the last one:

In order to facilitate incremental LISP deployments, several mechanisms have been designed to allow LISP enabled nodes to communicate with non-LISP enabled (legacy) nodes, each with different trade-offs. One mechanism uses proxy LISP devices, called PITRs (proxy ITRs) and PETRs (proxy ETRs), to provide LISP functionality during interaction with legacy hosts. Another approach uses a device with combined LISP and NAT ([RFC1631]) functionality, named a LISP-NAT.

But that's probably just me :)

I would also provide references to the two approaches you introduced here.

4.5

I would provide the brief overview first, and then say "for more details, go to.."

At the same time, I don't think that this section actually says anything at all about LISP security, beyond telling the reader that it's been considered, and that there's a tradeoff between security and deployability. It only talks about security in general.

I would either remove this section, or replace it with one that actually provides a brief overview of /LISP/ security. [Vasilis already mentioned this]

5.

I think the whole section focuses a little too much on the motivation to cater for the various use-cases, and a too little on how LISP uniquely addresses them.. But I get the impression that this is on purpose, and perhaps I just would've decided differently.

5.1

The referenced RFC appears to use the term "Provider-Aggregatable"

   In theory, it ought to be possible to update the DNS entries, and
   have everyone switch to the new addresses, but in practise, addresses
   are embedded in many places, such as firewall configurations at other
   sites.

I think the point made here is valid, but not a difference between theory and practise in the way it's stated (in practise it's also possible to update DNS entries). You could say "In theory, it ought to be sufficient to update the DNS entries".

5.2

I think it'd be nice if this section explained at least briefly how LISP actually helps with multi homing (priority & weights).

5.3

I think the first two sections are somewhat repetitive in terms of explaining that the internet was not designed with TE in mind.

I actually went and looked in section 6.2. The only bit that refers to TE is this:

   The mapping contains not just the RLOC(s), but also (for each RLOC
   for any given EID) priority and weight (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.

If it's just this one sentence, maybe it's worth stating that the priorities and weights can be used for [ingress] TE?

5.5

See 5, but I appreciate that mobility is somewhat outside of the charter.

5.6
"Note that LISP 'automagically' allows intermixing of various IP versions for packet carriage" => Are words like 'automagically' often used in RFCs?

I would somehow tie in that this is because LISP can use different versions of IP (or other protocols?) for the EID and RLOC space, or is that too technical?

5.7

Is it worth mentioning the words 'network virtualisation' in this context, or is that too buzzwordy?

6.1

   xTRs are fairly normal packet switches, enhanced with a little extra
   functionality in both the data and control planes, to perform LISP
   data and control functionality.

I'd probably remove the "fairly normal" and "little extra".. Maybe something like "xTRs are packet switches, which support the LISP control protocol and LISP encapsulation in the switchpath", or something like that?

I'd use the term 'decapsulate' for the ETR bit, since you used 'encapsulate' in the ITR paragraph.

6.1.1

I think this section is more appropriate for a survey than for an introduction.

6.2

I think it would be better to use the terms 'mapping system' and mapping database' consistently.

The mapping system also contains attributes of RLOCs, namely the priority and weight.

>   However, the block may be (and often is) as small as a single EID.

I'm not sure if "often" is correct. I took the HTML of http://www.lisp4.net/lisp-site/, discarded everything outside the main table, and all lines that didn't contain a '/' (trying to keep all the prefixes), sorted them and removed duplicates. That left me with 690 prefixes, 141 (~20%) of which were /32 or /128 (I didn't find /32 IPv6 addresses). I think the numbers make sense for an estimated nr of 355 sites, as it's on average ~2 prefixes/site.

   A particular node may have more than one RLOC, or may change its
   RLOC(s), while keeping its singlar identity.

I'd remove singular, as sites may have more than one EID (as seen in the beta network example above).

6.2.2

Re: (MSs - admittedly a poorly chosen term, since their primary function is not to respond to queries, but it's too late to change it now).

I'd be half inclined to remove the note about it being a poorly chosen term - maybe some day enabling proxy replies will be the recommended deployment method?

--

Best regards,

Michiel

On 26 Jul 2013, at 21:35, Noel Chiappa <[email-masked]<mailto:[email-masked]>> wrote:

From: [email-masked]<mailto:[email-masked]> (Noel Chiappa)

Now that I think about it, the way to hopefully help (I'm not sure I'd
say 'fix totally' ... ) is to add one sentence to the end of the
abstract, saying as concisely as possible that a subset of the
document, readable as a separate unit, forms a 'brief intoduction to
LISP', and is considerably shorter than the document as a whole.
...
All, does this sound like a good thing to do?

Not having heard any disagreement, I will do this.

(I'm not sure it will make Michiel totally happy, but if the abstract clearly
says the document includes a stand-alone brief intro, there's not much more I
can do if people ignore that.. :-)

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

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 5 Aug 2013 12:58:55 +0000

Michiel,

I strongly disagree.

LISP's primary claim is separation of locator and identifier semantics. However, that separation is not perfect. If fact, one might argue that it is no more perfect that the separation that is achieved by an L3VPN.

If we were to sweep this detail under the carpet, the reader would figure it out for himself, and wonder about what else might be under that carpet.

                                                Ron

4. LISP Overview

---

From: "Michiel Blokzijl (mblokzij)" <[email-masked]>
Date: Mon, 5 Aug 2013 13:28:59 +0000

Hi Ronald,

Sorry, it was not my intention to "sweep this detail under the carpet".

I think there's nothing wrong with discussing it in general, I just thought that typically you'd explain the protocol first, and then the limitations when the reader has a bit more of an understanding of the protocol (sometimes even in a separate draft, like http://www.ietf.org/rfc/rfc4116.txt, whatever makes sense I guess). I thought section 4 might be a potential starting point for people who want to find out what LISP is about without reading all of the background material. Basically, it was meant more as a structural/ordering comment.

Also, I should have qualified the "discuss it at all" with "in this draft".

Thank you for your feedback!

Michiel

From: Ronald Bonica <[email-masked]<mailto:[email-masked]>>
Date: Monday, 5 August 2013 13:58
To: Michiel Blokzijl <[email-masked]<mailto:[email-masked]>>, Noel Chiappa <[email-masked]<mailto:[email-masked]>>
Cc: "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [lisp] Comments on draft-ietf-lisp-introduction-01

Michiel,

I strongly disagree.

LISP’s primary claim is separation of locator and identifier semantics. However, that separation is not perfect. If fact, one might argue that it is no more perfect that the separation that is achieved by an L3VPN.

                                                Ron

4. LISP Overview

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 6 Aug 2013 14:07:54 +0000

Michiel,

I'm afraid that I still disagree.

To date, a major shortcoming in the LISP document set is that explains protocol machinery in great detail, but never really explains:

-          What problem it is trying it solve

-          Whether the protocol machinery offered is both necessary and sufficient to solve the problem

IMHO, the purpose of the introduction and architectural perspective documents was to remedy this shortcoming. Given that LISP's primary claim was to separate locator semantics from identifier semantics, it is very appropriate that Noel should introduce this discussion very early in the document.

                                                                                    Ron

From: Michiel Blokzijl (mblokzij) [mailto:[email-masked]]
Sent: Monday, August 05, 2013 9:29 AM
To: Ronald Bonica; Noel Chiappa
Cc: <[email-masked]>
Subject: Re: [lisp] Comments on draft-ietf-lisp-introduction-01

Hi Ronald,

Michiel

Michiel,

I strongly disagree.

                                                Ron

4. LISP Overview