Subject: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-02.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Aug 2018 14:07:22 +1200

Updated following comments received at IETF102.

-------- Forwarded Message --------
Subject: I-D Action: draft-carpenter-limited-domains-02.txt
Date: Mon, 13 Aug 2018 18:42:27 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Limited Domains and Internet Protocols
        Authors         : Brian Carpenter
                          Bing Liu
	Filename        : draft-carpenter-limited-domains-02.txt
	Pages           : 15
	Date            : 2018-08-13

Abstract:
   There is a noticeable trend towards network requirements, behaviours
   and semantics that are specific to a limited region of the Internet
   and a particular set of requirements.  Policies, default parameters,
   the options supported, the style of network management and security
   requirements may vary.  This document reviews examples of such
   limited domains and emerging solutions.  It shows the needs for a
   precise definition of a limited domain boundary and for a
   corresponding protocol to allow nodes to discover where such a
   boundary exists.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-carpenter-limited-domains-02
https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Tom Herbert <[email-masked]>
Date: Tue, 14 Aug 2018 17:00:59 -0700

>    corresponding protocol to allow nodes to discover where such a
Hi Brian, thanks for the draft.

A couple general points:

* It's unclear to me what it means for a protocol to only work in a
limited domain. I think there is a big difference between describing
how a standard protocol _could_ be deployed in a limited domain for
good effect, versus defining a standard protocol that can _only_
operate correctly in a limited domain. Most of the examples in section
4 are describing deployment of protocols seem to fall in the first
category where protocol deployment might only be feasible in limited
domain, but the definition of the protocol does not require a limited
domain. For instance, the fact that extension headers is not
deployable by the Internet, but may work in a limited domain, is
happenstance on how things evolved. It was never the intent of
extension headers to only be used in limited domains, neither do I
believe there is value in respecifying extension headers as such (I
still believe problems that prevent use on the Internet should be
fixed). On the other hand, something like extension header insertion
would require a protocol to be specified to only work in a limited
domain since that would otherwise break some fundamental requirements
of IPv6.

* If we accept that protocols can be defined for use only limited
domains, what becomes of the priniciple of interoperability? Does this
open up the possibility that "limited domain" could mean that any
possible variant of a protocol is allowed per the "local policy" of
the domain? A limited domain would make anything possible in
protocols. For instance, someone could decide to switch the soure and
destination addresses in IP headers in a limited domain as a local
policy. As long as the requirements of a limited domain is enforced
this is completely feasible (note a limited domain could be defined by
an island in the network having only one vendor solution). So then
does a limited domain become a vehicle for vendors to define and
deploy their own value-add protocol extensions without regard to
interoperability? The open endedness of "local policy" alluded to in
the SR protocol draft as well as some statement concerning the use of
network slices by mobile operators that are run by a single hardware
vendor are noteworthy.,

Tom

> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Aug 2018 17:26:50 +1200

Tom,

Thanks for the comments. See in-line:

> On Mon, Aug 13, 2018 at 7:07 PM, Brian E Carpenter
...
> operate correctly in a limited domain. 

Agreed. This is exactly why our next step is planned to be
a taxonomy of the various aspects, to try and separate
these issues.

> Most of the examples in section
> extension headers to only be used in limited domains,

Correct.

> neither do I

I'd be very unlikely to do that, personally. But there might be
*semantics* that only apply within a domain. (That is how we
designed diffserv, whereas the original IPv4 TOS design was
supposed to be universal, I believe.)

> fixed).

I wish that I had confidence that this could be achieved, but
there is an ongoing tension between innovation and firewall rules.

> On the other hand, something like extension header insertion

Exactly.

> the domain? 

That's a central question. I think the other way of looking at
it is: is it better to recognise that local semantics exist, and
figure out how to contain them, or is it better to simply
say "don't do that"?

> A limited domain would make anything possible in

Absent protocol police, we can't actually stop people doing such
things, can we? So the question is how can we best deal with the
reality of local semantics without (further) damaging global
interop?

Again, thanks, this is very helpful.

   Brian

---

From: Tom Herbert <[email-masked]>
Date: Wed, 15 Aug 2018 09:31:15 -0700

> there is an ongoing tension between innovation and firewall rules.
I am hopeful that mapping the capabilities of the Internet (like maybe
work from MAPRG?) will resolve that. Applications can use "advanced"
protocol features like extension headers in a type of happy eyeballs
approach. Also, applications should give feedback to users when their
in a degraded service mode because of non conforming devices in the
path.

> reality of local semantics without (further) damaging global
Right, such things happen already and it's probably much more common
than we'd like to admit. I've seen this deployed first hand (you
should see how we overloaded the GRE sequence number and checksum
fields to hold our own stuff at Google!). There is no interoperability
problem here either, for a large datacenter operator it's just a phone
call to a vendor to get what they want. But in the end, relying on
"local semantics", especially when that means proprietary protocols or
non-interoperability, is self defeating. It's better to use open
standard protocols or at least have a path to that. In the case of
GRE, the fields we could overload are limited and hence that was the
motivation to create GUE.

I don't think it's within the purview of IETF to prevent people from
hacking IETF protocols, but neither do I think that IETF should go out
of its way to facilitate, codify, or sanction such practises. Grant
it, there is subtly here. For instance, there are experimental
protocol numbers and experimental option values define in IP; Geneve,
on the other hand, explicitly allows vendor specific options to "allow
for differentiation of products by encouraging independent development
in each vendor's core specialty". In both instances the protocol has
hooks that could leveraged to implement a proprietary protocol per
local policy, but, on paper at least, the former is only for
experimentation and the latter explicitly facilitates proprietary
protocols.

So maybe Internet protocols should (continue to) be specified assuming
it runs in a network where everyone conforms to the protocols, has
minimal dependencies on other protocol layers or deployment
conditions, and doesn't acknowledgement proprietary protocols. This is
consistent with the fundamental goal of defining standard, open,
interoperable protocols for the Internet. Related documents (like
BCPs) describe how protocols can be deployed in the real world
circumstances. So it a limited domain can be specified in normative
language (I'm not yet convinced it can be) then we should see a number
of drafts on how to deploy standard protocols in limited domains.

Tom