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

[Dino Farinacci <[e-mail]>]

> 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.

> 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
>> 
>