Skip to main content

Limited Domains and Internet Protocols
draft-carpenter-limited-domains-13

Revision differences

Document history

Date Rev. By Action
2020-07-13
13 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-07-06
13 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-03-25
13 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-02-10
13 (System) IANA Action state changed to No IANA Actions from In Progress
2020-02-10
13 (System) IANA Action state changed to In Progress
2020-02-10
13 (System) RFC Editor state changed to EDIT
2020-02-10
13 Adrian Farrel ISE state changed to Sent to the RFC Editor from In IESG Review
2020-02-10
13 Adrian Farrel Sent request for publication to the RFC Editor
2020-02-02
13 (System) Revised ID Needed tag cleared
2020-02-02
13 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2020-02-02
13 Brian Carpenter New version available: draft-carpenter-limited-domains-13.txt
2020-02-02
13 (System) New version approved
2020-02-02
13 (System) Request for posting confirmation emailed to previous authors: Bing Liu , Brian Carpenter
2020-02-02
13 Brian Carpenter Uploaded new revision
2020-01-26
12 Adrian Farrel Tag Revised I-D Needed set.
2019-12-11
12 (System) IANA Review state changed to IANA OK - No Actions Needed
2019-12-11
12 Amanda Baber
(Via drafts-eval@iana.org): IESG/Authors/ISE:

The IANA Functions Operator has reviewed draft-carpenter-limited-domains-12 and has the following comments:

We understand that this document doesn't require any registry …
(Via drafts-eval@iana.org): IESG/Authors/ISE:

The IANA Functions Operator has reviewed draft-carpenter-limited-domains-12 and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Amanda Baber
Lead IANA Services Specialist
2019-12-06
12 Adrian Farrel ISE state changed to In IESG Review from In ISE Review
2019-12-06
12 Adrian Farrel IETF conflict review initiated - see conflict-review-carpenter-limited-domains
2019-12-06
12 Adrian Farrel
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 …
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
Global?

== 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
  regions.

  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).

---

1.

  they might not operate usefully

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

---

2.

  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"?

---

2.

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.

---

6.

2.  Nesting

Missing a final close bracket.

---

6.

  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
2019-11-30
12 (System) Revised ID Needed tag cleared
2019-11-30
12 Brian Carpenter New version available: draft-carpenter-limited-domains-12.txt
2019-11-30
12 (System) New version approved
2019-11-30
12 (System) Request for posting confirmation emailed to previous authors: Bing Liu , Brian Carpenter
2019-11-30
12 Brian Carpenter Uploaded new revision
2019-11-28
11 Adrian Farrel Tag Revised I-D Needed set.
2019-11-22
11 Adrian Farrel Tag Awaiting Reviews cleared.
2019-11-22
11 Adrian Farrel ISE state changed to In ISE Review from Response to Review Needed
2019-10-30
11 (System) Revised ID Needed tag cleared
2019-10-30
11 Brian Carpenter New version available: draft-carpenter-limited-domains-11.txt
2019-10-30
11 (System) New version approved
2019-10-30
11 (System) Request for posting confirmation emailed to previous authors: Bing Liu , Brian Carpenter
2019-10-30
11 Brian Carpenter Uploaded new revision
2019-08-09
10 Adrian Farrel Tag Revised I-D Needed set.
2019-08-09
10 Adrian Farrel ISE state changed to Response to Review Needed from Finding Reviewers
2019-08-02
10 Brian Carpenter New version available: draft-carpenter-limited-domains-10.txt
2019-08-02
10 (System) New version approved
2019-08-02
10 (System) Request for posting confirmation emailed to previous authors: Bing Liu , Brian Carpenter
2019-08-02
10 Brian Carpenter Uploaded new revision
2019-08-01
09 Adrian Farrel Tag Awaiting Reviews set.
2019-08-01
09 Adrian Farrel ISE state changed to Finding Reviewers from Submission Received
2019-07-19
09 Adrian Farrel Notification list changed to Adrian Farrel <rfc-ise@rfc-editor.org>
2019-07-19
09 Adrian Farrel Document shepherd changed to Adrian Farrel
2019-07-19
09 Adrian Farrel ISE state changed to Submission Received
2019-07-19
09 Adrian Farrel Intended Status changed to Informational from None
2019-07-19
09 Adrian Farrel Stream changed to ISE from None
2019-06-22
09 Brian Carpenter New version available: draft-carpenter-limited-domains-09.txt
2019-06-22
09 (System) New version approved
2019-06-22
09 (System) Request for posting confirmation emailed to previous authors: Bing Liu , Brian Carpenter
2019-06-22
09 Brian Carpenter Uploaded new revision
2019-06-11
08 Brian Carpenter New version available: draft-carpenter-limited-domains-08.txt
2019-06-11
08 (System) New version approved
2019-06-11
08 (System) Request for posting confirmation emailed to previous authors: Bing Liu , Brian Carpenter
2019-06-11
08 Brian Carpenter Uploaded new revision
2019-04-15
07 Brian Carpenter New version available: draft-carpenter-limited-domains-07.txt
2019-04-15
07 (System) New version approved
2019-04-15
07 (System) Request for posting confirmation emailed to previous authors: Bing Liu , Brian Carpenter
2019-04-15
07 Brian Carpenter Uploaded new revision
2019-03-01
06 Brian Carpenter New version available: draft-carpenter-limited-domains-06.txt
2019-03-01
06 (System) New version approved
2019-03-01
06 (System) Request for posting confirmation emailed to previous authors: Bing Liu , Brian Carpenter
2019-03-01
06 Brian Carpenter Uploaded new revision
2018-12-12
05 Brian Carpenter New version available: draft-carpenter-limited-domains-05.txt
2018-12-12
05 (System) New version approved
2018-12-12
05 (System) Request for posting confirmation emailed to previous authors: Bing Liu , Brian Carpenter
2018-12-12
05 Brian Carpenter Uploaded new revision
2018-10-14
04 Brian Carpenter New version available: draft-carpenter-limited-domains-04.txt
2018-10-14
04 (System) New version approved
2018-10-14
04 (System) Request for posting confirmation emailed to previous authors: Bing Liu , Brian Carpenter
2018-10-14
04 Brian Carpenter Uploaded new revision
2018-09-11
03 Brian Carpenter New version available: draft-carpenter-limited-domains-03.txt
2018-09-11
03 (System) New version approved
2018-09-11
03 (System) Request for posting confirmation emailed to previous authors: Bing Liu , Brian Carpenter
2018-09-11
03 Brian Carpenter Uploaded new revision
2018-08-13
02 Brian Carpenter New version available: draft-carpenter-limited-domains-02.txt
2018-08-13
02 (System) New version approved
2018-08-13
02 (System) Request for posting confirmation emailed to previous authors: Brian Carpenter , Sheng Jiang
2018-08-13
02 Brian Carpenter Uploaded new revision
2018-06-30
01 Brian Carpenter New version available: draft-carpenter-limited-domains-01.txt
2018-06-30
01 (System) New version approved
2018-06-30
01 (System) Request for posting confirmation emailed to previous authors: Brian Carpenter , Sheng Jiang
2018-06-30
01 Brian Carpenter Uploaded new revision
2018-06-10
00 Brian Carpenter New version available: draft-carpenter-limited-domains-00.txt
2018-06-10
00 (System) New version approved
2018-06-10
00 Brian Carpenter Request for posting confirmation emailed  to submitter and authors: Brian Carpenter , Sheng Jiang
2018-06-10
00 Brian Carpenter Uploaded new revision