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 |