Shepherd writeup

draft-carpenter-limited-domains has been presented to the ISE for
publication as an Independent Submission stream Informational RFC.

The document sets out the authors' views on scoping limited domains
within the Internet. The document is very clear that it is not an
IETF consensus document.

The work is relatively straight-forward and was previously brought to
the attention of the INT ADs.

The current document received detailed reviews from Donald Eastlake,
Mark Smith, and from the ISE. It has been updated several times to 
address the points raised. (Copies of the reviews are below.)

The Informational document does not request any IANA action and has
no disclosed IPR.

== Donald Eastlake ==

Section 3, Item 1: There seems to be some implication that wiring
errors such as physical loops wouldn't occur with professionally
managed networks. I am reminded of how, when Radia Perlman devised the
Spanning Tree Protocol she made sure it would work with arbitrary
wiring, like a jumper between two ports on the same bridge, despite
being told that would not occur. And how the first commercial customer
for such a bridge complained how it "didn't work" but investigation
showed that they had, in fact, erroneously wired it exactly that way.

Section 3, item 4: There are also the related very low latency
requirements for Virtual Reality and Augmented Reality applications.
See IEEE 3333.1.1-2015 - "IEEE Standard for Quality of Experience
(QoE) and Visual-Comfort Assessments of Three-Dimensional (3D)
Contents Based on Psychophysical Studies". Even slight delays in VR
displays can cause nausea.

Section 3, item 11: Maybe mention multicast / broadcast here or
somewhere in this list.

Section 4: Just a comment that with protocols such as TRILL [RFC6325]
and Shortest Path Bridging [IEEE Std 802.1Q-2014], Layer 2 domains can
get really big.

Section 4, item 1: Somehow I would feel better if somewhere in this
item it said something about "mapping", which is what commonly
happens, as opposed to the more general "re-marking".

Section 5, items A-D: I found the relationship between these items or
categories to be confusing. A table or ASCII-art Venn Diagram of valid
combinations would help a lot.

Section 6, third paragraph starting "Firstly, ": implies that a node
is necessarily inside or outside a domain. Note that considering Level
2 OSPF or IS-IS routers, this is true to OSPF where the Level boundary
is inside a link but not for IS-IS where the Level 2 boundary is
inside a node.

Section 6, items 1, 2, & 3: These seems a bit strong to me.

Appendix B.1, third bullet item on human versus automatic management:
Isn't it really just a question of management time scale? Humans
usually initiate and terminate the network no matter how automatic it
is. And even if it is extensively managed by humans, it may have, for
example, routing protocols that are changing forwarding on a time
scale of tens of milliseconds.

Appendix B.7: Main heading lists Privacy but none of the bullet points do.

Editorial suggestions:

Since this seems aimed at a slightly more general audience than the
typical RFC, it might be best to spell out more acronyms on first use
such as RSVP, DNS, GRE, ...

Section 3, item 2 of second list: Maybe swap this item with item 1
just so that "above" is a smaller jump upwards...

Section 3, item 10: The wording with which this item starts just
doesn't seem parallel to the that of other items.

Section 3, first paragraph after second numbered list: "right
questions" -> "best questions"?

Section 3, last paragraph: Add "[RFC2205]" reference to "RSVP".

Section 4, item 10, 4th starred sub-item: "will" -> "can".

Section 4, item 14: "but access" -> "but for which access".

Section 5, paragraph beginning "The FAST proposal mentioned above": I
found the "above' reference to be a bit hard to de-reference. Maybe
something like "The Fast proposal mentioned in item 5 in Section 4
above ..."

Appendix B, initial part next to last bullet item: add comma after 'trust".

== Mark Smith ==

5. The Scope of Protocols in Limited Domains

"D. If a limited-domain protocol has domain-specific variants,
such that implementations in different domains could not
interoperate if those domains were unified by some mechanism, the
protocol is not interoperable in the normal sense."

RFC 5704, "Uncoordinated Protocol Development Considered Harmful",
could be a good reference and further example. T-MPLS was being
developed by the ITU, while MPLS was being developed by the IETF. From
memory (as a distant observer), the ITU were using code points that
were duplicates of the IETF's and weren't registering it. In other
words, the ITU took forked MPLS and then redefined parts of it that
conflicted with the IETF's MPLS code points and perhaps operations.

"To provide a provocative example, consider the proposal in
[I-D.voyer-6man-extension-header-insertion] that the restrictions in
[RFC8200] should be relaxed to allow IPv6 extension headers to be
inserted on the fly in IPv6 packets. If this is done in such a way
that the affected packets can never leave the specific limited domain
in which they were modified, scenario C applies. If the semantic
content of the inserted headers is locally defined, scenario D also
applies. In neither case is the Internet disturbed."

The trouble here, and I think this is a very important point, is that
protocol specifications don't just define packet structures, they also
define expected implementation behaviours and processing rules.

A limited domain must not be used to ignore these protocol behaviours,
because then the claim of using the specific protocol within the
domain is false. It's not "IPv6" if the domain specified behaviour is
not compliant with RFC 8200. It is something else similar to and
derived from IPv6, but not the same. It would be a non-interoperable
dialect of IPv6.

If there is a domain specific, non-compliant version or variant of an
existing protocol, then it needs to have its own identifier to
distinguish it, either a major or minor version number.

"As long as all relevant standards are
respected outside the domain boundary, a well-specified limited-
domain protocol is not harmful to the Internet."

I'm struggling to agree with this, as it reads to me as "do anything
you like within your domain as long as you document it". This "do what
you like" can include taking an existing specification, ignoring parts
you don't like, and then still saying you're using the protocol.

This may not be harmful to the Internet in the sense of domain
behaviour being hidden from the Internet, however it is harmful in to
the Internet in the sense of whether Internet protocol specifications
have to be respected, and whether Internet network operators can trust
that if a claim is made about using a protocol and its specification,
it can be believed.

B.4 Topology

This point is duplicated:

In IP addressing terms, is the domain Link-local, Site-local, or

== ISE review 1 ==

Let's add a note to the Abstract that this is the authors' opinion not
an IETF consensus document. Nothing dramatic, just some shading. At the
same time we could fix some ambiguous wording. That leaves us with...

   There is a noticeable trend towards network requirements, behaviours,
   and semantics that are specific to a particular set of requirements
   applied within a limited region of the Internet.  Policies, default
   parameters, the options supported, the style of network management,
   and security requirements may vary within the scop of such limited

   This document reviews examples of such limited domains (also known as
   controlled environments), notes emerging solutions, and includes a
   related taxonomy.  It then briefly discusses the standardization of
   protocols for limited domains.  Finally, it shows the need 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.

   This document is the product of the research of the authors.  It has
   been produced through discussions and consultation within the IETF,
   but is not the product of IETF conensus.


Let's add that final paragraph as the last paragraph of the Introduction
as well.

== ISE review 2 ==

One area I personally work in is TE and optical networking. This gives
rise to some existing definitions of "domain" such as below. I don't
know whether any of these references or definitions are useful to you.

- RFC 4397

   TE domain is a set of controllers each of which has full TE
      visibility within the set.

Note that the 4397 definition was attempting coherence with the ITU-T
definition of a "routing domain" which is no more than the cluster of
inter-communicating "routing controllers".

- RFC 4427

   A recovery domain is defined as a set of nodes and spans, over which
   one or more recovery schemes are provided.  A recovery domain served
   by one single recovery scheme is referred to as a "single recovery
   domain", while a recovery domain served by multiple recovery schemes
   is referred to as a "multi recovery domain".

- RFC 4655 (also 4726 and 7926)

   A domain is any collection of network elements within a common sphere
   of address management or path computation responsibility.  Examples
   of domains include IGP areas, Autonomous Systems (ASes), and multiple
   ASes within a Service Provider network.  Domains of path computation
   responsibility may also exist as sub-domains of areas or ASes.

Finally, two clear separations into domains in the optical world are:
- technology-specific (e.g., connecting WDM equipment to TDM equipment
  may give interesting results) -- This may fit in B.5
- vendor-specific (historically, interoperability between equipment from
  different vendors has been poor at the physical, that is data plane,
  level even when the control plane is standardised).



   they might not operate usefully

Nit-picking and wondering whether s/usefully/optimally/



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

Not sure how well this will survive the erosion of time.

Maybe you can give a reference for the "recent discussions"?



I'm not a fan of the references you've used for network slicing. It's
OK to continue to use them, but if you want a definition that is under
the care of a WG then draft-ietf-teas-enhanced-vpn has

   A transport network slice is a virtual (logical) network with a
   particular network topology and a set of shared or dedicated network
   resources, which are used to provide the network slice consumer with
   the required connectivity, appropriate isolation and specific Service
   Level Agreement (SLA).  A transport network slice could span multiple
   technology (IP, Optical) and multiple administrative domains.
   Depends on the consumer's requirement, a transport network slice
   could be isolated from other, often concurrent transport network
   slices in terms of data plane, control plane and management plane.



2.   Nesting

Missing a final close bracket.



   3.   Overlapping.  It must be possible for nodes to be in more than
        one domain (see, for example, the case of PVDs mentioned above).

Pedantically, do you want to s/nodes/nodes and links/ ?


7.  Security Considerations

I think "confidentiality" (i.e., privacy of operational parameters)
should possibly show up here.


9.  Contributors

It is convention these days to format the Contributors section as the
Authors section, thus giving email and affiliation.


When I got to the end, I wondered why you hadn't mentioned domain
partitioning for scaling reasons. This may fit in B.1