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

Dino Farinacci <farinacci@gmail.com> Fri, 12 January 2018 18:40 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEB5128D2E; Fri, 12 Jan 2018 10:40:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3dOo1GPKITr; Fri, 12 Jan 2018 10:40:17 -0800 (PST)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34B5B12895E; Fri, 12 Jan 2018 10:40:17 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id p1so5008890pfh.4; Fri, 12 Jan 2018 10:40:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.99.116.23 with SMTP id p23mr16311995pgc.60.1515782416665; Fri, 12 Jan 2018 10:40:16 -0800 (PST)
Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id w124sm44374952pfw.90.2018.01.12.10.40.15 (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 <farinacci@gmail.com>
In-Reply-To: <225a4de9cbc54c50abbe8503dcf98093@XCH-ALN-001.cisco.com>
Date: Fri, 12 Jan 2018 10:39:54 -0800
Cc: "rtg-ads@ietf.org" <rtg-ads@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-lisp-signal-free-multicast.all@ietf.org" <draft-ietf-lisp-signal-free-multicast.all@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3FC38CC3-F7C9-4C58-B4E0-68240FD589C1@gmail.com>
References: <67a4814cf3aa408c8794d9b937cb8fcf@XCH-ALN-001.cisco.com> <73A6A40F-3193-4C01-9ABC-B1E8BDF0FB33@gmail.com> <225a4de9cbc54c50abbe8503dcf98093@XCH-ALN-001.cisco.com>
To: Les Ginsberg <ginsberg@cisco.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/NOBO7YNeTL6ovWr1FIa7qW-WE10>
Subject: Re: [lisp] [RTG-DIR} RtgDir last call review: draft-ietf-lisp-signal-free-multicast-07.txt
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=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.

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:farinacci@gmail.com]
>> Sent: Friday, January 12, 2018 9:59 AM
>> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
>> Cc: rtg-ads@ietf.org; rtg-dir@ietf.org; draft-ietf-lisp-signal-free-
>> multicast.all@ietf.org; lisp@ietf.org
>> 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
>> 
>