Dino - I - of course - defer to you as regards all things LISP. And if the use of RTR is already widespread, then please ignore my comment.
That said, I do not see use of "RTR" in RFC 6830. I see ITR and ETR and their TE equivalents, but I do not see "RTR". ??? The definition of Re-encapsulating Tunnel Router is fine. It is just that when I saw "RTR" used in the text I had to go back to the terminology section because otherwise I thought you were just talking about a "Router". Les > -----Original Message----- > From: Dino Farinacci [mailto:[email protected]] > Sent: Friday, January 12, 2018 9:59 AM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: [email protected]; [email protected]; draft-ietf-lisp-signal-free- > [email protected]; [email protected] > Subject: Re: [RTG-DIR} RtgDir last call review: draft-ietf-lisp-signal-free- > multicast-07.txt > > > The first use of LCAF (Section 2) should be expanded. > > > > I find the acronym "RTR" a bit unfortunate for the obvious reason that > > it intuitively represents "just a router". I wonder if the authors > > could > > Les, I understand your concern here. However, RTR is littered throughout > many LISP documents as well as in product documentation and > implementations. We have clearly defined it in the base documents and for > any new use-case of an RTR, it is explained in the use-case documents. > > I really think it is too late. The term will continue to be used even if IETF > changes the documents. And adding a new term could add confusion (you’d > have to clarify everywhere that an RTR and a ReTR is the same thing). > > > consider something like "ReTR". I am sensitive to the fact that this > > document has been around since 2014 and has undergone significant WG > > review. I have > > RTR was introduced in a general way in RFC6830 which dates even further > back in time. And the component has added NAT functionality, TE > functionality, and in this document multicast functionality. > > > not attempted to track all of the email history regarding this > > document. Perhaps this point has been considered and consensus has > > been that the RTR acronym is the best choice. If so, feel free to disregard > my suggestion, but as someone who read this document for the first time I > found myself looking back for the definition of "RTR" multiple times as I read > through the text. > > Do you believe the definition is sufficient? This is what’s in the current > document: > > Re-encapsulating Tunnel Router (RTR): An RTR is a router that > implements the re-encapsulating tunnel function detailed in Section 8 > of the main LISP specification [RFC6830]. A LISP RTR performs packet > re-routing by chaining ETR and ITR functions, whereby it first > removes the LISP header of an ingress packet and then prepends a new > LISP header to an egress packet. > > Dino > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
