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

From: Melinda Shore <[email-masked]>
Date: Sun, 25 Nov 2018 21:51:33 -0900

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
[email-masked]

Software longa, hardware brevis