Reported by Abel Weinrib/Intel
An on-line copy of these and other IAB minutes are available from http://www.iab.org/documents/IABmins.
The open meeting of the Internet Architecture Board at the San Jose IETF started out with a presentation by Jon Postel on “Not All RFC are Standard.” The issue is that there are a number of grades of RFC (Informational, Experimental, Proposed/Draft/Standard, Historic) and people get confused about which do and which do not describe Internet standards. The status of an RFC is usually clearly stated on the front page and in the RFC index, this does not help the naive user who does not have a copy of the document and may incorrectly believe that all RFCs describe standards. Jon discussed the reasons that a single RFC series is considered valuable, and then went on to describe the proposed fix, which is to encourage the use of the STD number rather than the RFC number when referencing an Internet standard. An advantage of this practice is that the STD number does not change as the standard goes through revisions, whereas the RFC(s) describing the standard will change. User education is an important part of this; in addition, Jon is in the preliminary stages of using WWW technology to create a standards directory with hypertext links to the relevant RFCs. The need for user education was highlighted by the fact that no one in the room knew what STD 5 is.
The second presentation, prepared by Yakov Rekhter and Lixia Zhang and presented by Lixia, discussed the commercialization of the Internet. Lixia described the Internet environment of the past, where it is going now, and made some suggestions about what the IETF should do about it. Up until recently, the Internet made the transition from a research testbed to a tool used and depended upon by the research and education community. Now, the Internet is undergoing a rapid transition to a public facility open for use by all. The applications, the user community, and the infrastructure are all becoming commercialized at the same time. The IETF continues to provide technical solutions to support Internet development and growth, but the rapid transition is also raising many non-technical issues that must be addressed (but it is not yet clear by whom). The technical issues that must be addressed include better understanding the requirements from commercial users on network security, network management, accounting and billing and support for electronic commerce, as well as continuing to make progress on routing over multi-provider interconnections, introducing support for integrated services, and so on.
Yakov Rekhter gave a presentation on “Routing in a Multi-Provider Internet.” He described the current environment as one in which multiple network service providers are driven by diverse and sometimes conflicting goals. There is no central control over service providers, they often compete with each other, and they do not always coordinate effectively with each other. However, Internet-wide connectivity is possible only with a degree of cooperation and coordination. Yakov then went on to discuss routing requirements. Open questions include which are the most important requirements and who is to bear the cost of supporting the requirements. Scalability is a critical issue in routing, with a system that scales linearly with the number of providers one possibility. The talk ended with some other issues, such as other routing issues (multicast, mobile hosts) and the impact of a multi-provider Internet on other areas, such as network management.
There was considerable discussion following Yakov’s talk questioning the desirability of provider-based addressing for IPv6. Other topics included who “owns” the address space, how to financially compensate the registries so that they can continue to operate (one suggestion was to charge for queries to the registry rather than for storage of the information), and the specter of regulation of Internet service providers.
The final presentation was by Christian Huitema, who asked the question “The Internet Service Model: should we upgrade it?”. He described the current model, which provides connectivity (“IP over everything”) and best effort service with simple gateways and end-to-end controls. The current challenge is to control the service to support applications with more stringent real-time requirements, and to control the usage to avoid the risk of congestion. Proposed solutions include resource reservation with admission control to provide some form of service guarantees, fair queueing to isolate the “bad guys,” fair policing to punish the “bad guys,” and bandwidth sharing that enforces various policies. Christian ended his talk by raising a number of issues for debate, including what the service model should become, what router requirements should become, and so on.
IBM Research Division T.J. Watson Research Center
December 2, 1994
Multiple Network Service Providers (NSPs) driven by diverse and sometimes even conflicting goals and objectives:
Mission oriented NSPs (e.g. NSI)
Commercial NSPs (e.g. Alternet, PSI, etc…)
An NSP may constrain reselling connectivity
An NSP may be subject to regulations
Wide variations in the scope of geographical coverage
Ability to scale – key requirement for the Internet routing system
– CPU, memory, bandwidth
– human resources
+ System that scales linearly with the number of networks or even sites
– unacceptable today (CIDR is the best proof )
– unlikely to be acceptable in the future
+ Can we operate with a system that scales linearly with the number of providers ?
– how does the number of providers grow with the number of sites ?
Information aggregation/abstraction implies losses of information
– impact on route optimality
– impact on the ability to find a route
+ Aggregation/abstraction implies certain homogeneity
– needs to be balanced against potential diversity of routing requirements
Changes in the network topology may require changes in the IP addresses (“renumbering”)
– changing providers
– need tools to facilitate renumbering
+ Multi-layer hierarchy allows to recapture routing entropy
+ Hierarchical addresses are not a MUST
– large organizations can have their own address prefixes carried through the Internet
Presented some, but not all, of the issues
– multicast routing ?
– routing in presence of mobile hosts ?
– routing in presence of large shared media (e.g. ATM) ?
+ Impact of multi-provider Internet goes beyond routing (e.g. network management)
+ Need to understand interaction among all the areas involved from a system-wide perspective
Yakov Rekhter & Lixia Zhang
IAB Open Meeting
DEC’94 IETF
- What we’ve had in the past
- Where the Internet is going today
- What IETF should do
Commercialization of applications
We’re not the only one who found the Internet useful
+ Commercialization of user community
+ Commercialization of the infrastructure (service providers)
+ These three forces interact, creating a positive feedback that further accelerate the process
We (IETF) made this happen
1 New technology development by government sponsored research
ARPANET, early days of the Internet2 Technology mature
NSFNET backbone was built as an infrastructure for research/educational use3 Technology transfer
As commercial providers picking up the technology, NSF started buying services for research&educational use4 Market development
End users buy services directly from commercial providers (with gov. subsidy to R&E community)
Commercialization, however, also brought up many new and important non-technical issues. e.g.:
copyright issue of various electronic documents
We Have a lot to Accomplish