Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review. The purpose
of the review is to provide assistance to the Routing ADs. For more
information about the Routing Directorate, please see
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-lisp-06.txt
Reviewer: Ron Bonica
Review Date: 3/15/2010
IETF LC End Date: TBD
Intended Status: EXPERIMENTAL

Summary:

I have significant concerns about this document and recommend that the
Routing ADs discuss these issues further with the authors.


Major Issues:

o Architectural Issues

- Tunnel Liveness - The document says little about what happens when a
tunnel connecting iTR to eTR fails? Does temporary black-holing result?
What is the restoration mechanism?

- UDP Checksum - When an iTR formats the LISP UDP header, it sets the
UDP checksum to zero. This is in violation of RFC 768.

- The document should say something about cases in which NATs and middle
boxes are deployed between iTR and ETR. Will those boxes continue to work?

o Caching Issues

- The caching policy is not well specified. Therefore, I am worried that
the cache might become an easy target for DoS attacks. Consider the
following scenario:

An opponent discovers the EIDs of 100 hosts behind an ITR. The opponent
then sends a steady stream of 50 pps to each of those 100 hosts. Each of
those packets has a unique, valid and spoofed source address. Each
packet also causes its recipient to send an ICMP port unreachable
message to the spoofed source. The ITR cache may be overrun.


o Migration issues Considerations

- During the migration period, when an ITR receives a packet, it must
determine whether that packet's destination address is an EID or an
RLOC. The document isn't clear about how the ITR does this. One
possibility is to encode that information in the IP address. Another is
to query the network to find out. While the first solution may work for
IPv6, it won't work well for IPv4. The second solution presents
performance problems regardless of IP version.

- LISP's goals are best achieved when the entire Internet is surrounded
by xTRs (i.e., at the end of migration). However, it is impossible to
know when that state has been achieved. The document should say
something about when an operator has completed its migration effort and
what benefit it can expect to reap at that time.

Minor Issues

- Terminology section defines many terms that are already commonly
understood.

Nits:


  == You're using the IETF Trust Provisions' Section 6.b License Notice from
     12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
     http://trustee.ietf.org/license-info/)


 ----------------------------------------------------------------------------

  ** The document seems to lack an IANA Considerations section.

  ** There are 5 instances of lines with non-RFC2606-compliant FQDNs in
the document.

  == There are 10 instances of lines with private range IPv4 addresses
in the document.  If these are generic example addresses, they should be
changed to use any of the ranges defined in RFC3330 (or successor):
192.0.2.x, 198.51.100.x or 203.0.113.x.


  Miscellaneous warnings:

----------------------------------------------------------------------------

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL',
'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.
Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is
what you
     mean).

     Found 'MUST not' in this paragraph:

     LCM:   The format is one of the control message formats described
     in this section.  At this time, only Map-Request messages and PIM
     Join-Prune messages [MLISP] are allowed to be encapsulated.
Encapsulating
     other types of LISP control messages are for further study.  When
     Map-Requests are sent for RLOC-probing purposes (i.e the P-bit is set),
     they MUST not be sent inside Encapsulated Control Messages.


  Checking references for intended status: Experimental

----------------------------------------------------------------------------

  ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)

  == Outdated reference: A later version (-02) exists of draft-jen-apt-01

  == Outdated reference: A later version (-05) exists of
     draft-meyer-lisp-cons-03

  -- Unexpected draft version: The latest known version of
     draft-ietf-lisp-interworking is -00, but you're referring to -01.

  == Outdated reference: A later version (-02) exists of
     draft-farinacci-lisp-lig-01

  == Outdated reference: A later version (-01) exists of
     draft-meyer-lisp-mn-00

  == Outdated reference: A later version (-04) exists of
draft-ietf-lisp-ms-03

  -- No information found for draft-mathy-lisp-dht - is the name correct?

  == Outdated reference: A later version (-08) exists of
     draft-lear-lisp-nerd-04

  == Outdated reference: A later version (-02) exists of
     draft-iannone-openlisp-implementation-01

  == Outdated reference: A later version (-05) exists of
     draft-narten-radir-problem-statement-00

  == Outdated reference: A later version (-09) exists of
     draft-ietf-mip4-rfc3344bis-05

  == Outdated reference: draft-ietf-pim-rpf-vector has been published as RFC
     5496

  -- No information found for draft-handley-p2ppush-unpublished-2007726 - is
     the name correct?

  == Outdated reference: draft-ietf-shim6-proto has been published as
RFC 5533


     Summary: 3 errors (**), 14 warnings (==), 3 comments (--).

     Run idnits with the --verbose option for more detailed information
about
     the items above.