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

[Dino Farinacci <[e-mail]>]

>> From: Dino Farinacci <[e-mail]>
> 
>> 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.

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

>> 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...

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

>>> 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.

Mapping System Interface is a fine compromise. No prob.

>>> 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.)

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.

> 
>>> 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.

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.

> 
> 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.

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

>> 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! :-)

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.

>>> [[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.

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!
> 
> 	Noel

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