On Wed, Sep 12, 2018 at 1:53 PM, Brian E Carpenter <[email protected]> wrote: > Tom, > > On 2018-09-13 04:10, Tom Herbert wrote: >> Hi Brian, >> >> Thanks for the draft! >> >> I am still concerned about the implications and perceptions this draft >> might entail. Particularly, I wonder whether this will fracture the >> Internet (even more) and encourage (even more) protocol ossification >> by allowing developers and protocol designers to take short cuts that >> skimp on interoperability and use proprietary solutions instead of >> investing in open ones (with the vendor lock-in that goes with that). > > Of course that's a concern. My personal opinion is since it's going to > happen anyway (in fact, has been happening for many years in reality), > we are better off to bite the bullet and face reality. If the IoT is > anything real, it means we're going to make the Internet 100 times bigger > and that seems inconceivable without limited domains at the edges. > Yes, but it's not yet clear that a formal concept of Limited Domains is required to scale the Internet, or at least is required as an entity that defines or drives requirements in protocols.
Consider the world of mobile. Every mobile provider runs their network as a Limited Domain already in order to manage the mobile devices in their network. But everyone runs their domain differently. For example, some have firewalls, some have proxies, some provide no security. At the end of the day, a device can't assume that all networks provide anything but connectivity. Knowing that a device is connected to some standard "Limited Domain" that might imply a set of available services isn't much consolation. Instead of talking about network devices be non-conformant to the protocols, we'll be talking about whether networks conform to the definition of a limited domain. Note also, that some other SDOs already define standards for limited domains. 3GPP in particular, specifies both the network architecture and protocols for a mobile network (e.g. 5G specification). While it one sense it's good to have a common model and architecture for mobile networks, I believe that is at the expense of having a very complex protocol that is extremely hard to change. IMO, IETF's strength and advantage is that it focuses on standardizing protocols without standardizing network architecture. This provides all the necessary freedom for to build networks as appropriate and encourage innovation on many fronts. For the most part this model seems to haved worked well. The same TCP/IP protocol suite that works over the Internet also works in the largest data center down to the smallest home network. Sure, to make things work, use of protocols and configurations need to be adapted for different use, but we haven't yet had to radically change the protocol because it needs to run in a new environment (I suppose one might consider NAT as a radical change, but that is supposed to be obsoleted by IPv6 anyway :-) ). Tom >> Consider this from the draft: >> >> "This section suggests that protocols or protocol extensions should, >> when appropriate, be standardised to interoperate only within a >> Limited Domain Boundary. Such protocols are not required to operate >> across the Internet as a whole." >> >> I'm not sure what "not required to operate across the Internet as a >> whole" means. Specifically, what does it mean for a protocol to not >> have to "operate" on the whole Internet. > > Yes, this area needs more work. Our idea was to do that next, after > getting the taxonomy into shape. Your comments below are very insightful > and help a lot. Just one specific comment below at this point. > >> I think there are three >> possible meanings here: 1) using the protocol across the whole >> Internet isn't useful because it depends on localized information 2) >> using the protocol on the Internet isn't feasible because there is a >> lack of global support for it in the Internet 3) using the protocol on >> the whole Internet isn't correct and leads to bad behaviors. Example >> of #1 is segment routing, example of #2 is IPv6 extension headers, and >> example of #3 is extension header insertion. Of the three >> possibilities, an incorrect protocol is the most problematic. As a >> litmus test, consider that a Limited Domain implies a security >> perimeter exists around the domain that would contain the Limited >> Domain protocol. We know that such perimeters can and will break down >> at some point so that some day a limited domain protocol will leak >> into the Internet. That cannot lead to incorrect behavior, this cannot >> break the Internet! I submit that if a protocol cannot operate >> *correctly* in the Internet, or would break correct operation of other >> protocols on the Internet, then it is _not_ an Internet protocol. >> >> The part about "interoperate only within a Limited Domain Boundary" is >> also interesting. I worry vendors make take a lot of license with >> this. For instance, I have heard one suggestion that mobile operators >> might "give" each hardware vendor there own slice. So a Limited Domain >> is defined to contain only one vendor's equipment. Interoperability >> within a single implementation is rarely an issue! While I don't think >> it's our business to prevent things like this (network operators can >> do what they want within their domain), neither do I think we should >> be encouraging or facilitating it. IETF is fundamentally about >> standardizing open, interoperable Internet protocols. I guess the >> consequences of this is that if someone defines a protocol that only >> operates in a limited domain, then the limited domain itself needs to >> be clearly defined in normative language. > > I'd go a bit further - I think we need to standardize the mechanisms > for identifying and defining the boundary, so that what happens inside > can be effectively contained. That helps everybody. > > Thanks > Brian > >> >> Tom >> >> On Tue, Sep 11, 2018 at 8:30 PM, Brian E Carpenter >> <[email protected]> wrote: >>> New version, with a first draft of a taxonomy added. >>> >>> Discussion welcome. >>> >>> Brian + Bing >>> >>> -------- Forwarded Message -------- >>> Subject: I-D Action: draft-carpenter-limited-domains-03.txt >>> Date: Tue, 11 Sep 2018 20:18:56 -0700 >>> From: [email protected] >>> Reply-To: [email protected] >>> To: [email protected] >>> >>> >>> 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-03.txt >>> Pages : 19 >>> Date : 2018-09-11 >>> >>> 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, and develops a related >>> taxonomy. 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-03 >>> https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-03 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-03 >>> >>> >>> 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 protected] >>> 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 >>> >>> _______________________________________________ >>> Int-area mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/int-area >> . >> _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
