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

From: [email-masked] (Noel Chiappa)
Date: Mon, 21 Oct 2013 21:42:07 -0400 (EDT)

> A New Internet-Draft is available from the on-line Internet-Drafts
    > directories.
    > ...
    > The IETF datatracker status page for this draft is:
    > https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction

So I was asked to release a new version, to show the changes made at the
Interim WG meeting, which I have now done, after some more changes, directed
by the Interim, were also taken care of. I haven't managed to get all the
small ones called for later in the document done, but all the main changes
should now be in.

    > A diff from the previous version is available at:

The side-by-side multi-coloured one at:

  http://tools.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-03.txt

is better, IMO.

The changes made at the Interim were major trimming of the Abstract, Prefatory
Note, Deployment Philosophy, and Initial Applications sections, along with a
whole host of small editing tweaks throughout the document.

Since then, responding to direction from the Interim on larger things we
couldn't do in real time, I have:

- Formally divided the document into "Part I" and "Part II" (it already had
that division, but now we have labels on it). Alas, I couldn't get these to
work the way I wanted; Terry mentioned a "toc" attribute to <section>, but it
did exactly the opposite of what I wanted (which was to have them appear in
the TOC, but not have section numbers; it still assigned them numbers, but
didn't show them in the TOC). I will try a number of hacks to see if I can
get it to do what I want, but I am not hopeful. If anyone can make XML2RFC do
what I want, I'd be appreciative.

- Created an 'Initial Glossary' at the start of the document, to contain the
most-used and more general terms. (The detailed glossary of LISP-specific
terms remains at the end; most would be 'forward references' if placed at the
start of the document, and couldn't really be fully understood without reading
the document, so... why put them at the start, to delay getting to the meat of
the content, not to mention baffling naive readers, etc, etc?) Also, a whole
raft of terms have been added, and the text has been changed to consistently
use them (I hope). That all allowed a number of 'in-line' definitions early in
the text to be removed, helping it flow better.

- There is also now a consistent syntax to indicate when a term is used which
is defined in a glossary.

- Changed the document to use a number of alterntive terms. (In particular,
'DDT node', used to refer to nodes in the namespace abstraction hierarchy,
turned out to be a conflict with a different use of that term elsewhere, so it
has been replaced with 'vertex'.)

- A large amount of text about perfomance studies in "Mapping Cache
Performance" (in "Major Functional Subsystems") has been moved later down to a
new section "xTR Mapping Cache Performance" (in "xTRs"), and a brief synopsis
left in its old place.

- The section "Long-term Possibilities" (from "LISP and DFZ Routing") was
moved out of the document, to the new "Improvements" document (which will have
to be renamed to "Improvements and Evolution", as a result).

I'm going to keep working on this, and hope to release the last version to
which we make major changes around the time the I-D window opens again; the
version after that I hope will only need spelling/grammar/typos etc taken

	Noel

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 27 Oct 2013 14:25:32 -0700

>  http://tools.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-03.txt

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