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

From: "Michiel Blokzijl (mblokzij)" <[email-masked]>
Date: Tue, 23 Jul 2013 21:47:35 +0000

Hi all,

First of all, let me briefly introduce myself, since this is the first time I'm writing to this list. I'm Michiel, a software engineer at Cisco working on LISP, primarily in IOS and IOS-XR. I joined the team a bit more than a year ago; while I haven't been around for that long, I had at the time less than a handful of days to learn about LISP and to decide whether or not to join the team, and I still remember that it was.. let's say, "surprisingly difficult". And, I think that we as the LISP community can do better (at the time I hadn't read the lisp introduction draft). I do think that LISP is a very cool technology that has a lot of potential!

I understand that comments to this draft are time-critical, which is why I'm releasing the first batch now, even though I've only covered the abstract, ToC and the first three sections (and section 8). Despite me only having covered those, I see that my email is rapidly approaching the <tl/dr> limits (if it hasn't gone over already).. I'll finish going through the draft and provide comments on the rest, though it may take me a few more days..

Anyway, enough about me etc, here are my thoughts on the draft at hand. My thoughts are my own, and may or may not coincide with Cisco's. Also, Noel, please don't take my criticism personally, it's about the working group document, not about you. :-)

High-level, birds-eye view:
* I think this document is confused. It doesn't really know if it's an architecture document, or an introductory text, or an introduction to the architecture document. I think that an architecture document and an introductory document serve different audiences and purposes, even though there may be some overlap in topics. The exact scope of each is perhaps somewhat debatable, but I think the main purpose of the introduction is to provide the reader an overview of LISP and familiarise him/her with the main concepts, emphasising understanding, perhaps even over technical precision. An introduction probably also doesn't need to exhaustively list every detail and component of the system. We should avoid having two very similar texts.
** I think the title "Architectural Introduction" adds to the confusion here, and I think it would be better to just call this document "Introduction to LISP", and aim for providing exactly that.

* I think there's a lot of background material. I think we should aim for "just enough" to understand the introduction to LISP, rather than a comprehensive study of "LISP in the context of the history of the internet"

* Looking at the contents…
** it looks like a VERY LONG introduction (37 pages if you print the HTML page). I think introductions should be a bit shorter, and less daunting. My first impression (with my LISP newbie hat on) is "Oh my goodness, I need to read all that just to get an idea about LISP?". I know that the prefatory note says otherwise, but you don't see that when you open up the HTML page and give it a quick scroll through.
** The design approach comes surprisingly late into the text (I'm not sure this is even the right document for that)
** Here are some sections I don't think are necessary for the introduction (again, just based on the table of contents; reading them may lead me to change my opinion), mostly because they sound like they're going into the nitty gritty detail that should be part of main protocol specs:

     4.4.  Interworking With Non-LISP-Capable Endpoints (maybe)

     4.5.  Security in LISP [or at least move it closer to the end]

     9.2.  UDP Encapsulation Details ("details")

     9.3.  Header Control Channel
       9.3.1.  Mapping Versioning
       9.3.2.  Echo Nonces
       9.3.3.  Instances

     9.4.  Probing
     9.5.  Mapping Lifetimes and Timeouts
     9.6.  Security of Mapping Lookups
     9.7.  Mapping Gleaning in ETRs
     9.8.  Fragmentation

     10.1. The Mapping System Interface
       10.1.1. Map-Request Messages
       10.1.2. Map-Reply Messages
       10.1.3. Map-Register and Map-Notify Messages

       10.2.1. Map-Referral Messages
     10.3. Reliability via Replication
     10.4. Security of the DDT Indexing Sub-system
     10.5. Extended Tools
     10.6. Performance of the Mapping System

     11.3. Proxy Devices
       11.3.1. PITRs
       11.3.2. PETRs
     11.4. LISP-NAT
     11.5. Use Through NAT Devices
       11.5.1. First-Phase NAT Support
       11.5.2. Second-Phase NAT Support
     11.6. LISP and DFZ Routing
       11.6.1. Long-term Possibilities
   12. Fault Discovery/Handling (maybe)
     12.1. Handling Missing Mappings
     12.2. Outdated Mappings
       12.2.1. Outdated Mappings - Updated Mapping
       12.2.2. Outdated Mappings - Wrong ETR
       12.2.3. Outdated Mappings - No Longer an ETR
     12.3. Erroneous Mappings
     12.4. Neighbour Liveness
     12.5. Neighbour Reachability
   13. Current Improvements
     13.1. Improved NAT Support
     13.2. Mobile Device Support
     13.3. Multicast Support
     13.4. {{Any others?}}

     B.1.  Old LISP 'Models' (maybe)

=> I'm not saying none of these should be mentioned, but I don't think each of them warrant a section of their own in an "introduction" document. I think things can be summarised a bit more to convey the main points.

* There is lots of stuff in brackets, which looks like it might be too important to be ignored, so perhaps it's not all suitable to be in brackets?
* It's good to define the intended audience:

   This document is an introduction to the entire LISP system, for those
   who are unfamiliar with it.

Abstract:

   LISP is an upgrade to the architecture of the IPvN internetworking
   system, one which separates location and identity (currently
   intermingled in IPvN addresses).

* I would be inclined to say "IPv4 and IPv6 internetwork", I think that, while technically correct, IPvN is a less often used term. Or at least I don't see it being used often. You could also just say "IP". I'd also drop the 'system', as I think an internetwork is a system already?
* What do you mean with 'currently intermingled in IPvN addresses'? Do you mean that location and identity are currently both expressed in IP addresses when using LISP? Or do you mean that in the current IP world, both location and identity is expressed with 1 IP address? I guess the latter, but I don't think it's particularly clear.

*  This is a change which has been
   identified by the IRTF as a critically necessary evolutionary
   architectural step for the Internet.

=> If this was wikipedia or an academic paper, I'd tag that with "citation needed".

1. Prefaratory Note
* Spello: "prefatory" is suggested by Google.
* Re 'Architectural Introduction' => see high level items above

* It is intended to both be easy to follow, and also to give

   the reader a choice as to how much they wish to know about LISP.
   Reading only the first part(s) 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.

=> Being easy to follow is good. I think it's also fine to provide a good high-level overview of the system in the first parts of the document. I don't think it's necessary to provide a very detailed understanding of the entire system as part of the introduction though, I think this is outside the scope of an introduction - after all, that's what all the other documents are there for, and I think a huge intro will just scare people off.

   This goal explains why the document has a somewhat unusual structure.
   It is not a reference document, where all the content on a particular
   topic is grouped in one place.  (That role is filled by the various
   protocol specifications.)  It starts with a very high-level view of
   the entire system, to provide readers with a mental framework to help
   understand the more detailed material which follows.  A second pass
   over the whole system then goes into more detail; finally, individual
   sub-systems are covered in still deeper detail.

* Sounds like there's way too much detail for an introduction, and I'm not sure it's necessary to cover one component thing three times in an introduction.

* I'm not sure an unusual structure helps understanding. Have you given this to someone new to LISP and asked them how much they understood? I tried that when I attempted to formulate a "LISP in 5 sentences" description (sample size of 1). The result was that the experiment worked, but my 5 sentences didn't.

   Note: 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.

* Excellent.

2. Background

* See high-level comment, I think the aim should be to provide "just enough"

* Now, having said that, I'm not sure that the "just enough" aim is actually fulfilled. I think that, apart from the first paragraph, the background section doesn't actually further the understanding of the document, as the bits in it are not necessary to understand LISP. You don't need to know when it was formed, how the history influenced it or when it became an RFC. I'd put those details into a 'history' appendix. [Todo: come back to this after I've finished reading the document and see what else would need to be added beyond the first paragraph]

*   It has gradually been realized in the networking community that
   networks (especially large networks) should deal quite separately
   with the identity and location of a node (basically, 'who' a node is,
   and 'where' it is).  At the moment, in both IPv4 and IPv6, addresses
   indicate both where the named device is, as well as identify it for
   purposes of end-end communication.

* Ok, this can be accepted as fact. I think however that it would be more useful to briefly introduce the location/id split by looking at an example:

Today, network nodes (routers, hosts, etc) typically have one or more IP addresses assigned to them. These IP addresses encode two bits of information: the location of a node, namely /which network/ the node is on, as well as a "host identifier". For example, the IP address 192.168.3.14, together with the subnet mask 255.255.255.0, refers to "host 14" on the network "192.168.3.0/24".

Of course there are many other ways to express location, and I guess this is just one example, but I think it's quite accessible (to pretty much anyone who's configured a static IP address). I hope it's correct enough and demonstrates some aspects of location and identity. If not, maybe we should find another example.

*   The distinction was more than a little hazy at first: the early
   Internet [RFC791<http://tools.ietf.org/html/rfc791>], like the ARPANET before it [Heart<http://tools.ietf.org/html/draft-ietf-lisp-introduction-01#ref-Heart>] [NIC8246<http://tools.ietf.org/html/draft-ietf-lisp-introduction-01#ref-NIC8246>], co-
   mingled the two, although there was recognition in the early Internet
   work that there were two different things going on.  [IEN19<http://tools.ietf.org/html/draft-ietf-lisp-introduction-01#ref-IEN19>]

=> I'd file this in the "LISP in the context of the history of the internet" (LicothoI) category, which I think is best documented in it's own draft. I'd summarise it in one sentence saying something like "The location/identity separation is not a newly discovered concept, it was recognised already in the early days of the internet [citation]", but at the moment I'm not sure where to best put it.

*  This likely resulted not just from lack of insight, but also the fact

   that extra mechanism is needed to support this separation (and in the
   early days there were no resources to spare), as well as the lack of
   need for it in the smaller networks of the time.  (It is a truism of
   system design that small systems can get away with doing two things
   with one mechanism, in a way that usually will not work when the
   system gets much larger.)

=> "LicothoI"
=> Can be replaced with a one-sentence summary
=> I don't think that the truism adds any value, and thus can be removed.

*   The ISO protocol architecture took steps in this direction [NSAP<http://tools.ietf.org/html/draft-ietf-lisp-introduction-01#ref-NSAP>],
   but to the Internet community the necessity of a clear separation was
   definitively shown by Saltzer.  [RFC1498<http://tools.ietf.org/html/rfc1498>] Later work expanded on
   Saltzer's, and tied his separation concepts into the fate-sharing
   concepts of Clark.  [Clark<http://tools.ietf.org/html/draft-ietf-lisp-introduction-01#ref-Clark>], [Chiappa<http://tools.ietf.org/html/draft-ietf-lisp-introduction-01#ref-Chiappa>]

=> Licothol

*   The separation of location and identity is a step which has recently
   been identified by the IRTF as a critically necessary evolutionary
   architectural step for the Internet.  However, it has taken some time
   for this requirement to be generally accepted by the Internet
   engineering community at large, although it seems that this may
   finally be happening.  [RFC6115<http://tools.ietf.org/html/rfc6115>]

Please could you point out exactly which bit of RFC6115 supports the above statement, especially the first sentence? Maybe I missed it. (I'm not commenting on whether or not I agree with the statement, after all I'm not part of the IRTF anyway, just on the reference)

*   The LISP system for separation of location and identity resulted from
   the discussions of this topic at the Amsterdam IAB Routing and
   Addressing Workshop, which took place in October 2006.  [RFC4984<http://tools.ietf.org/html/rfc4984>]

   A small group of like-minded personnel from various scattered
   locations within Cisco, spontaneously formed immediately after that
   workshop, to work on an idea that came out of informal discussions at
   the workshop.  The first Internet-Draft on LISP appeared in January,
   2007, along with a LISP mailing list at the IETF.  [LISP0<http://tools.ietf.org/html/draft-ietf-lisp-introduction-01#ref-LISP0>]

   Trial implementations started at that time, with initial trial
   deployments underway since June 2007; the results of early experience
   have been fed back into the design in a continuous, ongoing process
   over several years.

I think the above is useful background info, even in an intro, but belongs into a 'history' section, maybe in the appendix.

* LISP at this point represents a moderately
   mature system, having undergone a long organic series of changes and
   updates.

I think this statement would require regular updating as LISP matures, so I'm not sure it's suitable for a static RFC.

*   LISP transitioned from an IRTF activity to an IETF WG in March 2009,
   and after numerous revisions, the basic specifications moved to
   becoming RFCs in 2012 (although work to expand and improve it
   continues, and undoubtly will for a long time to come).

Perhaps slightly less useful background info, but probably OK for a history section.

* I think the History section should go into an appendix. We want to make it as easy as possible for newbies to pick up and understand LISP, and having less text between them and LISP means newbies are less likely to loose interest.

3. Deployment Philosophy

   It may seem odd to cover 'deployment philosophy' at this point in
   such a document.  However the deployment philosophy was a major
   driver for much of the design (to some degree the architecture, and
   to a very large measure, the engineering).  So, as such an important
   motivator, it is very desirable for readers to have this material in
   hand as they examine the design, so that design choices that may seem
   questionable at first glance can be better understood.

=> I think this paragraph doesn't add much value. It's 7 lines explaining why the next 8 lines are there…

   Experience over the last several decades has shown that having a
   viable 'deployment model' for a new design is absolutely key to the
   success of that design.  A new design may be fantastic - but if it
   can not or will not be successfully deployed (for whatever factors),
   it is useless.  This absolute primacy of a viable deployment model is
   what has lead to some painful compromises in the design.

This further motivates why we should care about a successful deployment model

   The extreme focus on a viable deployment scheme is one of the
   novelties of LISP.

So that sentence there the real content of this whole section? Considering the fact that there are more sections dealing with deployment, I think some merging and cutting needs to happen.. I'm thinking about 3.1-3.3., and 8. Design Approach (though I'll have more comments on those later). I think it's fine to say something like, "Given that the ease of deployment greatly influences the adoption of new technologies, one of the design goals of LISP stated that it should support incremental deployments, which provide benefits to the users from day one", or something along those lines. I think that would sufficiently summarise the whole section here, including 3.1.( Economics). I think sections 3.2 and 3.3 can similarly be summarised in one paragraph:

N.N Design Philosophy [this is just a sketch of the argument I'm trying to make, not a final wording suggestion]
…
Another important design goal of LISP stated that it should be easily deployable. This was motivated by the pragmatic insight that this would be key to widespread adoption. This was realised in three ways. Firstly, the cost of implementing LISP should be low in terms of complexity and number of nodes that need changing, and secondly the benefit in terms of added value (in the form of services or features) should be high. Furthermore, LISP should support and interoperate with and support existing protocols (e.g. IPv4, IPv6, TCP and UDP), and transition mechanisms should be provided.

I'd cut the section "3.3.  'Self-Deployment'"; I understand that a snowball effect is very desirable, but I'm not sure it furthers any argument at this point in time.

8<http://tools.ietf.org/html/draft-ietf-lisp-introduction-01#section-8>.  Design Approach

   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.

   This design philosophy is covered in detail in in [Perspective<http://tools.ietf.org/html/draft-ietf-lisp-introduction-01#ref-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.

=> This whole section is basically useless. It's only piece of real content is the reference to [Perspective].

To be continued…

Best regards!

Michiel

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 24 Jul 2013 08:24:44 -0400 (EDT)

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

    >> it looks like a VERY LONG introduction (37 pages if you print the HTML
    >> page). I think introductions should be a bit shorter, and less
    >> daunting. My first impression (with my LISP newbie hat on) is "Oh my
    >> goodness, I need to read all that just to get an idea about LISP?".
    >> I know that the prefatory note says otherwise, but you don't see that
    >> when you open up the HTML page and give it a quick scroll through.

    > I don't know how I could make it more prominent?

Now that I think about it, the way to hopefully help (I'm not sure I'd say
'fix totally' - you can't make _anything_ perfectly fool-proof) 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.

Of course, this will make the abstract one sentence longer, and it's _already_
long. But I see a not-very-necessary sentence I can delete, to avoid making it
even longer.

All, does this sound like a good thing to do?

     Noel

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 24 Jul 2013 09:51:13 -0400 (EDT)

> From: "Michiel Blokzijl (mblokzij)" <[email-masked]>

    > Reading your reply, I think that we just have very different
    > expectations of the introduction document.

Perhaps.. :-)

    > I think the document currently provides a reasonably comprehensive but
    > high-level overview of LISP, rather than an introduction, if that makes
    > sense.

That's a very good point: it _is_ as much an overview as it is an
introduction. (It's also the second, because it specifically caters to readers
who know nothing of LISP to start with.)

Should we rename it to "Architectural Overview", to better describe it? I'd be
OK with that. Although, since it is written as an introduction (i.e. a first
document to read), it's probably most accurate to call it an "Introductory
Overview"! :-) Although that's kind of clunky.

I'm basically happy with any of the three: it's up to the WG which to pick:
"Introduction", "Overview", "Introductory Overview". (But I'm not changing the
file name! That is something of a PITA, as I learned from the Perspective
document... :-)

    > By having a shorter document.. :)

Did you have any opinion about the idea of a one-sentence addition to the
abstract (see previous WG list email)?

    > I don't think there's anything fundamentally wrong with approach 2,
    > assuming you don't recurse ad inifinitum. However, I

I think we lost some text here?

    >>> Have you given this to someone new to LISP and asked them how much
    >>> they understood?

    >> A while ago. Not with recent versions.

    > Now you've made us all curious, what did they say? :)

I honestly don't recall - it's been over a year.

But I'll try the exercise again (I have a test subject in mind :-), and see
what they say.

    > Maybe it's worth tying this statement to "the time of writing", and say
    > it's constantly maturing - just to avoid people in the future dismissing
    > LISP as a solution to a problem requiring a "mature" solution.

Well, it does currently say "at this point", which I assumed was basically
synonomous with "time of writing", but I think your overall concern is viable,
let me see if I can tweak the text there to meet that potential issue.

    > But when you start having more justifying text than actual content you
    > start to wonder whether it might be easier to just "say it"? :)

Your point about the ratio of text lengths is a good one. Let me look at that,
and see if I can shorten the first part.

    Noel

---

From: "Vasileios Lakafosis (lakafosi)" <[email-masked]>
Date: Fri, 26 Jul 2013 00:19:08 +0000

Hi Noel,
overall, I believe there have been significant improvements in this version.
Below please find a few comments of mine.

General

[whole document]
- You tend to use the verb "switch" for xTRs. Is that correct/intended sensu stricto? Lato sensu I can understand…
- (you already have a question about this in the doc) You tend to use "binding" and "mapping" interchangeably. Do you see any benefit in sticking with just the second term perhaps?
- please choose between "user interface" or "client interface". I would go with the second one, as the first one can bring wrong associations to a totally new-comer.

[4.5] and [12.4]
You do include solutions/contributions offered when describing a LISP feature and it's real nice (given you are skipping technical details because of brevity of doc). This is _not_ the case, though, for sections:
- [4.5] Security
- [12.4] Liveness
Here you only discuss the necessity, rather than what they at least offer or intend to offer.

[5.7]
What do you mean by "application-specific data"?

[6.1] "now-normal"
I would put this in double quotes.

[6.2.3]
This section should not be so much tied to DDT. It should be highlighted that _any_ database that meets the requirements could be used. And there are plenty of examples. And this gives versatility to LISP.

[6.2.3.1] 5th paragraph
This seems wrong. The DDT leaf nodes _are_ MSs and, thus, do not "assign EID namespace blocks to MS's".

[6.2.3.1] 2nd paragraph "necessarily smaller"
Redundant as it cannot be larger anyways as only parts can be delegated to children.

[7.1]
It would be helpful to add a paragraph about the reason of/benefits from the existence of the LISP header.

[7.2]
You could add "as previously explained in Section XX"

[9.1]
- 2nd paragraph: "normally" -> "natively" better?
- 3rd paragraph: did you intend to say "despite the fact" or "although" instead of "because"?

[10.1.2]
What about negative ones?

[10.1.3] and elsewhere "and its AFI"
Why keep mentioning AFIs? Doesn't it go without saying?

[10.2]
- 3rd paragraph: You may want to use "DDT nodes" everywhere (as in the draft) instead of the term "servers". Just a suggestion.
- 6th paragraph: "{{I think this case has been mentioned already; check.}}" yes, it has been. So, I would remove the next paragraph "Delegations are…"

[13.2]
The way 13.2 is written (with all these problems outlined and no solutions provided) gives the impression to the new-comer that mobility does not work in LISP today, which is absolutely wrong (either physically "LISP-MN" or in a DC environment). At least, this is how I felt when I read it.

[13.4] " {{Any others?}}"
Since these "improvements" sections are so short anyways, what about adding a few words about LISP+SDN (LISP-enabled Openflow, opportunities in Openstack,

[whole document]
No need to introduce new paragraphs at:
- [6.2.2] between second and third paragraph
- [12.4] between 3rd and 4th paragraph

[4.2] 1st paragraph
no verb in the secondary "that" clause or confusing subject ("packets") if "switches" is the verb

[3.2] 3rd paragraph
Discussed this with you in my previous email (related to version "00").

For brevity reasons, I would still remove:
[3.1] " One might have the world’s best ’clean-slate’ design, but if it does not have a deployment plan which is economically feasible, it’s not good for much."

Structure-related comments

[5.5] and [13.2] Mobility
- Mobility (although indeed in different enough degree of instantiations) has been around since almost the early days of LISP itself. As such I wold remove it from improvements and move the [13.2] text into [5.5].
- No reference(s) provided in current [5.5]

[6.1.1]
- Shouldn't this section follow mapping [6.2]? And be a subsection of that one?
- 3rd paragraph -- Description of first effort seems too long (also compared to the rest ones). Feel free to drop out some details if possible.

[9] first paragraph
if [9.x] are "advanced topics" then it "automatically" makes them candidates for removal given the prior email discussion about keeping the _Intro_ document short. But I believe [9.1], [9.8], a few details in [9.2] are indeed (fundamental) helpful to be included in this document. Just pointing out in case you were looking to somehow cut down the size of the document.

[10] 1st paragraph
Here you refer to only "indexing subsystem" and the "mappings" although you mentioned _3_ subsections above [in 6.2.1].

[11.2]
Shouldn't [11.3], [11.4], [11.5] and [11.6] be subsections of [11.2]?

Thanks,
Vasileios

---

From: "Vasileios Lakafosis (lakafosi)" <[email-masked]>
Date: Fri, 26 Jul 2013 00:01:18 +0000

Hi Noel,

General

[whole document]

[4.5] and [12.4]

[5.7]

[6.1] "now-normal"

[6.2.3]

[6.2.3.1] 5th paragraph

[7.1]

[7.2]

[9.1]

[10.1.2]

[10.2]

[13.2]

[whole document]

[4.2] 1st paragraph

[3.2] 3rd paragraph

[6.1.1]

[9] first paragraph

[10] 1st paragraph

[11.2]

Thanks,
Vasileios

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 26 Jul 2013 16:35:49 -0400 (EDT)

> 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.
    > ... 

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