Subject: [lisp] AD review of draft-ietf-lisp-lig

From: Jari Arkko <[email-masked]>
Date: Fri, 29 Jul 2011 16:25:11 -0400

Thanks for sending me a few documents to read :-)

I'm starting with an easy one. This document is ready to move forward, I 
found no technical issues but I did find a few editorial issues. I have 
sent the draft forward to an IETF last call.

Technical:

None

Editorial:

Section 1 gives the usual RFC 2119 terminology, but I don't actually see 
why this draft would need to use these terms. This is an explanation of 
a tool that is based on Lisp protocols defined in other documents, 
right? Please delete section 1.

Also, please reformulate the definition of term "EID" so that it does 
not use the RFC 2119 keywords; a definition seems like the wrong place 
to use such keywords, and in case, the normative rules about the EIDs 
should probably only exist in one of the Lisp documents.

> ITR, ETR, PA addresses, xTR

These terms are not defined in this document. Please add them and 
possibly other missing terms to the terminology section  (or just expand 
them on first use and refer to a document that defines them).

> Sending Map-Requests to Map Resolvers provides a secure
> mechanism mechanism to obtain a Map-Reply containing the
> authoritative EID-to-RLOC mapping for a destination LISP site.
>   
s/mechanism mechanism/mechanism/

> an EMR is a Map-Request message
> which is encapsulated with another LISP header using UDP
> destination port number 4341

Please refer to the Lisp header specification and the one that defines 
port 4341.

> The cisco LISP prototype implementation has support for lig for IPv4

s/cisco/Cisco/g (I think)

>      titanium-simlo# lig self6
>      Send loopback map-request to 10.0.0.1 for 192:168:1:: ...
>      Received map-reply from 10::1 with rtt 0.044372 secs
>
>      Map-cache entry for EID 192:168:1:::
>      192:168:1::/48, uptime: 00:00:01, expires: 23:59:58
>                         via map-reply, self
>        Locator          Uptime    State  Priority/Weight  Packets In/Out
>        10.0.0.3         00:00:01  up     1/100            0/0
>        10::1            00:00:01  up     2/0              0/0
>   

What are the 192:168:1 etc addresses? Would it be better to use the IPv6 
example address space for these examples?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 29 Jul 2011 16:46:00 -0400

I forgot to say that if you have a possibility to fix the editorial 
issues, please issue a new draft (even if the last call is 
starting/started).

Jari