Re: [lisp] I-D Action: draft-ietf-lisp-introduction-03.txt

[Dino Farinacci <[e-mail]>]

> The side-by-side multi-coloured one at:
> 
>  http://tools.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-03.txt
> 
> is better, IMO.

Here are my comments Noel. Since copy and pasting the text gets messed up with the color-coded diff, I have enclosed screen captures of the diff’ed text and my comments follow.

This email message seems long but the comments are very brief and to the point. And many of the comments are not a request to change something but to express delight in the wording.

Want to give a special thanks to you for all the effort. I believe the interim meeting was really helpful. I hope others feel the same way.



I think this is a fine set of content for a Part I. Thanks for doing this.



Working “on” and working “with” is very subtle. I would be more clear if you mean, someone who just:

(1) Wants to know what it is.
(2) Wants to do an implementation of LISP.
(3) Wants to deploy someone else’s implementation of LISP.
(4) Wants to design a network using LISP.



This seems repetitive from the first paragraph. So I’d either one versus the other.



Put this in traditional ID format. If I don’t call you on it, I’m sure further down in the process will.



I like the way you worded this. It basically reflects what a lot of us feel about having a good balance of security and practicality.



I would order this based on building on the previous. And I think you accomplished that with the current ordering.



Why do you think it needs a fix?



Do you want to make a reference to LISP-MN, if and only if LISP is to be implemented in host stacks?



I think you can say since the EID has provider independence and address resuse is desirable in the EID namespace, then by introducing Instance-IDs, which are coordinated to be unique to a given mapping system, the VPN use-case just falls out with little changes to the LISP data-plane (and certainly no changes to the network core).



This looks great Noel!



I think they way you have done it, that two Parts work just fine and there is no need to have two documents and more overhead in processing more documents than necessary. So for the record, I vote for having one document.



How about:

Before describing each LISP component in more detail below, it is worth pointing out that the philosophical approach to the design was to require incremental deployability of the LISP architecture. To be practical at the engineering level, and to avoid changing infrastructure between unmodified EID-based hosts and strs as well as core infrastructure between xTRs, hard tradeoff decisions were made. The LISP community believes these choices will lead to rapid and non-disruptive LISP deployment.



Can you change to “… among different destination EID namespaces …”.



Or an ITR will get an SMR to do a new lookup which may replace the existing contents with a more updated set of contents.



You can say an source-EID (which is AFI-encoded) can be specified in a Map-Request. What also is important is the list of ITR-RLOCs, which is also AFI-encoded, so the Map-Replier can choose from a set of addresses to decide what the destination address of the Map-Reply should be. This helps when there are dual-stack xTRs and partially dual-stack network cores. Also, optionally, the mappings of the ITR, can be supplied (appended to the end of the Map-Request) in the ”Mapping Data” field.

It is this “Mapping Data” where an ETR that receives this Map-Request could glean information from the source-site requesting the mappings of the destination site.



I think you should phrase this to be consistent with RFC 6830. As in “For each RLOC-record in an EID-record entry, . . .”.



I would say an SMR is a Map-Request message with the Solicit-Map-Request bit set. And remove the parenthesis. 



Again, use terms “EID-record” and “RLOC-record”.



Deregistering is accomplished by sending a Map-Register register with a TT=0 for an EID-record. So a Map-Register can have a set of EID-records that are being “registered” or being “deregistered”.



It is actually a referral action field, that contains values “node-referral”, “ms-referral”, and “ms-ack”, respectively to your list above.



Since the ETR registers to multiple locations (i.e. Map-Servers), the Map-Servers that serve the EID-prefix are naturally replicated by the source of the registration.

And it is likely the map-servers themselves may not be able to talk to each other if different MSPs serve them up. So the customer (the ETR) is the only path to keep them in sync of the latest registration status.

I know you mention this further below, but if you could summarize it in just a couple of sentences, you have your “say something about sources” text.



But the source still does have a location, so the combination of source and group needs to be dealt with. Furthermore, the source EID information is not known to the core, and since multicast packets are forwarded based on (source, group) routing table entries, the source needs to be mapped to the RLOC namespace.



It is also import for multicast to work well with LISP. It actually came before LISP. ;-)




Yes, a PITR can use an ELP-encoded RLOC-record.



Maybe some marketing here would be good. That is, LISP can help with the size of the routing table growth and the same time deploying new services and use-cases described in section 7.

That’s all I have. Again, nice job and great effort.

Dino