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

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Dec 2018 08:32:39 +1300

An update following recent comments:

-------- Forwarded Message --------
Subject: I-D Action: draft-carpenter-limited-domains-05.txt
Date: Wed, 12 Dec 2018 11:26:16 -0800
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-05.txt
	Pages           : 23
	Date            : 2018-12-12

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, also known as controlled environments, and emerging
   solutions, and develops a related taxonomy.  It then briefly
   discusses the standardization of protocols for limited domains.
   Finally, it shows the needs for a precise definition of limited
   domain membership and for mechanisms to allow nodes to join a domain
   securely and to find other members, including boundary nodes.

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-05
https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-05

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

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: Wed, 12 Dec 2018 16:14:44 -0800

Hi Brian,

A few comments on new text in the draft...

>From the draft:

"Another term that has been used in some contexts is "controlled
environment". For example, [RFC8085] uses this to delimit the scope
within which a particular tunnel encapsulation might be used."

I think this is mis-characterizing things a bit. The rationale for
restricting an encapsulation protocol to a controlled environment is
only applicable in the case that the traffic being carried isn't
subject to congestion control. The controlled environment text is in
GRE/UDP because of the rather narrow use case that GRE can carry
non-IP, non-congestion controlled traffic like in encapsulated
Ethernet (there is an explicit assumption that IP traffic is
congestion controlled). This is only an _operational_ requirement.
Assuming that the operational requirements for congestion control is
met (easy enough to do with rate limiting from a source), there are no
protocol restrictions, nor should there be any, on using GRE/UDP or
any other encapsulation protocol over the Internet.

"The recent discussions about the unreliability of IP fragmentation
needed.  and the filtering of IPv6 extension headers have clearly
shown that at least for some protocol elements, transparency is a lost
cause and middleboxes are here to stay."

I can't say that I agree with this assessment, at least the part about
transparency being a loss cause. It seems to preclude the possibility
that non-conformant implementations can be fixed or that we could
figure out ways to systematically work around them. This needs
discussion, but it's probably outside the scope of limited domains.

"In summary, some application environments require protocol features
that cannot cross the whole Internet."

This seems a little ambiguous to me. It would be good to have a
definition what it means that a "protocol feature cannot cross the
whole Internet". If taken literally, I believe that TCP is the only
transport protocol and IPv4 is the network protocol that might be
close to being able to cross the whole Internet. So then one could
infer that all other transport and network protocols are relegated to
only be used in limited domains. I don't believe that's the intent of
the draft! :-)

Tom

On Wed, Dec 12, 2018 at 11:32 AM Brian E Carpenter
<[email-masked]> wrote:
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area