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

"Darrel Lewis (darlewis)" <darlewis@cisco.com> Tue, 14 October 2014 17:57 UTC

Return-Path: <darlewis@cisco.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 60D401A9141 for <lisp@ietfa.amsl.com>; Tue, 14 Oct 2014 10:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level:
X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 GSoMQDWUI_Oi for <lisp@ietfa.amsl.com>; Tue, 14 Oct 2014 10:57:05 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AEC71A912C for <lisp@ietf.org>; Tue, 14 Oct 2014 10:57:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8658; q=dns/txt; s=iport; t=1413309425; x=1414519025; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vGPzzz9C0W3i2ndSlaJViBhFSnoMAEqViXqRJVX3tMs=; b=mtZkQpAWuu2n3IPB9O2UDprTLupdnLGYXnv/N6NsmVgCaB5Q7kxKXE2a P0GMqD4qwuoPtVxJgKHqdJmODXtGWvcAnylT09RSV0TH7T6zA13rBuPGT qERImZCmAgNvWZNbQrhcQhgOxEG5MyVQ9Lj6d09lXLBumif2+VEpocVbZ Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FAM1iPVStJV2c/2dsb2JhbABbgw5TWATMNIdNAoEVFgF9hAMBAQIBAXkFCwIBCEYhESUCBAENBYgqAwkIDcAWDYZOAQEBAQEBAQEBAQEBAQEBAQEBARmOE4F/MweDLYEeBZF5hEKEf4IRgWqNU4ZUggAGGIFZbAGBR4ECAQEB
X-IronPort-AV: E=Sophos;i="5.04,718,1406592000"; d="scan'208";a="363231756"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 14 Oct 2014 17:56:18 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9EHuIGq019740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Oct 2014 17:56:18 GMT
Received: from xmb-rcd-x15.cisco.com ([169.254.5.125]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 12:56:18 -0500
From: "Darrel Lewis (darlewis)" <darlewis@cisco.com>
To: Luigi Iannone <luigi.iannone@telecom-paristech.fr>, "Joel M. Halpern" <jmh@joelhalpern.com>
Thread-Topic: Review of draft-farinacci-lisp-rig-03.txt
Thread-Index: AQHP59gnkha9Q7pPrU+HjyCtl1SB4Q==
Date: Tue, 14 Oct 2014 17:56:18 +0000
Message-ID: <6581A638-DB12-4C6D-AB87-7E15CDB19D4B@cisco.com>
References: <684A8FEC-35CF-40CA-AE2D-16FA61C6C11A@telecom-paristech.fr> <16712457-9A07-44FC-8F9F-DCFB442BA9EE@gmail.com>
In-Reply-To: <16712457-9A07-44FC-8F9F-DCFB442BA9EE@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.74.229]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <50F3FEA8D00439489219DE10AA4EB759@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/bIs8lHnHawhWnR4nQK2wrW6MAGE
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 17:57:12 -0000

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>