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

Dino Farinacci <> Fri, 12 January 2018 18:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CEEB5128D2E; Fri, 12 Jan 2018 10:40:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A3dOo1GPKITr; Fri, 12 Jan 2018 10:40:17 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 34B5B12895E; Fri, 12 Jan 2018 10:40:17 -0800 (PST)
Received: by with SMTP id p1so5008890pfh.4; Fri, 12 Jan 2018 10:40:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T7U9u8EjPqAlI/JVxyJ15Gaswzd4oWqN7wzTwpjRnC8=; b=lnXfm93gfvLl9rjurLzBFbIdUJGTfaa6q+izRW32IuaJx/oUbD4k1rFzB6sFp+XHD+ T4ijySkCO2PdOX64YI0p4jMJCbi1X00EuaAMh8I0n198GLjNq6sTWwJTqk825Aib+YoS kPZfqdTKM6GvdrAJogE+HIOpJKoASFz4G1/fufIwH3kEOu6fT/s2qavHFLCb+UdN17/a ln2Gb/leEsYqyxavKNuAXvpzGYh6A3O8nWiDUh0iozON4urRDOcDMISSNnpA24o8Yrhr BlrLXqjJndZIk06WbgoVeppx9DANv4MhbB4dSCyHdZ0y661pPEapDSdGzCo4dQbhvBQL 6dAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T7U9u8EjPqAlI/JVxyJ15Gaswzd4oWqN7wzTwpjRnC8=; b=PJh4JCo7wSkCmrqHgbg0iF3xv8N4A+uPoEi9f/bjdX1PjhXEynVUkt0QMyMF06B4/u Yh9Pl+EmWklml0D2qts2O7dSQuQKAy+RHIOJppAxHSMQkX1jg7a0e9wmTZmvaHGRs7H8 gYupDYgszgLrgemwU8EzV4ckvDFRNNEbl5vpL8oRhus7WKzOCQiNmAWYqr71kxoToCth 0hgm3BQyt3glJA8zRfgbpo7PqQa+vLo0IB0GCQlPnMSVZMzVRL1eCZrBqNyeZwHsxcH3 u5oowXEhbe0PNC7RwfXF/KfA8J1JAHiSR/glfw83380x2vtTnhvJON63adwUY5y1oRgS l0+A==
X-Gm-Message-State: AKGB3mLPCbLyyZuK/5NIyhlaSHa03n1GqT0iu/DIpqpZuBoLDbT34RKD tPJZDNMhO0BXHBOJk9VvKoY=
X-Google-Smtp-Source: ACJfBovxFWxd0vbXEIeZZepgyxTjLgXb1D3DTUuTWnQ0jLrIYVhnLDAlXaEeuDNUOBH2L5OdpRFBtw==
X-Received: by with SMTP id p23mr16311995pgc.60.1515782416665; Fri, 12 Jan 2018 10:40:16 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id w124sm44374952pfw.90.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jan 2018 10:40:15 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Dino Farinacci <>
In-Reply-To: <>
Date: Fri, 12 Jan 2018 10:39:54 -0800
Cc: "" <>, "" <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Les Ginsberg <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [lisp] [RTG-DIR} RtgDir last call review: draft-ietf-lisp-signal-free-multicast-07.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Jan 2018 18:40:20 -0000

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

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


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