Re: [lisp] Review of draft-farinacci-lisp-rig-03.txt

["Joel M. Halpern" <[e-mail]>]

I actually like the document.  But it is not at all clear that the WG 
can do anything useful with it.
Most importantly, if we were to adopt it now, we still could not work on 
it until we clear the blocking documents.

Is there a reason not to publish it as in informational independent 
submission?

Yours,
Joel

On 10/14/14, 1:56 PM, Darrel Lewis (darlewis) wrote:
> Chairs,
>
> It seems to me that this document (lisp-rig) is overdue for WG adoption.  Its an implemented, key management component/utility which is essential to the operation of the deployed LISP-DDT implementation.
>
> Is there a plan for adoption, or a reason to wait?  Thanks!
>
> -Darrel
> On Jul 2, 2014, at 2:12 PM, Dino Farinacci <[e-mail]> wrote:
>
>> See comments inline. A new draft and diff file is enclosed. What I didn't respond to I agree with and made changes to the draft.
>>
>>
>>>> to store and propagate those mappings globally.  This
>>>>     document focuses on the LISP-DDT [LISP-DDT] mapping database system.
>>>>
>>>>     The 'rig' is a manual management tool to query LISP-DDT mapping
>>>>     database hierarchy.  It can be run by all devices which implement
>>>>     LISP, including ITRs, ETRs, PITRs, PETRs, Map-Resolvers, Map-Servers,
>>>>     and LISP-DDT nodes, as well as by a host system at either a LISP-
>>>>     capable or non-LISP-capable site.
>>>>
>>>>     The LISP-DDT 'rig' tool is similar to the 'lig' [RFC6835] tool in
>>>>     that they are both diagnostic tools to query a distributed database.
>>>>     However, 'rig' is used to find Map-Servers serving an EID-prefix,
>>>>     specifically within a LISP-DDT mapping database framework.  And 'lig'
>>>>     can be used on top of any mapping database system to retrieve
>>>>     locators used for packet encapsulation.
>>>>
>>>>
>>>> 3.  Definition of Terms
>>>>
>>>>
>>> I would put the definitions of terms as appendix. This document is not authoritative on these
>>> definitions. An appendix to help reading is enough.
>>
>> Is it okay if I keep it this way. All the protocol documents have the Definition of Terms section right after the Introduction section. I would like to keep it consistent.
>>
>>> Check the eid block documents as example:
>>>
>>> http://tools.ietf.org/html/draft-ietf-lisp-eid-block-09
>>> http://tools.ietf.org/html/draft-ietf-lisp-eid-block-mgmnt-01
>>>
>>>
>>>>     Endpoint ID (EID):   An EID is a 32-bit (for IPv4) or 128-bit (for
>>>>        IPv6) value used in the source and destination address fields of
>>>>        the first (most inner) LISP header of a packet.  The host obtains
>>>>
>>> [snip]
>>>>
>>>> Farinacci, et al.      Expires September 18, 2014               [Page 7]
>>>> Internet-Draft   LISP-DDT Referral Internet Groper (RIG)      March 2014
>>>>
>>>>
>>>> 4.  Basic Overview
>>>>
>>>>
>>> Just to ease even more the reading wouldn’t be helpful put how mapping lookup works in DDT?
>>>
>>> Something describing by text the content of slide 7 of:
>>>
>>> http://tools.ietf.org/agenda/83/slides/slides-83-lisp-8.pdf
>>
>> Added a opening paragraph to the Basic Overview section. Let me know if you think it is sufficient. I wanted to keep it brief and to the point.
>>
>>>
>>>>        message exchange.
>>>>
>>>>     A possible syntax for a rig command could be:
>>>>
>>>>     rig [instance-id <iid>] <eid> to <ddt-node> [follow-all-referrals]
>>>>
>>>>     Parameter description:
>>>>
>>>>     [instance-id <iid>]:   is the instance-ID portion of the Extended EID
>>>>        used as VPN identifer.  When the DDT hierarchy is not configured
>>>>        with instance-IDs, this argument is omitted from the command line.
>>>>
>>>>     <eid>:   is either a Fully Qualified Domain Name or a destination EID
>>>>        that is being queried in the LISP-DDT mapping database.
>>>>
>>>>     <ddt-node>:   is the RLOC address of any DDT-node in the DDT
>>>>        hierarchy.  This can be the DDT root node, a DDT transit node, or
>>>>        a DDT Map-Server.
>>>>
>>>>     [follow-all-referrals]:   when this keyword is used each referral
>>>>        RLOC is queried so rig can descend the entire DDT hierarchy
>>>>        starting from the node <ddt-node>.  When this keyword is not used,
>>>>        one of the referral RLOCs will be selected to descend a branch of
>>>>        the DDT hierarchy.
>>>>
>>> The text above is unclear.
>>>
>>> If follow-all-referrals is present then rig follows all RLOCs: that is OK.
>>>
>>> If the option is not present why should the rig command follow the first RLOC?
>>
>> It doesn't. It is up to the implementation to decide which referral node is used. And most implementations I am aware of will hash the EID-prefix being looked up (from the Map-Request) will be used so you can load-split Map-Requests across referral nodes.
>>
>>> The initial description of rig (first paragraph section 4) just states the upon reception of a Map-Referral,
>>> its content is displayed to the user, it does not mention that any RLOC is followed to go down the DDT tree.
>>>
>>> Why not adding a “follow-first-referral” option to actually follow the first RLOC.
>>
>> The implementations don't support such an option because that is not the way it was implemented or described in the DDT spec.
>>
>>>
>>>> 5.  Implementation Details
>>>>
>>>>     The cisco LISP prototype implementations on IOS and NX-OS has rig
>>>>     support for IPv4 and IPv6 EIDs in either the default instance or a
>>>>     non-zero instance-ID.
>>>>
>>>>     The IOS syntax is:
>>>>
>>>>     rig [instance-id <iid>] <eid> to <ddt-node> [follow-all-referrals]
>>>>
>>>>     The NX-OS syntax is:
>>>>
>>>>     rig [instance-id <iid>] <hostname> | {<eid> | <eid6>}}
>>>>                             to {<ddt-hostname> | {<ddt> | <ddt6>}}
>>>>
>>>>     Here is some sample IOS output:
>>>>
>>>>     Router# rig 12.0.1.1 to 1.1.1.1
>>>>
>>>>     Send Map-Request to DDT-node 1.1.1.1 ... node referral, rtt: 0 ms
>>>>     EID-prefix: [0] 12.0.0.0/16, ttl: 1440
>>>>     referrals: 2.2.2.2
>>>>
>>>>     Send Map-Request to DDT-node 2.2.2.2 ... node referral, rtt: 0 ms
>>>>     EID-prefix: [0] 12.0.1.0/24, ttl: 1440
>>>>     referrals: 4.4.4.4, 5.5.5.5
>>>>
>>>>     Send Map-Request to DDT-node 4.4.4.4 ... map-server acknowledgement,
>>>>                                              rtt: 0 ms
>>>>     EID-prefix: [0] 12.0.1.0/28, ttl: 1440
>>>>     referrals: 4.4.4.4, 5.5.5.5
>>>>
>>>>
>>>>
>>>>
>>> Any other implementation available? Steffann has a ddt_query script written in python...
>>
>> I would be glad to add the output if Steffan is willing to provide it.
>>
>>>
>>>
>>>> 8.  References
>>>>
>>>> 8.1.  Normative References
>>>>
>>>>     [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
>>>>                September 1981.
>>>>
>>> Delete this reference it is never cited.
>>
>> It is in the definition of "Routing Locator (RLOC)":
>>
>>       <t hangText="Routing Locator (RLOC): ">A RLOC is an IPv4
>>        <xref target="RFC0791" /> or IPv6 <xref target="RFC2460" />
>>        address of an egress tunnel router (ETR). A RLOC is the output
>>        of an EID-to-RLOC mapping lookup. An EID maps to one or more
>>        RLOCs. Typically, RLOCs are numbered from
>>        topologically-aggregatable blocks that are assigned to a site at
>>        each point to which it attaches to the global Internet; where
>>        the topology is defined by the connectivity of provider
>>        networks, RLOCs can be thought of as PA addresses. Multiple
>>        RLOCs can be assigned to the same ETR device or to multiple ETR
>>        devices at a site.</t>
>>
>>>
>>>>
>>>>     [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
>>>>                STD 13, RFC 1034, November 1987.
>>>>
>>> This is used in the definition of terms section and since this document is not authoritative on
>>>   those definitions it might be better to put the reference as informative.
>>>>
>>>>     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>>>>                Requirement Levels", BCP 14, RFC 2119, March 1997.
>>>>
>>> As far as I can see there is not 2119 notation actually concerning rig, IMHO we can drop this reference.
>>
>> I will keep it there since there is a reference to 2119 and we MAY add such language in the future.
>>
>> Dino
>>
>>
>>
>>
>>
>> <rfcdiff-lisp-rig-03-to-04.html><draft-farinacci-lisp-rig-04.txt>
>
>