Subject: Re: [lisp] Comments on draft-ietf-lisp-introduction-01 (tranche #2)

From: [email-masked] (Noel Chiappa)
Date: Mon, 30 Sep 2013 14:42:06 -0400 (EDT)

OK, here's the rest. Usual caveats apply (thing I agreed with aren't
mentioned, etc).

	Noel

--------

    > ["Multi-Homing"]
    > I think it'd be nice if this section explained at least briefly how LISP
    > actually helps with multi homing (priority & weights).

I think those are more important for Traffic Engineering, no? I mean, if you
care _which_ ETRs traffic flow through, then you need those fields - but
caring which ETR traffic comes in through is by definition TE, no?

    > ["Traffic Engineering"]
    > I think the first two sections are somewhat repetitive in terms of
    > explaining that the internet was not designed with TE in mind.

Well, the content is not actually repetitous, since the second one talks about
how TE is really functionally a routing thing. And I would have said that the
second is probably excess non-relevant detail, except that the para after that
goes on to talk about how doing TE with LISP is slightly 'hammer-nail', and I
think that needs the preceeding paragraph to make sense.

    > I actually went and looked in section 6.2. The only bit that refers to
    > TE is this:
    > ...
    > If it's just this one sentence, maybe it's worth stating that the
    > priorities and weights can be used for [ingress] TE?

Well, you have a point about the thinness of what's said at the location of
the forward pointer, but alas I don't think I have a better place to point to
- details of applications of LISP are, for better or worse, outside the scope
of this document: to include them all would greatly increase the size of the
document. I have added a reference to the LISP-TE document.

And moving that content back here isn't really in the cards either: if I moved
all the content at forward references back, it would just create others. You
can't have 'everything in front of everything else'.

    > ["IP Version Reciprocal Traversal"]
    > "Note that LISP 'automagically' allows intermixing of various IP
    > versions for packet carriage"
    > Are words like 'automagically' often used in RFCs?

No, but it made me sad to take it out - the IETF is so humourless that it
can't tolerate a tiny bit of whimsy?

    > I would somehow tie in that this is because LISP can use different
    > versions of IP (or other protocols?) for the EID and RLOC space, or is
    > that too technical?

Well, I could have put in an allusion to that - except that that capability is
not mentioned until later. Again, everything before everything else
problems... :-(

    > ["Local Uses"]

    > Is it worth mentioning the words 'network virtualisation' in this
    > context, or is that too buzzwordy?

It is pretty buzzwordy, but it's also pretty common - and also, I gather, one
of the most common uses of LISP in practise - so I had already added a bit
about it (although not that specific term - it just talks about "virtual
networks, and virtual machine mobility").

    > ["Mapping Cache Performance"]
    > I think this section is more appropriate for a survey than for an
    > introduction.

The problem is that the first thing one hears from a lot of people, when
talking about LISP, is 'oh, the caching won't work'. So I think we have to
talk about it.

I did earlier decide that this section was too long, with too much detail, and
so it has been reduced in size considerably,

    > ["Mapping System"]
    > I think it would be better to use the terms 'mapping system' and mapping
    > database' consistently.

I have tried to do this (as explained earlier), but I haven't recently done a
front-> back readthrough, and so I may have missed some. I will be doing such
a read-through 'soon' (as soon as I finish going through all the comments),
and I'll try and catch any remaining problems at that point. If anyone sees
any, of course, please let me know.

    >> However, the block may be (and often is) as small as a single EID.

    > I'm not sure if "often" is correct. I took the HTML of
    > http://www.lisp4.net/lisp-site/, discarded everything outside the main
    > table, and all lines that didn't contain a '/' (trying to keep all the
    > prefixes), sorted them and removed duplicates. That left me with 690
    > prefixes, 141 (~20%) of which were /32 or /128 (I didn't find /32 IPv6
    > addresses). I think the numbers make sense for an estimated nr of 355
    > sites, as it's on average ~2 prefixes/site.

???? If I'm reading you correctly, out of 690 entries, ~20% are host entries?
How is this not "often"?

Not that it really matters - I can drop the "and often is" if it's an issue.

    > ["Interface to the Mapping System"]

    >> Re: (MSs - admittedly a poorly chosen term, since their primary function
    >> is not to respond to queries

    > I'd be half inclined to remove the note about it being a poorly chosen
    > term - maybe some day enabling proxy replies will be the recommended
    > deployment method?

Dino mentioned this too. I dunno, the terminology  _really_ confused me for a
while, and it took a while to get it straight. If people really don't like it,
I can remove it, though.