Subject: Re: [lisp] Comments to draft-ietf-lisp-introduction-02 (Tranche #1)

From: [email-masked] (Noel Chiappa)
Date: Sat, 17 Aug 2013 21:47:17 -0400 (EDT)

> From: Dino Farinacci <[email-masked]>

    > Noel, here are my comments.

Thanks for your lengthy, and most helpful, comments. To keep the reply in
usably-sized chunks, I'm going to send it in tranches, this being #1.

I did not _always_ agree with your comments (big surprise :-), but most of
them I did, and the ones where I did not, I have attempted to explain my
reasoning for disagreeing. See below (I have edited stuff out, in an attempt
to keep the size of this reply down - only kept what was needed for context).

    > to draft-ietf-lisp-introduction-02

Well, 1.5 actually... :-)

	Noel

----

    > There are many places where you have parenthetical comments. In most of
    > those cases, the text I think is important so I urged you remove the
    > parens but keep the text.

Other people have made the point that I use too many parenthesized comments.
I agree, but I don't know the fix! The problem is that, in my brain,
'everything is connected to everything else', but... text is linear (and RFCs'
aren't hypertext... :-). So I don't have a good notation for 'this is
important, but a diversion from the main point I'm trying to make here', other
than those blasted parantheses...

But I'll look at them, and see what I can do about getting rid of as many as I
can...

    >> 5.  Initial Applications
    > I think multicast should move from section 13 to here. It is pretty
    > fundamental as all the use-cases you list above.

I agree with you that it doesn't belong in "On-Going Improvements", and I
_will_ move it from there. I don't think it belongs in "Initial Applications",
though, because by your reasoning, xTRS belong there too, because they are
"fundamental as all the use-cases".  Let me ponder where it belongs best - at
this point, I'm thinking probably a section of its own, just after "10. The
Mapping System"?

    > Could you name this "Data Plane - XTRs".

Good idea, done. And I'll describe the xTRs subsystem that way in the earlier
text, too.

    > And can you name this "Control Plane - The Mapping System".

Ditto. (I see I have used the term 'control plane' some already, but I will
make greater use of it.)

    >> 10.1. The Mapping System Interface
    > Just a suggestion but maybe not necessary but do you like the term
    > "Mapping System API"?

Not really, because to me an API is more of a language thing ('to do X, call
the subroutine 'foo' with arguments x, y and z'). A generalized description of
how two subsystems interact I think of as their interface; But I'm not stuck
on that term; if someone has a better alternative, I'm happy to switch.

    >> 10.1.3. Map-Register and Map-Notify Messages

    > Just an FYI we have Map-Notify-Ack messages as well.

Ahh, they're not in RFC's 6830 or 6833? Oh, I see, Google shows the in the NAT
ID; I will cover them there (in a new section, to allow people to find them
easily/quickly in the ToC).

Wait a minute, they aren't in that I-D! I only got one hit on that term in
Google! What are they? (But I'll leave the new section for NAT control
messages, it's good to call those new control messages out.)

    >> 10.2. The DDT Indexing Sub-system
    > I am really glad that DDT is listed here but does it imply a precedent
    > or a favoring of one transport system versus others?

Well, 10 is "The Mapping System" in general, so covering DDT in one sub-section
of that seems appropriate.

    > Especially since DDT is not yet RFC but ALT is.

I have moved ALT to an appendix, as I view it as obsolete (and to keep the
readable text size down, keeping something obsolete in the main sections seem
like a poor choice). Are people actually still using it? Should it not be in
an appendix?

    > Is there a way to talk about the indexing system without mentioning any
    > specific one?

Well, there is that intro section in "The Mapping System" which talks
generically about how the mapping system uses an indexing subsystem, and the
next section ("The Mapping System Interface") is also generic.

I do need to talk a bit about how DDT works, and so I have to get specific
about it at some point, and that point seems like it ought to be where it is
now? I mean, we do need to cover the basic structure of DDT at some point, no?

I have expanded the intro section a tiny little bit, to talk a bit more about
the indexing sub-system generically, but I'm not sure there's much else I can
do?

    > I think describing the Map-Referral message is important. The fact that
    > you mention all LISP messages in one place is goodness.

Actually, they aren't all in one place! The basic ones (Map-Request,
Map-Reply, etc) are in with the xTRs, but others are described along with the
'piece' where they are used, e.g. Info-Request and Info-Reply in the NAT
section.

This seems to me to be better for naive readers - a bald list of all LISP
message types, without an understanding of the parts of the system they are
used in, is not, I think, the best way to go in a _learning_ document (as
opposed to a _reference_ document, where that arrangement _would_ be the best
way to go).

    > Having said that, a mention for the Info-Request and Info-Reply for
    > NAT-traversal will be important as well.

Actually, they were in the document (in "Improved NAT Support"), just didn't
have their own sub-section (so they'd show up in the ToC). They do have their
own sub-section now (see above).

    >> 12.4. Neighbour Liveness
    >> 12.5. Neighbour Reachability

    > We have never used the term Neighbour. Can you use "RLOC Liveness" and 
    > "RLOC Reachability"?

My thinking in using "neighbour" was to tie across to the exact same problem
in routing protocols, in line with this mental picture I have where I want people
to see the network of LISP data-plane nodes are being a packet-switching system,
just like any other.

I'm uncomfortable using the term "RLOC Reachability" because to me an RLOC is
a name, and names aren't reachable - the _thing_ the RLOC names might be
reachable or not, but the name is just a name.

How about "ETR Reachability" (or, perhaps better yet, "Neighbour ETR
Reachability")?

    >> 1.  Prefatory Note
    >> {{This section can probably be edited down somewhat.}}

    > Let's see if I can help.

I'm going to skip this for the moment, OK? I'll cover it in a separate reply.

    >> 2.  Background

    >> 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.  (A more detailed history of this evolution
    >> is in Appendix B.1.)

    > Remove the parens and just put in an reference to the B.1 anchor.

Sorry, which parens? There are two sets! :-) I ditched the first set, replaced
with ','s. Should I kill the second set too? I feel they are a little more
useful than the first set.

    >> The on-going LISP project is an attempt to provide a viable path
    >> towards this separation.  (A brief history of the LISP project can
    >> be found in Appendix B.2.)  As an add-on to a (large) existing system,

    > Remove the parens but keep the text.

Same question - both sets - and same reply about those around the appendix
pointer (I ditched the others here too).

    >> it has had to make certain compromises.  (For a good example, see
    >> [Perspective], Section "Residual Location Functionality in EIDs".)
    >> However, if it reaches near-ubiquitous deployment, it will have two
    >> important consequences.

    > I would again remove the parens but keep the text.

Again, I do think these appendix pointers are good places to use ()'s. (If I
had easy access to footnotes, I'd have put them in one, but I don't...)

    >> 3.1.  Economics

    > I thought this section was great!

Thanks!

    >> 4.1.  Basic Approach
    >> 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.

    > Not sure if this is the best place to mention it, but do you want to say
    > anything about how EIDs and RLOCs can be of any address-family and have
    > multi-tuple encodings?

I did add there a _brief_ mention that LISP already has the capability to use
other namespaces. I didn't want to go into too much depth on those
capabilities because it's too early in the document. Should I include a
forward reference to the existing more extensive discussion? (Which was
originally in section 10.1.1. "Map-Request Messages", now in 6.2. "Mapping
System" - see below.)

I decided I should I say something more detailed than the brief note in "Basic
Approach" about the multi-namespace stuff before the reader gets all the way
to "Map-Request Messages", so I did so in 6.2. "Mapping System".

And the point about being able to map to compound names - I'm not sure I cover
that anywhere in the Intro document! Let me think about where to put it - it
is in the Perspectives document, where I cover namespaces in a lot more depth.
But not everyone who reads this will read that...

I think I found a good place to put a quick ref here, with a cross-ref to more
coverage in the Perspectives document (in "6.2. Mapping System").

    >> 4.2.  Basic Functionality

    >> LISP augmented packet switches [[O2: do we need a new term for these
    >> things, or is 'router' OK, or should we use an existing, but
    >> uncomittal term, like 'device' - I guess I will call them 'LISP
    >> devices' to start with, and 'xTRs' once I have introduced that
    >> term]]

    > I think "LISP router" is okay, well-known and obvious. But if you want
    > to generalize to refer to LISP-MNs as well then we should call it a
    > "LISP node". And you should say that a LISP node is a router, switch or
    > LISP-MN that supports LISP.
    > The term "device" could lend itself to not make people think that the
    > LISP node may not be virtual

You have good points there, but I need to think about this a bit; I think I
need to come up with clear terminology, and use it consistently throughout.

I have used (in a couple of places) the term "LISP node" to mean 'host behind
an xTR. I definitely need a separate term for that - any suggestions? 'LISP
served host' is a bit too clunky... :-)

"LISP router" might be OK as a replacement for "LISP device", which I agree
could be confusing. All xTRs are _by definition_ routers, so I think I am OK
with that. I think "LISP router" is probably better than "LISP node" for that
purpose.

I'm not sure what use - if any - "LISP node" might be; it's a bit too generic
to have an obvious meaning in the mind of a naive reader (the way "LISP
router" does).

And I will make sure to enter these terms in the glossary! :-)

(Something I have not made as much use of as I should have. I will attempt to
upgrade it significantly, and add not just things that are acronyms, but other
things too.)

    >> The lookup is performed through a 'mapping system', [[O3: the existing
    >> LISP documents aren't wholly consistend on this name, many call it the
    >> mapping database, but I want to stick with 'mapping system', to
    >> emphasize its unity in its own right]]

    > That is fine, but right here call it "... through a 'mapping database' =
    > or 'mapping system' ..." and then just use 'mapping system' throughout =
    > the document.

To me, the 'mapping database' is nothing more, and nothing less, than the
entire collection of mappings. It is a subset of the 'mapping system', which
includes both the database, and also the 'stuff' used to gain access to it
(the MRs, the indexing sub-system, etc).

I will carefully define these terms in the glossary, and make sure they are
used consistently throughout the document.

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

    > I don't think there is a difference. So let's stick with mapping so we
    > don't obsolete the text in the RFCs.

OK, sounds good, done.

    >> 4.3.  Mapping from EIDs to RLOCs
    >> The mappings from EIDs to RLOCs are provided by a distributed (and
    >> potentially replicated) database, the mapping database, which is
    >> the heart of LISP.

    > Can you change to ".. which is the heart of the LISP control-plane."

Actually, it really is the heart of the entire system, in my eyes. After all,
LISP is a system whose goal is to 'separate location and identity', and at
that level, it's clear that a directory of bindings (aka the mapping database)
is a key component of that highest-level architectural goal for the system as
a whole. So if you don't mind, I'm going to leave it?

    >> Mappings are requested on need, not (generally) pre-loaded; in other
    >> words, mapping are distributed via a 'pull' mechanism.

    > Well pre-loading could be done by the implementation so you should
    > probably not make a reference to it.

Well, it's a bit of a balancing act, because I don't want people to think it's
_only_ ever only going to be able to operate as demand loaded, but at the same
time, I don't want (this early in the document) to spend a lot of time side-lining
into that question. Hence the subtle "(generally)" (although that text is now
slightly different as a result of changes made in response to earlier points).

    > And for NAT-travesal, once you get the address of an RTR, you install a
    > default map-cache entry. That is a preload because the cache is
    > repopulated before any packet arrives.

And that is way too detailed to be this early! But I would put a note in the
section on NAT ... if I understood the point! Can you explain a bit more?  (A
default map-cache entry would seem to send all traffic to wherever it points -
the RTR, I am assuming from context, since you don't say exactly - or is that
incorrect? Mass confusion in my brain at this point! :-)

    >> 4.4.  Interworking With Non-LISP-Capable Endpoints

    >> The capability for 'easy' interoperation between nodes using LISP,
    >> and existing non-LISP-using hosts (often called 'legacy' hosts) or
    >> sites

    > I think this paragraph needs rephrasing because it came across to me
    > that there are LISP-hosts and legacy hosts that don't run LISP. But the
    > fact of the matter is there are hosts in LISP sites that do not run
    > LISP. So just say there are LISP sites where addresses are in the
    > mapping database and there are non-LISP sites where addresses are
    > advertised to the underlying routing system.

Yes to the basic point (better clarity on what a 'LISP host' is), but I don't
think "where addresses are advertised to the underlying routing system" is the
best definition of a non-LISP site - since LISP sites are normally advertized
too, for backward compatability.

Probably a better definition is the inverse of the first part - i.e. 'not in
the mapping database' - although actually, probably the best definition of a
'LISP host' is 'something with an xTR between it and the rest of the network'.

    >> To allow such interoperation, a number of mechanisms have been
    >> designed.  This multiplicity is in part because different mechanisms
    >> have different advantages and disadvantages (so that no single
    >> mechanism is optimal for all cases), but also because with limited
    >> field experience, it is not clear which (if any) approach will be
    >> preferable.

    > Can you change to "... multiplicity is in part because design tradeoffs
    > are allowing a choice to be made when more field experience is
    > obtained"

That reference to 'design tradeoffs' is a bit too terse, I think, to make the
first point I was trying to make; I have used your alternative text for the
second; hope that's OK?

    >> LISP, like DNS, needs to be _capable_ of providing 'the very best'
    >> security there is.

    > I would add "... security there is, at a reasonable cost."

Doesn't the very next paragraph make that point? I will add a brief mention of
cost there.

    >> the approach taken is to thorougly analyze what LISP needs for
    >> security, and then design, in detail, a scheme for providing that
    >> security. Then, steps can be > taken to ensure that the appropriate
    >> 'hooks' .. are included at an early stage .. Later on, the design can
    >> be fully specified, implemented, and deployed.

    > This is making it sound like we have no security and it is to be
    > started.

Good point.

    > You should say that an initial form of security is placed in the API to
    > sign and secure Map-Replies as well as to validate Map-Referrals in
    > DDT.

That's a bit much detail to have this early, I think, but I will make the
basic point (that LISP does already have security), and include forward refs
to the greater detail (the first one is already covered, as is the second one;
however, you forgot Map-Register, etc, the security for which I _didn't_ yet
cover in the usual level of detail for this document, but now have done so).

    > We should say that this amount of security is adequate for the start of
    > deployment and experience will tell us if more mechanism will be
    > required.

[s]if[/s] when! :-) But I will make your basic point, that what we have now
is what we need now, and experience will tell us when we need to upgrade.

    >> 5.5.  Mobility

    > You should say that sessions can survive across moves as well as better
    > packet stretch compared to traditional schemes.

OK, will do.

    >> [[A6: What about recursive tunneling?  Do we need an 'advanced usage
    >> cases' section?]]

    > Just make a reference to the main RFC 6830.

I looked in 6830, but there didn't seem to be a specific, detailed section on
recursive tunneling? Also, recursive tunneling is a _technique_, not an
application in itself, so I'm not sure this is where to mention it anyway.

    > Also in section 5, you should include a multicast section, indicating
    > an opportunity to encapsulate multicast in unicast. And it allows for
    > group addressing to be local to the sites attached to the core. So there
    > is less group allocation coordination among the core and the sites.

Good points. I have inserted a 'Multicast' section, just before "Local Uses",
and covered the points there. (If you think of more _applications_ for
LISP-Multicast, I can list them here too.)

    > This is also true for encapsulating one address-family in another. So
    > that could use a mention somewhere in the applications section.

There is an "IP Version Reciprocal Traversal" sub-section in "Initial
Applications"; I have added a brief mention of multicast mutual encapsulation.

    > Have a very short section and use this wonderful picture that Albertoa
    > drew up:
    > You'll have to draw it in ascii.

I like that diagram a lot (although it has a minor 'error', at least for the
normal case; the Map-Reply only goes from the MS directly back to the ITR if
the ETR has requested proxy Map Replies).

    > Just try not repeating yourself.

I have tried not to do that too much, although I am always mindful of the old
(I think it was US Army dictum) for making sure something gets through: tell
them what you're going to tell them, then tell it to them, and then tell them
what you told them! Although I have tried to not simply repeat things, but to
add extra depth each time I touch on something again.

Enough for now... more in the next tranche!

	Noel

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 18 Aug 2013 18:10:46 -0700

> usably-sized chunks, I'm going to send it in tranches, this being #1.

Thanks for the reply. Where I agree or have no response, I have snipped out text. So see the responses inline.

> than those blasted parantheses...

Just put them in full sentences. Add nouns and verbs and you should be done.

> on that term; if someone has a better alternative, I'm happy to switch.

Mapping System Interface is a fine compromise. No prob.

> messages, it's good to call those new control messages out.)

Right because Map-Notifys are only used to acknowledge Map-Registers. We use Map-Notify-Acks for unsolicited Map-Notifys when VM-mobility is the use-case. But since VM-mobility is not in charter we could not justify putting the new message type in.

Perhaps when we recharter and add use-cases, we can add them in. I hope so.

> reachable or not, but the name is just a name.

Well you need to connect the intro with the specs. And in the specs we use RLOC Reachability. You don't want readers who are going to read from beginning of document set to end to have to remap the terminology. I am sorry that the term we used is not to your satisfaction but we shouldn't introduce terminology inconsistency. That is not going to help anyone.

> useful than the first set.

I was referring to (A more detailed history of this evolution is in Appendix B.1.) from above.

> incorrect? Mass confusion in my brain at this point! :-)

I was just stating that a preload can be done via protocol mechanism versus implementation mechanism. And just to reference it via the NAT-traversal design would be helpful. Either way is okay with me.

> application in itself, so I'm not sure this is where to mention it anyway.

Yes, you are right to classify it that way. A use-case is in draft-farinacci-lisp-te.

> Enough for now... more in the next tranche!

If you need any clarification on what I snipped out, let me know. I'd prefer to just read the next rev and do a diff so I can see the decisions you made.

Thanks for the reply.
Dino