[PANRG] A few comments on draft-irtf-panrg-what-not-to-do, and a question

Melinda Shore <melinda.shore@nomountain.net> Mon, 26 November 2018 06:51 UTC

Return-Path: <melinda.shore@nomountain.net>
X-Original-To: panrg@ietfa.amsl.com
Delivered-To: panrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D411271FF for <panrg@ietfa.amsl.com>; Sun, 25 Nov 2018 22:51:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.358
X-Spam-Level:
X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.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 saJzeNyG-Vs9 for <panrg@ietfa.amsl.com>; Sun, 25 Nov 2018 22:51:36 -0800 (PST)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 A5F3E128CB7 for <panrg@irtf.org>; Sun, 25 Nov 2018 22:51:36 -0800 (PST)
Received: by mail-pg1-x52f.google.com with SMTP id 70so5698200pgh.8 for <panrg@irtf.org>; Sun, 25 Nov 2018 22:51:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=from:subject:to:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=K3u/Q9vnRM/eymLPhBX5YTCbY0ytDBmLZSM3N6ljhgM=; b=m38bqTI9UP9W87Bc31hN3nxcpOK2aQ0SxsTXRR6wMupqPei9Xn0DmRNumaXBGDs/SN pVd8FGJ8kX5YUI7wlhznIjl5Kxm0TvVNP3DoUwM9gQ2EcBTPGaxen5UCvPM6v5uoTpk0 Tk185i1PAbIvEjMpKeyw1tIVGITGML7D37LmrsVEECoP1XpoPItOlHLzkFA//OfIyVS6 nbdgy/yL4av0kNeuL2/9Yv94K+D2290uy73lhpA0vrFVPi319YXNbHtdkUAzyRyq0ddn XvrikjoZMwU+/2BZ4ZllTBWzGclhRXr7DW+jFKacyglpnAaYfTJadEENROayhx92I6tJ cqJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=K3u/Q9vnRM/eymLPhBX5YTCbY0ytDBmLZSM3N6ljhgM=; b=iGRm9let2eCKpQaKpOUqI23oqNHfg/UWQIA4XAzqOcgtjbuNHLQ9clUf+ocBwng6uJ mcrDPp1S22OtwS0O59jc15pvX9FkINaQ5xADVFdA5D/vVIYwdr8lz2H4oL0J9SUgcuv6 zdJcGeHceX+zMJvRvj+up1jHJZr07TesrMv0NJGQA0d4absQ8ygIApOW85+Y2+RCtx76 VTWuMc2kAB2s1H/3Om7ddqzIw3zIYhCxTmfcDULcocZKDFV4h6Z/ZwcGDPL2wweuNt38 jcxA+9+xr0HYYa42a4yA6SNYbX6sl4o2UUHMsaF894Lf/X5kAFDRamDxc/7CWGQzC+Du tOyw==
X-Gm-Message-State: AA+aEWZLxK6G3XlwLuzfcPmuIyTHoyeBiCKGyED3XhLAggL+p8Yz+7iZ fmr7K2oqObLmB94GAq1lOHZyoB8I7Q==
X-Google-Smtp-Source: AFSGD/WFuNuwe/TDRFidRWlnzZUvjIVxLibXWsui/dwh9qiY94a/UzeL2D9xqbjcH4jMsC4gjarPBw==
X-Received: by 2002:a62:2c81:: with SMTP id s123mr22946620pfs.174.1543215095823; Sun, 25 Nov 2018 22:51:35 -0800 (PST)
Received: from aspen.local (216-67-35-146-radius.dynamic.acsalaska.net. [216.67.35.146]) by smtp.gmail.com with ESMTPSA id m65sm8887694pfg.180.2018.11.25.22.51.34 for <panrg@irtf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Nov 2018 22:51:35 -0800 (PST)
From: Melinda Shore <melinda.shore@nomountain.net>
To: panrg@irtf.org
Message-ID: <24791826-af02-0aea-c221-517a9c0f4f9b@nomountain.net>
Date: Sun, 25 Nov 2018 21:51:33 -0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/panrg/sgdR1GTuVGWLU0HW-f8lZnYohJY>
Subject: [PANRG] A few comments on draft-irtf-panrg-what-not-to-do, and a question
X-BeenThere: panrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" <panrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/panrg>, <mailto:panrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/panrg/>
List-Post: <mailto:panrg@irtf.org>
List-Help: <mailto:panrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/panrg>, <mailto:panrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Nov 2018 06:51:39 -0000

First, I really enjoyed this draft, not only as a look back
at some of the things we've done (and failed to do), but also
as an excellent overview, in a quirky way, of the problem space.

I spent my first decade or so of involvement with the IETF
working on middlebox-related problems.  Sometimes the approaches
were on-path (for example, NSIS, NLS, and other similar protocols) and
sometimes they were off-path but required at least some topological
awareness, (midcom, NUTSS, PCP).

My understanding of what happened in NSIS, as someone who'd been
active in that work at the outset, is that because of heavy involvement
by folks from telecomm land there was an understanding that
"reliability" meant reliable delivery baked into the transport, and
they ended up with something extremely stateful and with expensive
start-up costs on signaling streams, plus a fairly incoherent security
model.  We had a lighter-weight approach at the networking behemoth
and while it was eventually picked up by CableLabs to address a topology
discovery problem they were facing, we did not see implementation to
address middlebox problems for both business and deployment reasons.
The primary business reason was that there was reluctance on the part of
the  vendor to do anything that would reduce the value of their stateful
inspection technology (in which they had a considerable investment), and
the deployment reason had to do with the near impossibility of upgrading
essentially everything on the network at the same time.  (I'd be happy
to discuss the security and trust issues at another time; we felt we
had a reasonable solution and it was not, ultimately, a barrier to
getting the technology rolled out).  At any rate we found that even
without the router alert there was sufficient reason for vendors not
to want to implement this kind of thing that it wouldn't have
progressed, anyway.

My question:  as mentioned above, over the years there's been a
considerable amount of effort that's been expended in the IETF
and IRTF on protocols that need some level of path awareness in
order to communicate policy to devices that a given path traverses,
but that are not themselves path-coupled.  Is that sort of thing in-
scope or out-of-scope for this RG?

Melinda


-- 
Melinda Shore
melinda.shore@nomountain.net

Software longa, hardware brevis