Michiel, thanks for the comments. Most of them produced significant
improvements in the document. Sorry it's taken me a while to get to them!
This is the first part; I will finish it off tomorrow.
Noel
--------
> From: "Michiel Blokzijl (mblokzij)" <[email protected]>
> 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" :)
I can easily believe that (such things would in fact fit better in the
'Perspective' document), but I'm too burned out to trawl through the entire
document and find the things that fall into that class. There will be a final
draft 'soon', and if you read that, please bring these to my attention.
[Later: I found one, the griping about lack of separate naming for interfaces
and stacks.]
> After reading more of this document, I think it starts to sound more
> like "A survey on LISP"?
I'm not sure quite what you mean by this, how a 'survey' might differ from an
'introduction' or an 'overview' (and which of the three this thing ought to
be).
> I hope my comments don't come across as overly negative..
Not to worry. If I think you're wrong, I'll say so! :-)
>> 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 have an entry for 'node' in the Glossary now.
> I think the bracketed bit just confuses readers, and I think it can be
> removed.
Assuming you mean the first one (about nodes), it is now elsewhere.
> 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.
Well, 'function' in a more general sense ('the function of the steering wheel
is to control the direction of the front wheels'), but yes, 'property' is
probably a better word - or it would be, if I hadn't removed 'function'
already in the earlier changes to this section... :-)
>> 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.
I'm going to leave it the way it is, as the terms "RLOC" and "EID" are
universal,
and it therefore seems odd to me to have them in parens.
>> 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?
Since the average node will have only one, yes!
>> 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], 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.
I see your point (although it does say "the RLOC(s) name interface(s)", not
'the node's interface(s)' :-).
I have re-arranged all this text substantially, to try and improve it. I do
think it's important to make that point that ideally, we should have the two
different classes of names different classes of objects; this is a
long-standing lack of clarify in the existing Internet architecture, and it
would be good fix this too, as well as the lack of L/I separation.
>> 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).
That's just an example, to aid in comprehension. But I have totally
re-organized all this too.
> 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"
Read RFC-1498 and http://www.chiappa.net/~jnc/tech/endpoints.txt.
> After all, L2 is a part of the communication stack, and that's to some
> degree bound to interfaces.
"Stack" is used as an alternative term for 'endpoint' (AKA "fate-sharing
region"). I have clarified this in the text too.
>> 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.
That's because it was a novelty to me: the basic concept of something like LISP
has been around for a long time (that was the Nimrod deployment plan), but
having
IPvN addresses as both inputs _and_ outputs was the novel insight, from my point
of view.
> 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."
I have re-organized this text too.
> 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.
I looked at this, and thought about it for a bit, but my concern is that if I
immediately jump into the concrete details people will only think of it in
low-level engineering terms. I know a lot of people habiturally think at this
level, but I'd like to at least try and get them to see things in a
higher-level way. I did tweak it a tiny bit, in an attempt to make it less
mystical.
>> 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.
True, done.
>> 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 ["Basic Approach"] says about what RLOCs
> should ideally be.
"Basic Approach" has been reorganized as a result of earlier comments.
>> {{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
6830 is irrelevant. I'm using 'binding' in the CS sense of the term. See
RFC-1498.
> I'd prefer to know the difference between the two before giving an
> opinion
'Binding' is the formal computer-science term. 'Mapping' is the term used in
LISP.
(Although, to be technical, 'binding' refers to the association between a
name, and an object. This association may be inherent [e.g. memory loctions,
disk blocks] or constructed [e.g. a file name], which involves a 'directory',
if I am recalling the jargon correctly. And I guess I have just answered my
quetion: the things in LISP aren't really 'bindings' in the computer science
sense of the word.)
> 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'.
I carefully define, and throughout the document try and carefully distinguish
between the 'mapping database' (the collection of mappings'), and the 'mapping
system' - the entire system of MR's, indexing subsystem (DDT), etc - which
allows clients to retrieve mappings. I may have some places where I didn't use
the right term, but if so, I'd like to fix them.
I have added some text here to define the second, and the difference between
them.
>> 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 is interesting. I'm not sure if I'd put it into a "further reading"
> section though.
But to talk about this in detail here would require a lengthy diversion into
details, de-railing the rolling out of the 'big picture' of the entire system.
Much as I would love to, I can't (in a linear document) talk about everything
in full detail at once.
> I probably would've summarised the first two paragraphs [of
> "Interworking With Non-LISP-Capable Endpoints"] into a sentence and
> merged it with the last one:
I did look at this, but it doesn't clearly make a number of points which are
in the original text, and which I think are important to convey. So I have
left this as it is.
> I would also provide references to the two approaches you introduced here.
Done.
> ["Security in LISP"]
> I would provide the brief overview first, and then say "for more
> details, go to.."
Well, but I wanted to flag for them, _before they read the section_, that this
is only a high-level gloss on the topic... and having done that, it seemed
like a good place to stick the reference. I mean, otherwise, I have to have a
whole sentence at the end, saying 'for more see xxxx'.
> 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.
Well, yes. LISP Security is an incredibly complex topic, with quite different
mechanisms all over the place; there is simply no simple way to describe it
briefly. Even a page would be a total gloss - and I don't want to spend an
entire page this early in the document on a massive derail into a
semi-detailed description of 5 different security mechanisms.
I can probably edit this down to make the points it does in less space, though.
> ["Initial Applications"]
> 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.
That's possible a worth-while thing to write somehere, but to do it here would
have taken a lot more space. I'm not sure we can afford it - what's the
cost/benefit of discussing this, versus the space it will take to do so?
Also, this is 'Introduction to LISP', not 'Why LISP is the greatest things
since sliced bread'.
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
