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

[Luigi Iannone <[e-mail]>]

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.