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>
