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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
