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