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

From: Luigi Iannone <[email-masked]>
Date: Tue, 1 Jul 2014 16:29:35 +0200

Hi,

I had the time to have a look to the rig document. Hereafter is my review.

ciao

Luigi

> 
> 
> Internet Engineering Task Force                             D. Farinacci
> Internet-Draft                                               lispers.net
> Intended status: Experimental                                    A. Jain
> Expires: September 18, 2014                             Juniper Networks
>                                                              I. Kouvelas
>                                                                 D. Lewis
>                                                            cisco Systems
>                                                           March 17, 2014
> 
> 
>                 LISP-DDT Referral Internet Groper (RIG)
>                       draft-farinacci-lisp-rig-03
> 
[snip]

> 2.  Introduction
> 
>    LISP [RFC6830] specifies an architecture and mechanism for replacing
>    the addresses currently used by IP with two separate name spaces:
>    Endpoint IDs (EIDs), used within sites, and Routing Locators (RLOCs),
>    used on the transit networks that make up the Internet
>    infrastructure.  To achieve this separation, the Locator/ID
>    Separation Protocol (LISP) defines protocol mechanisms for mapping
>    from EIDs to RLOCs.  In addition, LISP assumes the existence of a
>    database 
I would put “distributed database"

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

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

>    When the rig command is run, an Encapsulated Control Message Map-
>    Request is sent for a destination EID.  When a LISP-DDT Map-Referral
>    is returned, the contents are displayed to the user.  The information
>    displayed includes:
> 
>    o  A delegated EID-prefix configured in a DDT-node or a configured
>       site EID-prefix in a DDT Map-Server that matches the requested
>       EID.
> 
>    o  The type of DDT-node which sent the Map-Referral.
> 
>    o  The action code and ttl set by the sender of the Map-Referral.
> 
>    o  The referral RLOC addresses from the Map-Referral message.
> 
>    o  An round-trip-time estimate for the ECM-Map-Request/Map-Referral
Typo: “A round-trip-time…"

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

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.

Which implies as well that if no “follow-xxx-referral” option is present the simple referral reply is displayed with no further queries.

> 
>    The rig utility not only shows you branches of the delegation
>    hierarchy but can also report:
> 
> 
> 
[snip]
> 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...

> 
> 
> Farinacci, et al.      Expires September 18, 2014              [Page 10]
> 
> Internet-Draft   LISP-DDT Referral Internet Groper (RIG)      March 2014
> 
[snip]
> 
> 6.  Security Considerations
> 
>    The use of rig does not affect the security of the LISP
>    infrastructure as it is simply a tool that facilities diagnostic
>    querying.  See [RFC6830], [LISP-DDT], and [RFC6833] for descriptions
>    of the security properties of the LISP infrastructure.
> 
I would add a reference to the lisp-threats document.

>    LISP rig provides easy access to the information in the public
>    mapping database.  Therefore, it is important to protect the mapping
>    information for private use.  This can be provided by disallowing
>    access to specific mapping entries or to place such entries in a
>    private mapping database system.
> 
> 
> 
[snip]

> 8.  References
> 
> 8.1.  Normative References
> 
>    [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
>               September 1981.
Delete this reference it is never cited.

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

> 
>    [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
>               (IPv6) Specification", RFC 2460, December 1998.
> 
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.

>    [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
>               A., Peterson, J., Sparks, R., Handley, M., and E.
>               Schooler, "SIP: Session Initiation Protocol", RFC 3261,
>               June 2002.
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.

> 
>    [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
>               Locator/ID Separation Protocol (LISP)", RFC 6830,
>               January 2013.
> 
>    [RFC6833]  Fuller, V. and D. Farinacci, "Locator/ID Separation
>               Protocol (LISP) Map-Server Interface", RFC 6833,
>               January 2013.
> 
>    [RFC6835]  Farinacci, D. and D. Meyer, "The Locator/ID Separation
>               Protocol Internet Groper (LIG)", RFC 6835, January 2013.
> 
> 8.2.  Informative References
> 
>    [LISP-DDT]
>               Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
>               Delegated Database Tree", draft-ietf-lisp-ddt-01.txt (work
>               in progress).
> 
What?  Since RIG is a tool to debug DDT I would expect that the DDT document is normative.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 2 Jul 2014 14:12:29 -0700

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.

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

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

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

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

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

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

> 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