Re: [RTG-DIR] [RTG-DIR} RtgDir last call review: draft-ietf-lisp-signal-free-multicast-07.txt

["Les Ginsberg (ginsberg)" <[e-mail]>]

> -----Original Message-----
> From: Dino Farinacci [mailto:[e-mail]]
> Sent: Friday, January 12, 2018 10:40 AM
> To: Les Ginsberg (ginsberg) <[e-mail]>
> Cc: [e-mail]; [e-mail]; draft-ietf-lisp-signal-free-
> [e-mail]; [e-mail]
> 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:[e-mail]]
> >> Sent: Friday, January 12, 2018 9:59 AM
> >> To: Les Ginsberg (ginsberg) <[e-mail]>
> >> Cc: [e-mail]; [e-mail]; draft-ietf-lisp-signal-free-
> >> [e-mail]; [e-mail]
> >> 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
> >>
> >