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

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 14 October 2014 18:00 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8611A90FD for <lisp@ietfa.amsl.com>; Tue, 14 Oct 2014 11:00:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ejd8Hd-WwqYI for <lisp@ietfa.amsl.com>; Tue, 14 Oct 2014 11:00:49 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ABDC1A9100 for <lisp@ietf.org>; Tue, 14 Oct 2014 11:00:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 415EF2406AC; Tue, 14 Oct 2014 11:00:47 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.1.90] (107-194-85-212.lightspeed.nsvltn.sbcglobal.net [107.194.85.212]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 74F062406AD; Tue, 14 Oct 2014 11:00:46 -0700 (PDT)
Message-ID: <543D64CD.1030104@joelhalpern.com>
Date: Tue, 14 Oct 2014 14:00:45 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Darrel Lewis (darlewis)" <darlewis@cisco.com>, Luigi Iannone <luigi.iannone@telecom-paristech.fr>
References: <684A8FEC-35CF-40CA-AE2D-16FA61C6C11A@telecom-paristech.fr> <16712457-9A07-44FC-8F9F-DCFB442BA9EE@gmail.com> <6581A638-DB12-4C6D-AB87-7E15CDB19D4B@cisco.com>
In-Reply-To: <6581A638-DB12-4C6D-AB87-7E15CDB19D4B@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/yX9qMRnuM_DHn5myXw5d2JKsHKE
Cc: LISP mailing list list <lisp@ietf.org>
Subject: Re: [lisp] Review of draft-farinacci-lisp-rig-03.txt
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Oct 2014 18:00:53 -0000

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 <farinacci@gmail.com> 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>
>
>