Last Call Review of draft-ietf-lisp-eid-block-10

Request Review of draft-ietf-lisp-eid-block
Requested rev. no specific revision (document currently at 13)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-04-28
Requested 2015-04-19
Authors Luigi Iannone, Darrel Lewis, David Meyer, Vince Fuller
Draft last updated 2015-04-26
Completed reviews Genart Last Call review of -03 by Meral Shirazipour (diff)
Genart Last Call review of -10 by Meral Shirazipour (diff)
Genart Last Call review of -12 by Meral Shirazipour (diff)
Genart Telechat review of -12 by Meral Shirazipour (diff)
Opsdir Last Call review of -10 by Ron Bonica (diff)
Opsdir Last Call review of -12 by Ron Bonica (diff)
Assignment Reviewer Ron Bonica 
State Completed
Review review-ietf-lisp-eid-block-10-opsdir-lc-bonica-2015-04-26
Reviewed rev. 10 (document currently at 13)
Review result Serious Issues
Review completed: 2015-04-26



I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document is on the Informational Track and is a direction to IANA to allocate a /32 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP).

Major Issues

Section 3 (Rationale and Intent)

- Bullet item 3 (Early LISP destination detection) should be removed. Please see the LISP WG mailing list thread that begins with

. In particular, look at

- Bullet item 4 (Traffic Engineering) is unclear. Are you applying TE inside or outside of the LISP site? If outside, the presence of a LISP header identifies LISP traffic.  If inside, the traffic could be marked otherwise. Could you say more about the use-case?

- Bullet item 5 (Transition mechanism) should be removed. It doesn't add any value beyond bullet item 5 and section 4.

Section 4 (Expected Use)

- Paragraphs 2 and 3 contradict each other regarding whether IPv6 EID prefixes can be advertised into BGP as anything more specific than a /32.

Section 7 (Routing Considerations)

- If Section 4, Paragraph 3 is correct, a PITR can advertise the IPv6 EID block as a single /32. However, it cannot advertise more specifics. If this is the case, the PITR has to carry traffic for every LISP site in the world, regardless of whether it can collect money from the site. Will this work?

Ron Bonica