> -----Original Message----- > From: Dino Farinacci [mailto:[email protected]] > Sent: Friday, January 12, 2018 10:40 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 > > > 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. > > Thanks. > > > 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". > > ??? > > That has been noticed by many and the definition has been put in the > 6830bis draft. Sorry about referring to 6830 when I should have said draft- > ietf-lisp-rfc6830bis-08. >
[Les:] Yes - I see that. But - at a quick perusal of other LISP documents - I do not see a definition of RTR elsewhere. So it would seem you still have an opportunity to change the acronym and keep all published documents consistent. But, I don't want to prolong this discussion. I think we understand each other and I am comfortable with whatever decision you make. Les > > 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”. > > A sign that you have been doing routers (aka RTRs) too long. ;-) > > Dino > > > > > 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
