As per Relevance of the word workshop, we have this rfc below:
Network Working Group S.
Request for Comments: 2902 Cisco
Category: Informational S.
Merit
C.
Nokia Research
R.
Sun Microsystems
August 2000
Overview of the 1998 IAB Routing
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document is an overview of a Routing workshop held by
Internet Architecture Board (IAB) during March 25-27, 1998.
major points of discussion are listed, along with some
and action items for many of the points of discussion
Table of
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conclusions and Action Items . . . . . . . . . . . . . . . . 3
2.1. Scaling of Unicast Routing and Addressing . . . . . . . 3
2.1.1. Unicast Routing - Conclusions . . . . . . . . . . . 3
2.1.2. Unicast Routing - Action Items . . . . . . . . . . 4
2.2. Levels of Addressing of Addressing and Routing . . . . 4
2.3. Network Address Translation (NAT) devices . . . . . . . 5
2.3.1. NAT devices - Conclusions . . . . . . . . . . . . . 5
2.3.2. NAT devices - Action Items . . . . . . . . . . . . 5
2.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . 5
2.4.1. Multicast - Conclusions . . . . . . . . . . . . . . 5
2.4.2. Multicast - Action Items . . . . . . . . . . . . . 6
2.5. Routing Stability . . . . . . . . . . . . . . . . . . . 6
2.5.1. Routing Stability - Conclusions . . . . . . . . . . 6
2.5.2. Routing Stability - Action Items . . . . . . . . . 7
2.6. ToS/CoS/QoS . . . . . . . . . . . . . . . . . . . . . . 7
Deering, et al. Informational [Page 1]
RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
2.6.1. ToS/CoS/QoS - Action Items . . . . . . . . . . . . 8
2.7. Routing Protocol Security . . . . . . . . . . . . . . . 8
2.7.1. Routing Security - Conclusions . . . . . . . . . . 8
2.7.2. Routing Security - Action Items . . . . . . . . . . 8
2.8. Routing Policy . . . . . . . . . . . . . . . . . . . . 8
2.8.1. Routing Policy - Conclusions . . . . . . . . . . . 8
2.8.2. Routing Policy - Action Item . . . . . . . . . . . 9
2.9. Network to Host Flow of Information . . . . . . . . . . 9
2.9.1. Host Information - Conclusions . . . . . . . . . . 9
2.9.2. Host Information - Action Items . . . . . . . . . . 9
2.10. Shorter Topics . . . . . . . . . . . . . . . . . . . . 9
2.10.1. Multi-strand Trunking . . . . . . . . . . . . . . 9
2.10.2. Routing Diagnostic and Development Tools . . . . 10
2.10.3. Anycast . . . . . . . . . . . . . . . . . . . . . 10
2.10.4. Load Sensitive IGP routing for Best Effort Traffic 11
2.10.5. Geographical Addresses and Renumbering . . . . . 11
3. Summary of Action items . . . . . . . . . . . . . . . . . . . 11
3.1. Action Items for the IAB . . . . . . . . . . . . . . . 11
3.2. Action Items for IETF Working Group Chairs . . . . . . 11
3.3. Action Items for the IRTF Routing Research Group . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
A. Participants . . . . . . . . . . . . . . . . . . . . . . . . 12
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 16
1.
March 25 to March 27, 1998 the Internet Architecture Board (IAB)
a workshop on Routing. The workshop focused on current
within the Internet and the long term solutions that should
addressed. This document summarizes the discussions the group had
routing, and lists the conclusions reached by the workshop.
2 lists the conclusions reached by the participants of the
and the suggestions for additional work or redirection of
work. Sections 2.1-2.10 attempt to extract the major points of
was, in actuality, many multifaceted discussions, sometimes
all at the same time. Appendix A contains a list of the
who attended the workshop. The full body of the report can be
at http://www.iab.org
The topics covered at length during the IAB workshop were
1. Scaling of Unicast Routing and Addressing (section 2.1)
2. Unicast Addressing Issues (Section 2.2)
3. The Effect of extending IP version 4 in the Internet by
Network Address Transformation boxes (Section 2.3)
4. Multicast Routing (Section 2.4)
Deering, et al. Informational [Page 2]
RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
5. Routing Instability (Section 2.5)
6. Quality of Service Routing (Section 2.6)
7. Routing Security (Section 2.7)
8. BGP Policy (Section 2.8)
9. Flows of information from network routing to hosts for
services (Section 2.9)
In addition the following topics were briefly covered
a. Multi-strand
b. Better tools for monitoring and diagnosis of network
c. Routing protocol bandwidth
d. Automatic renumbering and automatic
e.
f. Load-sensitive
g. Geographical
These shorter topics are contained in section 2.10.
It would be unrealistic to assume that the workshop had
answers to all the technical problems that were raised. The
that can be hoped is that we raised most of the relevant issues
gave opinions that were the best guess of the people at the meeting
keeping in mind that the attendees did not come armed with data
back up opinions. Much of the discussion amounted to an
of the intuition of the experts in attendance, intuition gained
years of experience in making the Internet work. More work is
to validate the intuition and experience by way of
experimentation and analysis. Unfortunately, it's not so easy
find a spare collection of global Internets upon which one
perform controlled experiments
2. Conclusions and Action
The participants came to a number of conclusions after
discussions referred to in sections 2.1-2.10. These conclusions
presented in this document, provide summary statements and
items for the IETF community
2.1. Scaling of Unicast Routing and
2.1.1. Unicast Routing -
The participants of the workshop came to the following
1. Most of the current unicast routing stability problems can
fixed with improved implementation
Deering, et al. Informational [Page 3]
RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
2. Some long term systemic issues that may eventually overwhelm
unicast routing are
- Flaps - which will only get worse unless work is
- Multi-
3. We'd like more research into what's breaking; not just more data
but more analysis of the
The group reviewed the following potential solutions
- Architected NAT (improving the existing Network
Translation schemes to provide better scaling
- IPv6 (deploying an IP version 6 infrastructure
- MAP/Encap (map to aggregatable addresses and encapsulate
original packet
- Do
- Aggressive renumbering (try to continue to encourage
to improve utilization of the IP version 4 address space
- Metro addressing (use a geographical or metropolitan
addressing scheme
2.1.2. Unicast Routing - Action
We recommend that the IRTF Routing Research group should
more analysis of routing data, not just the collection of more data
2.2. Levels of Addressing of Addressing and
Levels of hierarchy do not matter to the customers.
hierarchy must be distinguished from routing hierarchy. The
examined whether the current Internet has enough levels of
in Internet addresses or routing infrastructure. The group did
find that levels of hierarchy should be added to the Internet,
least for now. Flat routing at the AS level seems to be workable;
this changes in the future, hierarchy would need to be revisited,
studied with due consideration to convergence time for
algorithms and trust management. There is no universal
that adding levels of hierarchy at this point in time provides
well-defined benefit. Furthermore, two levels is difficult for
people, and any more than that is difficult both to build and to use
Deering, et al. Informational [Page 4]
RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
2.3. Network Address Translation (NAT)
2.3.1. NAT devices -
Upon reviewing the NATs, the
1. Noted that NAT devices are fairly widely
2. Identified various problems with the use of NAT devices
the
3. Discussed the interaction between NAT devices and
4. Listed the following options regarding NAT devices
- Eliminate
- Fix NATs to interact better with the rest of the
- Fix applications to interact better with NAT
- Don't do certain things -- like IP Security (IPSec
2.3.2. NAT devices - Action
1. Forward our concerns, problems and suggestions to the
working
2. Note architectural work outside the NAT working
3. Suggest to the IAB that it continue to be concerned about
issues involving
2.4.
2.4.1. Multicast -
Since the multicast model was created, many multicast
have been tried over the Internet multicast routing fabric.
group began to discuss the multicast model in terms of
multicast applications to run efficiently, and scale favorably
future growth. Multicast applications place varying requirements
multicast routing
Multicast applications may have a variable
- number of sources
- number of receivers
- amount of data
- amount of data in a burst, and length of quiet
- number of groups utilized per application or per set
cooperating applications,
- amount of time during which the group
- topological distance between members of the group
- volatility of
Deering, et al. Informational [Page 5]
RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
Multicast routing must provide the flexibility to support the
requirements of different multicast applications. The
multicast model establishes multicast routing paths upon reception
a data packet. The discussion on the viability of the
model examined the viability of the model in terms of the uses
multicast routing by applications and the scalability to
Internet usage. For example, providing for many groups of
conferences (a small number of widely-dispersed people) with
topological scope scales badly given the current multicast model
The group felt the existing multicast protocols and multicast
be evaluated in terms of the requirements listed above. The
suggested that the evaluation should include the multicast
DVMRP [12], MOSPF [8], PIM [4], CBT [2], and Express [5], as well
the following mechanisms used by multicast applications
1. Registering with the core or the RP (Rendezvous Point),
2. Having the ID of the group include the core, and having
specify the
3. Having the ID of the group include the core, and having
and data specify
4. Sending data via unicast to all members,
5. Sending data via unicast transport to the RP
The group acknowledged that the current multicast model does
scale well for all scenarios that applications use
The group noted that reliable multicast is surprisingly orthogonal
the issues about the scaling of the multicast model to all
applications
2.4.2. Multicast - Action
Encourage evaluation and written reports on these
protocols, and mechanisms for different types of protocols
Notify the IRTF Routing Research Group of the need to
activity in this area
2.5. Routing
2.5.1. Routing Stability -
Damping the effects of route updates enhances stability, but
at the cost of reachability for some prefixes. A prefix can
damped and reachable via another path, so that for such prefixes
effects of damping are less serious than for other prefixes.
performance of various algorithms for enhancing stability should
Deering, et al. Informational [Page 6]
RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
measured by recording whether the affected route prefixes
reachable or not reachable. Using current damping approaches
approximately 1% of the prefixes are affected at any one point
time. We should try to find out how many prefixes are
because of damping
2.5.2. Routing Stability - Action
The conclusion is that this effort merits continued investigation
The IRTF Routing Research Group should measure how stable things are
and if stability is an issue, to study methods of making them
stable
2.6. ToS/CoS/
The group noted that the terms Type of Service (ToS), Class
Service (CoS), and Quality of Service (QoS) are imprecise
currently used. The discussion started by defining the
as follows
ToS: hop by hop routing based on destination plus ToS bits [9]
CoS: classes of service based on service contracts. These
of service are enabled by a variety of mechanisms which
queueing, and multiple physical or link level paths
QoS: managing routes that meet certain quality of service constraints
and involving the following steps
* routing the resource
* setting up a path that satisfies the
* routing the
There is no smooth dividing line between between ToS and QoS. ToS
relative. QoS is absolute. The group discussed whether there is
demand for ToS, CoS and QoS. Differentiated-services [3] as
in the IETF is ToS++.
The group also discussed a more general concept of "Constraint
Routing" which was defined as traffic engineering on large
flows. Constraint based routing allows the providers to
utilize the bandwidth in their network to handle traffic
from users. Besides enabling policy management techniques
constraint based routing allows providers to route traffic based
the characteristics of the traffic flows
Deering, et al. Informational [Page 7]
RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
2.6.1. ToS/CoS/QoS - Action
We recommend that IETF should look into the issue of Constraint
Routing
2.7. Routing Protocol
2.7.1. Routing Security -
After a lengthy discussion of the various problems of
security, the group notes that
1. Routers need intrinsic system security as good as or better
any host computer
2. Improving router security will not solve all problems
3. Console access to the router can do everything
4. One compromised router can create disaster
5. ISPs and vendors should consider taking some control traffic
of band, due to lack of wire speed authentication
6. We discussed other issues that will be passed on to
appropriate people involved with network security
7. Identified areas of work to improve things (e.g., wire
authentication).
2.7.2. Routing Security - Action
The IETF should encourage work on "wire speed" authentication, pair
wise authentication of routers in routing protocols, and
robustness [6] in routing protocols
2.8. Routing
2.8.1. Routing Policy -
During our discussion on routing policy the group reviewed what
be done with BGP. The group noted that
1. Some routing policies requested by ISPs or NSPs are not
with BGP. Some of these "unsolvable" routing policies can be
into effect using tunnels and static configuration
2. BGP is only a mechanism for announcing
3. BGP routing controls traffic direction without regard to
volume
4. BGP policy management is too delicate, too easy to mess up,
fragile
Deering, et al. Informational [Page 8]
RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
5. Router Configuration Language is very complex and error-
6. We can't count on symmetric routing, so ISPs/NSPs/Enterprise
should deal with it
The group concluded the Internet needed a better routing
specification language
2.8.2. Routing Policy - Action
Pass the concerns about the Routing Policy Syntax Language (RPSL) [1]
to chairs of the Routing Policy Syntax (RPS) working group [11].
2.9. Network to Host Flow of
2.9.1. Host Information -
Publishing information about traffic statistics along backbone
could improve the way Internet services replicate data for
from various sites. This replication could be especially
for the retrieval of information off the web. Currently, web
refer people to caches local to their sites; for instance, a
site might be used for United Kingdom customers and a North
site for North American customers. Proponents of web caches want
auto-configure the locations of web caches so a user's web
can automatically discover the local cache. Other applications
this need for finding the best cache for a particular service
2.9.2. Host Information - Action
The group recommends a BOF be held on Measuring Path Characteristics
Measurement of path characteristics should include
- format for exchange of measurement
- mechanisms for distribution of measurement
IPPM working group [7] is dealing with issues within the
problem space
2.10. Shorter
2.10.1. Multi-strand
PPP did multi-link in a way that required too much computation
could not be used for faster links. Internet technology should
multiple parallel trunks as 1 link at the IP layer, but with multi
dimensional metrics
Deering, et al. Informational [Page 9]
RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
Multi-strand Trunking - Action
There is design and development work at layer two which should
done to support the multiple parallel trunks. This layer two
is outside the scope of the IETF. Layer three routing
support richer metrics in OSPF
2.10.2. Routing Diagnostic and Development
2.10.2.1. Routing Diagnostics -
1. It would be nice to have an Authoritative Database listing
prefixes permitted from each AS. The authoritative data base
attempted before without success, but the group felt it might
useful to try again
2. SNMP version 3 should be deployed in order to make use of
improved authentication, scope and rate
3. Remotely-controlled traffic monitors should be used to
4. Better tools are needed for preventative problem
2.10.2.2. Routing Diagnostics - Action
1. Encouraged an authoritative database within the
2. Notify SNMP version 3 working groups regarding needs
authentication, scope, and rate limiting
3. Encourage funding of better tools for remotely controlled
sources and pro-active problem detection
2.10.3.
2.10.3.1. Anycast -
1. We need to describe the advantages and disadvantages of anycast
2. Local-scoped well-known anycast addresses will be useful
applications
2.10.3.2. Anycast - Action
A BOF should be held to plan work on anycast
If a working group forms, a paper on the advantages and
of anycast should be included as part of the charter
Deering, et al. Informational [Page 10]
RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
2.10.4. Load Sensitive IGP routing for Best Effort
2.10.4.1. Load Sensitive IGP -
While load sensitive routing is interesting in some ways, it
be considered until certain problems are worked out. Currently
constraint based routing is assigning administrative metrics to
routing to adapt to different traffic patterns. Load
routing may increase oscillation and instability of routes.
instability of routes, sometimes called churn, may affect the
of the routing infrastructure to scale
Load sensitive routing would allow IGPs to better utilize links
Past and current efforts in load sensitive routing include: QoS
[10], Q-OSPF [10], and load sensitive routers developed by BBN
2.10.4.2. Load Sensitive IGP - Action
The IRTF Routing Research group chair and Routing Area
should discuss this subject and determine what techniques from
Sensitive IGP routing are ready for IETF, and what
additional research
2.10.5. Geographical Addresses and
This topic was discussed, but without any conclusions or
items
3. Summary of Action
3.1. Action Items for the
1. The IAB should be concerned about the issues involving
2. Authoritative Database (for addresses within domains) should
encouraged within the
3. Encourage funding of better tools for remotely controlled
sources and pro-active problem detection
3.2. Action Items for IETF Working Group
1. NAT: Forward our concerns, problems and suggestions to
appropriate working
2. We recommend that IETF should work the issue of Constraint
Routing
3. The IETF should encourage work on "wire speed" authentication
pair-wise authentication of routers in routing protocols,
Byzantine robustness in routing protocols
Deering, et al. Informational [Page 11]
RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
4. Concerns about the Routing Policy Specification Language (RPSL
should go to the Routing Policy Systems (RPS) working group chair
5. The group recommends a BOF be held on Measuring
Characteristics. The BOF should consider the data exchange
of measurement and mechanisms to distribution of data mechanism
It is noted that the IPPM working group is dealing with
within the measurement problem space
6. There is layer two work which should be done to support
multiple parallel trunks which is outside the scope of the IETF
Layer three routing should support richer metrics in OSPF
7. SNMP version 3 working groups should be notified about the
about authentication, scope, and rate limiting
8. A BOF should be held to plan work on anycast. A document
anycast should be part of the proposed working group charter
3.3. Action Items for the IRTF Routing Research
1. We recommend that the IRTF Routing Research working group try
encourage more analysis of routing data, not just the
of more data
2. Encourage evaluation and written reports on the evaluation
multicast protocols and mechanisms for different types
3. The IRTF Routing Research group chair and the Routing
Director should discuss Load Sensitive IGP routing and
whether it is ready for the IETF
4. Security
Security considerations were an important part of the discussions
the workshop, but the workshop decided not to publish a summary
these discussions. Other documents that address the issues
routing infrastructure security have recently been published
A.
(Email addresses as of the meeting date.)
Harald Alvestrand Harald.Alvestrand@maxware.
Fred Baker fred@cisco.
Jeff Burgan burgan@corp.home.
Brian Carpenter brian@hursley.ibm.
Noel Chiappa jnc@ginger.lcs.mit.
Rob Coltun rcoltun@fore.
Steve Deering deering@cisco.
Deborah Estrin estrin@usc.
Deering, et al. Informational [Page 12]
RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
Dino Farinacci dino@cisco.
Paul Francis francis@slab.ntt.co.
Elise Gerich epg@home.
Joel Halpern jhalpern@newbridge.
Sue Hares skh@merit.
Cyndi Jung cmj@3Com.
Dave Katz dkatz@jnx.
Tony Li tli@juniper.
Peter Lothberg roll@stupi.
Louis Mamakos louie@uu.
Dave Meyer dmm@cisco.
Keith Moore moore@cs.utk.
Bob Moskowitz rgm@htt-consult.
Thomas Narten narten@raleigh.ibm.
Vern Paxson vern@ee.lbl.
Charles E. Perkins cperkins@eng.sun.
Radia Perlman Radia.Perlman@East.Sun.
Yakov Rekhter yakov@cisco.
Allyn Romanow allyn@MCI.
Martha Steenstrup msteenst@bbn.
George Swallow swallow@cisco.
[1] Alaettinoglu, C., Bates, T., Gerich, E., Karrenberg, D., Meyer
D., Terpstra, M. and C. Villamizar, "Routing
Specification Language (RPSL)", RFC 2280, January 1998.
[2] Ballardie, A., "Core Based Trees (CBT) Multicast
Architecture", RFC 2201, September 1997.
[3] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W
Weiss, "An Architecture for Differentiated Service", RFC 2475,
December 1998.
[4] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S.,
Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei
"Protocol Independent Multicast-Sparse Mode (PIM-SM):
Specification", RFC 2362, June 1998.
[5] Holbrook, H., Cheriton, D, "EXPRESS Multicast", SIGCOMM 99,
September 1999.
[6] Charlie Kaufman, Radia Perlman, and Mike Speciner.
Security: Private Communication in a Public World, pages 462--
465. Prentice-Hall, Inc., 1995.
Deering, et al. Informational [Page 13]
RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
[7] W. Leland and M. Zekauskas (chairs). IP Performance
(IPPM), October 1997. http://www.ietf.org/html.charters/ippm
charter.html
[8] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[9] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition
the Differentiated Services Field (DS Field) in the IPv4
IPv6 Headers", RFC 2474, December 1998.
[10] H. Sandick and E. Crawley (chairs). QoS Routing (qosr),
1997. http://www.ietf.org/html.charters/qosr-charter.html
[11] C. Villamizar and C. Alaettinoglu (chairs). Routing
Syntax (RPS), July 1995. http://www.ietf.org/html.charters/rps
charter.html
[12] Waitzman, D., Partridge, C. and S. Deering, "Distance
Multicast Routing Protocol", RFC 1075, November 1988.
Deering, et al. Informational [Page 14]
RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
Authors'
Questions about this memo can be directed to
Stephen E.
Cisco Systems, Inc
170 West Tasman
San Jose, CA 95134-1706
Phone: +1 408 527-8213
EMail: deering@cisco.
Susan
Merit, Inc
1071 Beal Avenue
Ann Arbor, MI 48109
Phone: +1 313 936-2095
EMail: skh@nexthop.
Radia
Sun Microsystems
2 Elizabeth
Chelmsford, MA 01824
Phone: +1 978 442-3252
EMail: Radia.Perlman@sun.
Charles E.
Nokia Research
313 Fairchild
Mountain View, CA 94043
Phone: +1 650 625-2986
EMail: Charles.Perkins@nokia.
Fax: +1 650-625-2502
Deering, et al. Informational [Page 15]
RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Deering, et al. Informational [Page 16]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
