Re: [lisp] Comments to draft-ietf-lisp-introduction-02 (tranche #2)

[[e-mail] (Noel Chiappa)]

    > Noel, here are my comments.

After a (unfortunately long) diversion into multicast (from one of your
comments), here is the second tranche of replies to your comments.

As before, I did not _always_ agree with your comments, and the ones where I
did not, I have attempted to explain my reasoning for disagreeing. (Ones I
agreed with I have edited out, to keep the size down.)

	Noel

----


    >> The data plane functions in ITRs include ...
    >> [[S2: Anything else?]]

    > Well, possibly doing some control functions are storing some state. Like
    > echo-nonces, or adding to counters for per RLOC/per-EID packet counters.

The low-level housekeeping stuff (like counters) is too detailed to be
mentioned at this early stage (and in any case, it's not really a procotol
thing, so I'm not sure I should mention it at all - although I suppose those
counters are in the MIB, now that I think about it?

As for the piggybacking (sucks teeth..) again, probably too early to mention
that. There is a whole sub-section later (9.3.  "Header Control Channel")
which covers it in some detail.

    >> checking for the reachability and liveness of their neighbour ETRs; and
    >> checking for outdated mappings and requesting updates.

    > Remove "neighbour". ETRs are anything but close to the ITRs.

At the 'LISP packet switch' level, they are neighbours. See the section
"Another Packet-Switching Layer" in the Perspectives document. Two BGP
neighbours attached to an ATM network were still referred to as 'neighbours',
even though there might have actually been a number of ATM packet switches
etween them, right?

By definition, _at the LISP layer_, an ITR has as a 'LISP neighbour' the ETR
it is sending packet to...


    >> In the ETR, control plane functions include
    >> [[S3: Missing anything here? ...]]

    > Yes, missing a big part. Registering their mappings to the mapping
    > system. That is what ETRs do in the control plane. And they also process
    > Map-Requests and send Map-Replies.

Err, it says "interacting with the mapping sub-system ... and answering
requests for mappings"!! Which is just those two functions you just listed?

I have added a few words about what the first entails, but I don't want to
expand on it too much (remember how you told me not to be repetitive :-), and
this is covered in great detail in section 10.1, "The Mapping System
Interface".


    > This is too detail

You're behind the curve :-), I had already decided to move a lot of it:

  http://www.ietf.org/mail-archive/web/lisp/current/msg04635.html

    > the data may change in the future to obsolete the numbers provided
    > above.

I did worry about that (and in fact referred to it directly "Obviously, these
studies are all snapshots of a particular point in time, and as the Internet
continues its life-cycle they will increasingly become out-dated."), but I
felt that I needed to be a bit more concrete than 'Oh, it will work fine';
after all, how many people are actually going to track down the paper and slog
through 10 pages or so _more stuff_ it to see what it says?

Anyway, I'll see if on the next pass through I can trim it down and balance
(as everying in this blasted document) on the fine edge between 'not enough'
and 'too much'.

    > There will be a lot more research so citing just these 4 will make this
    > document incomplete. We don't want that.

Yes, but the demand caching of mappings is the thing that gets the most FUD
about the entire design. I feel there have to be some hard data put right out
front to show that this has been studied in some detail, and that there is
actual empirical data to show that it will work. And I can only cite what's
available _when the document_ was written - we cannot wait for more work to be
done!

    > I think you should summarize what properties were considered and what
    > high-level conclusions were made.

Easy to say! But I have tried to boil this section down considerably, and
tried to say something about the conclusions (more than just simply 'it will
work', which is in some sense the highest level conclusion that was reached).


    >> 6.2.2.  Interface to the Mapping System

    > Earlier in this commentary, I suggested "API".

Like I said, to me "API" means "programming interface", and I'm thinking in
somewhat more general terms.


    >> Similarly, the client interface to the indexing system from an ETR's
    >> point of view is through devices called Map Servers (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 would strike the text in the parens. They are serving registrations so
    > the term would be good as anything else.

Hmm. It took me a long time to get used to the terminology: I kept thinking
that a server was something that the clients of the system would go to for
information, and of course MS's don't generally do this (they are neither the
machines that the ITRs go to, nor the machines that give mappings to the ITRS
- they're just the penultimate leaves in the delegation tree).

I have changed the wording, perhaps it's better now?


    >> ETRs send registration control messages (Map-Register packets) to an
    >> MS, which makes the information about the mappings which the ETR
    >> indicates it is authoritative for available to the indexing system. The
    >> MS formulates a reply control message (the Map-Notify packet),

    > Change "Map-Notify" to "Map-Reply".

Huh? I'm talking about _registration_ here. Map-Notify is the acknowledgement
to a Map-Register, no? Map-Replies are in response to Map-Requests, right?


    >> robustness, any particular node in the DDT delegation tree may be
    >> instantiated in more than one redundant physical server machines.
    >> Obviously, all the servers which instantiate a particular node in the
    >> tree have to have identical data about that node.

    > Don't use "server" here because it could imply or mislead the reader to
    > think "Map-Servers". I think the best noun is "DDT-nodes" or describe
    > from a parent node's reference and call them child nodes as you did in
    > the uprevious paragraph.

I am trying to draw a distinction between the _delegation tree_ (which is
abstract), and its instantiation as data in a set of servers. This _exactly_
parallels DNS, which has a similar distinction. (Although I find DNS's
somewhat confusing, with zones and all, and the ability to have more than oneA
level in a zone - if I am remembering that correctly!)

Anyway, I'm happy to switch to a different word for 'server', but it can't be
'node' - I am already using that to refer to the nodes in the abstract
delegation hierachy.


    >> This case follows the processing of a typical user packet (for
    >> instance, a normal TCP data or acknowledgment packet associated with an
    >> already-open TCP connection) as it makes its way from the original
    >> source host to the ultimate destination.

    > A TCP Syn or data packet has no special difference at the network layer.
    > So why do you have to say this?

Because I want to emphasize that this description applies to a packet which is
_not_ the first packet exchanged, since _that_ packet might provoke a mapping
cache miss, and reload - a more complex situation, and one which is covered in
a separate description, below. I have added a few words to make this clear.

    >> When the packet has made its way through the local site to an ITR
    >> (which is also a border router for the site)

    > The ITR does not need to be a border router for the site. It could be
    > directly connected to a source, or even a PE router. So just strike the
    > text in the parens.

But in this _example_ it is. But you are correct that the wording is
inappropriate, so I have modified it.

    >> (Typically, like many ARP implementations, the original user packet
    >> will have been discarded, not cached waiting for the mapping to be
    >> nfound.  When the host retransmits the packet, the mapping will be
    >> there, and the packet will be forwarded.)

    > I would strike the text in the parens. And add a short paragraph
    > indicating the packet could be dropped, queued, or sent natively. Where
    > the latter means it would flow toward a PITR.

I seem to recall a discussion in which I was informed that queueing packets
while waiting for the mapping to arrive was unlikely to be a viable strategy;
there are just too many ways to Lose.Big doing that. Since I'm trying to show
what will happen to a _typical_ packet, I think this is the one to focus
on. But I will mention the other possibilities, improve the text about
dropping, and put it all in a new para.

    >> [[E3: Should we given the detail on at least on DDT step?]]

    > I think you missed explaining that if a Map-Request is not going to a
    > Map-Server that intermediate DDT-nodes return referrals.

That's now covered as a result of the re-write above.

    > And when you explain that you should indicate that they provide keys for
    > the children so subsequent Map-Referrals can be verified.

My sense is that that's too much detail for this 'Examples' section, which is
here to provide people with a rough picture of how typical packets get
handled. I will mention that in the detailed section on DDT, though. And
there is an entire section, "Security of the DDT Indexing Sub-system", which
covers DDT's security in more detail.


    >> The UDP checksum is zero because the inner packet usually already has a
    >> end-end checksum, and the outer checksum adds no value. [Saltzer] In
    >> most exising hardware, computing such a checksum (and checking it
    >> at the other end) would also present an intolerable load, for no
    >> benefit.

    > I am feeling this is too much detail. Why does someone who wants an
    > intro need to know the detail about a checksum?

Well, now we're into the part of the document that starts to go into more
detail.

Yes, this is more 'design insight' than strictly an introductory description,
but... this is supposed to be an architecture document, right?  And there
isn't a natural place to put it in the perspective document, which focuses
on larger issues; this is a very localized, small, one.


    >> Note that lack of a response is not necessarily _proof_ that something
    >> has gone wrong - but it stronly suggests that something has, so other
    >> actions (e.g. a switch to an alternative ETR, if one is listed; a
    >> direct probe; etc) are advised.

    > Change to ".. a direct RLOC probe".

Sorry, I don't see the benefit of that? The text is clear that the ETR is being
probed? If there was some kind of probe that was particularly advised, I could
see listing it, but I fail to see how mentioning "RLOC" helps.


OK, enough for now. Another tranche 'soon' (probably tomorrow).

	Noel