Skip to main content

An Architectural Introduction to the Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-introduction-15

Discuss


Yes

(Brian Haberman)

No Objection

(Benoît Claise)
(Jari Arkko)
(Joel Jaeggli)
(Stephen Farrell)
(Ted Lemon)

Note: This ballot was opened for revision 11 and is now closed.

Adrian Farrel Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2015-03-03 for -12) Unknown
Thank you for this document. It is really helpful to have a clear
introduction to LISP, and I appreciate the hard work that has gone into
producing this text.

I have a small Discuss that is easily fixed. The essence is that you 
should limit this document to a description of LISP and not try to use
it to bash other solutions.

In Section 4.2

   On the contrary BGP is a
   push architecture, where the required network state is pushed by
   means of BGP UPDATE messages to BGP speakers.

You will be aware of RFC 5291 and the use of ORF to make BGP a pull-mode
protocol.

(I won't say to you that LISP is push mode because a Map-Reply pushes 
the mapping information from the map server to the client :-)

So, my advice is to describe LISP in this document and to not make
comments about other systems. It isn't a beauty contest and it isn't
wise to try to say "my system is better/different from yours".

The solution is to just remove this sentence.

Similarly in 7.1

   BGP is the standard protocol to implement inter-domain routing.  With
   BGP, routing information are propagated along the network and each
   autonomous system can implement its own routing policy that will
   influence the way routing information are propagated.  The direct
   consequence is that an autonomous system cannot precisely control the
   way the traffic will enter the network.

   As opposed to BGP, a LISP site can strictly impose via which ETRs the
   traffic must enter the the LISP site network even though the path
   followed to reach the ETR is not under the control of the LISP site.

Let's not get into the "BGP this, BGP that" debate. Just remove the 
first paragraph and the first four words of the second paragraph. That
way you avoid all contention and write a document about LISP.
Brian Haberman Former IESG member
Yes
Yes (for -11) Unknown

                            
Spencer Dawkins Former IESG member
Yes
Yes (2015-03-03 for -12) Unknown
I'm a Yes because this draft is helpful to the largely uninitiated (that would include me), but I was consistently encountering questions that Adrian's Discuss and Comments answered, so I'd encourage you to work through his Comments, as well as his Discuss.

Beyond that:

In this text:

3.3.1.  LISP Encapsulation

   ITRs encapsulate data packets towards ETRs.  LISP data packets are
   encapsulated using UDP (port 4341), the source port is usually
   selected by the ITR using a 5-tuple hash of the inner header (so to
   be consistent in case of multi-path solutions such as ECMP [RFC2992])
   and ignored on reception.  
   
would you ever use "virtual xTRs" with the same outermost IP addresses?
If not, fine, but if so, would you need to use different destination ports to disambiguate them? Or does the Instance ID provide enough isolation to meet this need?

I ask because adding virtual hosts to HTTP was a drag, so best for me to ask early!
   
Further in the same paragraph, in this text:

   A particularity of LISP is that UDP
   packets should include a zero checksum [RFC6935] [RFC6936] that it is
   not verified in reception, LISP also supports non-zero checksums that
   may be verified.  This decision was made because the typical
   transport protocols used by the applications already include a
   checksum, by neglecting the additional UDP encapsulation checksum
   xTRs can forward packets more efficiently.
   
I'm wobbling between "should include a zero checksum" and "also supports non-zero checksums". Is that text saying something like this?

   LISP data packets are often encapsulated in UDP packets that
   include a zero checksum [RFC6935] [RFC6936] that is not verified 
   when it is received, because LISP data packets typically include
   an inner transport protocol header with a non-zero checksum. By 
   omitting the additional outer UDP encapsulation checksum, xTRs 
   can forward packets more efficiently. If LISP data packets are 
   encapsulated in UDP packets with non-zero checksums, the outer
   UDP checksums are verified when the UDP packets are received, as
   part of normal UDP processing.
Alia Atlas Former IESG member
(was Discuss) No Objection
No Objection (2015-04-14 for -13) Unknown
Thanks for addressing my discuss and comments.


I support Adrian's discuss.  In a similar vein:

In Sec 3.2: Please either remove the claim of "Such LISP capable
routers, in most cases, only require a software upgrade." or explain
how you can justify the need to add and remove new encapsulations and
handle the various flag triggers and caching at line rate.  There is
no need for such marketing in this document.

1) Sec 1, second paragraph:
   "LISP creates two separate namespaces, EIDs (End-host IDentifiers) and
   RLOCs (Routing LOCators), both are typically syntactically identical
   to the current IPv4 and IPv6 addresses."
   
   What does "typically" mean?  As far as I'm aware, they are
   syntactically identical.  This is reiterated in Sec 3.2; are you just
   trying to preserve the point of architectural freedom?  I've found the
   third instance of insisting that the EID or RLOC now is only "typically" 
   an IPv4 or IPv6 address. Please lose "typically".  Minorly, the ,
   before both should be a ;.

2) top paragraph of p.4:
  "The initial motivation in the LISP effort is to be found in the
   routing scalability problem [RFC4984], where, if LISP is completely
   deployed, the Internet core is populated with RLOCs while Traffic
   Engineering mechanisms are pushed to the Mapping System."

   Instead of "LISP is completely deployed" to "LISP were to be
   completely deployed" - making it subjunctive.  

3) Last paragraph in Sec 1:
   "This document describes the LISP architecture, its main
   operational mechanisms as its design rationale."

   I think you mean 

   "This document describes the LISP architecture and its main
   operational mechanisms as well as its design rationale."

4) In Sec 3.1, second paragraph:
   "Locator/Identifier split: By decoupling the overloaded semantics
      of the current IP addresses the Internet core can be assigned
      identity meaningful addresses and hence, can use aggregation to
      scale."
   I assume that you mean "topologically meaningful addresses" instead
   of "identity meaningful addresses".
Benoît Claise Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Kathleen Moriarty Former IESG member
(was Discuss) No Objection
No Objection (2015-04-14 for -13) Unknown
Please do look at the other suggestions from the review as they should help clarify a few points in the draft and provide the background needed for an introduction draft.  While the edits in the security section help enough that I'll let it go, the other problems were not highlighted here and will rely on subsequent drafts elaborating on the threats and security considerations besides DoS.  I haven't read the threats draft yet, so hopefully that covers the full set.  Thanks.
https://www.ietf.org/mail-archive/web/secdir/current/msg05415.html
Richard Barnes Former IESG member
No Objection
No Objection (2015-03-04 for -12) Unknown
I would also find this document much improved if the authors could address Adrian's comments, as well as those in Radia's SECDIR review.
Stephen Farrell Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Ted Lemon Former IESG member
No Objection
No Objection (for -12) Unknown