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 <[email protected]> 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> _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
