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

From: Dino Farinacci <[email-masked]>
Date: Wed, 10 Aug 2011 10:59:04 -0700

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

Thanks for the quick review Jari. Sorry for the delay. See responses inline, a new draft attached with a diff file. I have submitted a new revision.

> 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.

Great news.

> 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.

Removed.

> 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.

Done.

>> 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).

Added.

>> 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/

Fixed.

>> 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.

Done.

>> The cisco LISP prototype implementation has support for lig for IPv4
> 
> s/cisco/Cisco/g (I think)

It is spelled correctly.  ;-)

>>     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?

Changed all references to IPv6 addresses to be in the prefix 2001:DB8::/32.

Thanks,
Dino/Dave