idnits 2.17.1 draft-iab-rtrws-over-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2280 (ref. '1') (Obsoleted by RFC 2622) ** Downref: Normative reference to an Historic RFC: RFC 2201 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '3') ** Obsolete normative reference: RFC 2362 (ref. '4') (Obsoleted by RFC 4601, RFC 5059) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Downref: Normative reference to an Historic RFC: RFC 1584 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. '11') Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Architecture Board Steve Deering 2 INTERNET DRAFT Cisco Systems 3 15 June 2000 Sue Hares 4 Merit Networks 5 Charles E. Perkins 6 Nokia Research Center 7 Radia Perlman 8 Sun Microsystems Laboratories 10 Overview of the 1998 IAB Routing Workshop 11 draft-iab-rtrws-over-03.txt 13 Status of This Memo 15 This document is a submission by the Internet Architecture Board 16 Working Group of the Internet Engineering Task Force (IETF). 17 Comments should be submitted to the 18 iab-routing-workshop@external.cisco.com mailing list. 20 Distribution of this memo is unlimited. 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its areas, 25 and its working groups. Note that other groups may also distribute 26 working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at 30 any time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at: 34 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at: 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This document is an overview of a Routing workshop held by the 41 Internet Architecture Board during March 25-27, 1998. The major 42 points of discussion are listed, along with some conclusions and 43 action items for many of the points of discussion. 45 Contents 47 Status of This Memo i 49 Abstract i 51 1. Introduction 1 53 2. Conclusions and Action Items 2 54 2.1. Scaling of Unicast Routing and Addressing . . . . . . . . 2 55 2.1.1. Unicast Routing - Conclusions . . . . . . . . . . 2 56 2.1.2. Unicast Routing - Action Items . . . . . . . . . 3 57 2.2. Levels of Addressing of Addressing and Routing . . . . . 3 58 2.3. Network Address Translation (NAT) devices . . . . . . . . 3 59 2.3.1. NAT devices - Conclusions . . . . . . . . . . . . 3 60 2.3.2. NAT devices - Action Items . . . . . . . . . . . 3 61 2.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.4.1. Multicast - Conclusions . . . . . . . . . . . . . 4 63 2.4.2. Multicast - Action Items . . . . . . . . . . . . 5 64 2.5. Routing Stability . . . . . . . . . . . . . . . . . . . . 5 65 2.5.1. Routing Stability - Conclusions . . . . . . . . . 5 66 2.5.2. Routing Stability - Action Items . . . . . . . . 5 67 2.6. ToS/CoS/QoS . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.6.1. ToS/CoS/QoS - Action Items . . . . . . . . . . . 6 69 2.7. Routing Protocol Security . . . . . . . . . . . . . . . . 6 70 2.7.1. Routing Security - Conclusions . . . . . . . . . 6 71 2.7.2. Routing Security - Action Items . . . . . . . . . 7 72 2.8. Routing Policy . . . . . . . . . . . . . . . . . . . . . 7 73 2.8.1. Routing Policy - Conclusions . . . . . . . . . . 7 74 2.8.2. Routing Policy - Action Item . . . . . . . . . . 7 75 2.9. Network to Host Flow of Information . . . . . . . . . . . 8 76 2.9.1. Host Information - Conclusions . . . . . . . . . 8 77 2.9.2. Host Information - Action Items . . . . . . . . . 8 78 2.10. Shorter Topics . . . . . . . . . . . . . . . . . . . . . 8 79 2.10.1. Multi-strand Trunking . . . . . . . . . . . . . . 8 80 2.10.2. Routing Diagnostic and Development Tools . . . . 9 81 2.10.3. Anycast . . . . . . . . . . . . . . . . . . . . . 9 82 2.10.4. Load Sensitive IGP routing for Best Effort Traffic 9 83 2.10.5. Geographical Addresses and Renumbering . . . . . 10 85 3. Summary of Action items 10 86 3.1. Action Items for the IAB . . . . . . . . . . . . . . . . 10 87 3.2. Action Items for IETF Working Group Chairs . . . . . . . 10 88 3.3. Action Items for the IRTF Routing Research Group . . . . 11 90 4. Security Considerations 11 91 A. Participants 12 93 References 12 95 Authors' Addresses 14 97 1. Introduction 99 From March 25 to March 27, 1998 the Internet Architecture Board 100 (IAB) held a workshop on Routing. The workshop focused on current 101 problems within the Internet and the long term solutions that should 102 be addressed. This document summarizes the discussions the group 103 had on routing, and lists the conclusions reached by the workshop. 104 Section 2 lists the conclusions reached by the participants of the 105 workshop and the suggestions for additional work or redirection of 106 current work. Sections 2.1-2.10 attempt to extract the major points 107 of what was, in actuality, many multifaceted discussions, sometimes 108 occuring all at the same time. Appendix A contains a list of the 109 participants who attended the workshop. The full body of the report 110 can be found at http://www.iab.org. 112 The topics covered at length during the IAB workshop were: 114 1. Scaling of Unicast Routing and Addressing (section 2.1) 115 2. Unicast Addressing Issues (Section 2.2) 116 3. The Effect of extending IP version 4 in the Internet by using 117 Network Address Transformation boxes (Section 2.3) 118 4. Multicast Routing (Section 2.4) 119 5. Routing Instability (Section 2.5) 120 6. Quality of Service Routing (Section 2.6) 121 7. Routing Security (Section 2.7) 122 8. BGP Policy (Section 2.8) 123 9. Flows of information from network routing to hosts for improved 124 services (Section 2.9) 126 In addition the following topics were briefly covered: 128 a. Multi-strand trunking 129 b. Better tools for monitoring and diagnosis of network problems 130 c. Routing protocol bandwidth minimization 131 d. Automatic renumbering and automatic organization 132 e. Anycast 133 f. Load-sensitive routing 134 g. Geographical addressing 136 These shorter topics are contained in section 2.10. 138 It would be unrealistic to assume that the workshop had definitive 139 answers to all the technical problems that were raised. The best 140 that can be hoped is that we raised most of the relevant issues and 141 gave opinions that were the best guess of the people at the meeting, 142 keeping in mind that the attendees did not come armed with data to 143 back up opinions. Much of the discussion amounted to an exploration 144 of the intuition of the experts in attendance, intuition gained 145 after years of experience in making the Internet work. More work is 146 needed to validate the intuition and experience by way of scientific 147 experimentation and analysis. Unfortunately, it's not so easy to 148 find a spare collection of global Internets upon which one might 149 perform controlled experiments. 151 2. Conclusions and Action Items 153 The participants came to a number of conclusions after the 154 discussions referred to in sections 2.1-2.10. These conclusions, 155 presented in this document, provide summary statements and action 156 items for the IETF community. 158 2.1. Scaling of Unicast Routing and Addressing 160 2.1.1. Unicast Routing - Conclusions 162 The participants of the workshop came to the following conclusions 164 1. Most of the current unicast routing stability problems can be 165 fixed with improved implementation. 167 2. Some long term systemic issues that may eventually overwhelm the 168 unicast routing are: 170 - Flaps - which will only get worse unless work is undertaken 171 - Multi-homing 173 3. We'd like more research into what's breaking; not just more data, 174 but more analysis of the data 176 The group reviewed the following potential solutions: 178 - Architected NAT (improving the existing Network Address 179 Translation schemes to provide better scaling) 180 - IPv6 (deploying an IP version 6 infrastructure) 181 - MAP/Encap (map to aggregatable addresses and encapsulate the 182 original packet) 183 - Do nothing 184 - Aggressive renumbering (try to continue to encourage renumbering 185 to improve utilization of the IP version 4 address space) 186 - Metro addressing (use a geographical or metropolitan based 187 addressing scheme) 189 2.1.2. Unicast Routing - Action Items 191 We recommend that the IRTF Routing Research group should encourage 192 more analysis of routing data, not just the collection of more data. 194 2.2. Levels of Addressing of Addressing and Routing 196 Levels of hierarchy do not matter to the customers. Address 197 hierarchy must be distinguished from routing hierarchy. The group 198 examined whether the current Internet has enough levels of hierarchy 199 in Internet addresses or routing infrastructure. The group did not 200 find that levels of hierarchy should be added to the Internet, at 201 least for now. Flat routing at the AS level seems to be workable; 202 if this changes in the future, hierarchy would need to be revisited, 203 and studied with due consideration to convergence time for routing 204 algorithms and trust management. There is no universal agreement 205 that adding levels of hierarchy at this point in time provides a 206 well-defined benefit. Furthermore, two levels is difficult for many 207 people, and any more than that is difficult both to build and to use. 209 2.3. Network Address Translation (NAT) devices 211 2.3.1. NAT devices - Conclusions 213 Upon reviewing the NATs, the group 215 1. Noted that NAT devices are fairly widely deployed 216 2. Identified various problems with the use of NAT devices within 217 the internet 218 3. Discussed the interaction between NAT devices and applications 219 4. Listed the following options regarding NAT devices: 220 - Eliminate NATs 221 - Fix NATs to interact better with the rest of the Internet 222 - Fix applications to interact better with NAT boxes 223 - Don't do certain things -- like IP Security (IPSec) 225 2.3.2. NAT devices - Action Items 227 1. Forward our concerns, problems and suggestions to the appropriate 228 working groups 230 2. Note architectural work outside the NAT working group 231 3. Suggest to the IAB that it continue to be concerned about the 232 issues involving NATs 234 2.4. Multicast 236 2.4.1. Multicast - Conclusions 238 Since the multicast model was created, many multicast applications 239 have been tried over the Internet multicast routing fabric. The 240 group began to discuss the multicast model in terms of enabling 241 multicast applications to run efficiently, and scale favorably with 242 future growth. Multicast applications place varying requirements on 243 multicast routing. 245 Multicast applications may have a variable: 247 - number of sources, 248 - number of receivers, 249 - amount of data, 250 - amount of data in a burst, and length of quiet periods 251 - number of groups utilized per application or per set of 252 cooperating applications, and 253 - amount of time during which the group exists 254 - topological distance between members of the group. 255 - volatility of membership 257 Multicast routing must provide the flexibility to support the varying 258 requirements of different multicast applications. The current 259 multicast model establishes multicast routing paths upon reception 260 of a data packet. The discussion on the viability of the multicast 261 model examined the viability of the model in terms of the uses 262 of multicast routing by applications and the scalability to full 263 Internet usage. For example, providing for many groups of small 264 conferences (a small number of widely-dispersed people) with global 265 topological scope scales badly given the current multicast model. 267 The group felt the existing multicast protocols and multicast should 268 be evaluated in terms of the requirements listed above. The group 269 suggested that the evaluation should include the multicast protocols 270 DVMRP [11], MOSPF [7], PIM [4], CBT [2], and Express (an unpublished 271 single-source multicast model proposed by Hugh Holbrook and David 272 Cheriton), as well as the following mechanisms used by multicast 273 applications: 275 1. Registering with the core or the RP (Rendezvous Point), 276 2. Having the ID of the group include the core, and having joins 277 specify the core 279 3. Having the ID of the group include the core, and having joins and 280 data specify both 281 4. Sending data via unicast to all members, and 282 5. Sending data via unicast transport to the RP. 284 The group acknowledged that the current multicast model does not 285 scale well for all scenarios that applications use. 287 The group noted that reliable multicast is surprisingly orthogonal to 288 the issues about the scaling of the multicast model to all possible 289 applications. 291 2.4.2. Multicast - Action Items 293 Encourage evaluation and written reports on these multicast 294 protocols, and mechanisms for different types of protocols. 296 Notify the IRTF Routing Research Group of the need to charter 297 activity in this area. 299 2.5. Routing Stability 301 2.5.1. Routing Stability - Conclusions 303 Damping the effects of route updates enhances stability, but possibly 304 at the cost of reachability for some prefixes. A prefix can be 305 damped and reachable via another path, so that for such prefixes the 306 effects of damping are less serious than for other prefixes. The 307 performance of various algorithms for enhancing stability should 308 be measured by recording whether the affected route prefixes are 309 reachable or not reachable. Using current damping approaches, 310 approximately 1% of the prefixes are affected at any one point in 311 time. We should try to find out how many prefixes are unreachable 312 because of damping. 314 2.5.2. Routing Stability - Action Items 316 The conclusion is that this effort merits continued investigation. 318 The IRTF Routing Research Group should measure how stable things are, 319 and if stability is an issue, to study methods of making them more 320 stable. 322 2.6. ToS/CoS/QoS 324 The group noted that the terms Type of Service (ToS), Class of 325 Service (CoS), and Quality of Service (QoS) are imprecise as 326 currently used. The discussion started by defining the terminology 327 as follows: 329 ToS: hop by hop routing based on destination plus ToS bits [8] 330 CoS: classes of service based on service contracts. These classes 331 of service are enabled by a variety of mechanisms which include 332 queueing, and multiple physical or link level paths. 333 QoS: managing routes that meet certain quality of service constraints, 334 and involving the following steps: 335 * routing the resource requests 336 * setting up a path that satisfies the constraints 337 * routing the data 339 There is no smooth dividing line between between ToS and QoS. ToS is 340 relative. QoS is absolute. The group discussed whether there is a 341 demand for ToS, CoS and QoS. Differentiated-services [3] as discussed 342 in the IETF is ToS++. 344 The group also discussed a more general concept of "Constraint 345 Based Routing" which was defined as traffic engineering on large 346 aggregated flows. Constraint based routing allows the providers 347 to better utilize the bandwidth in their network to handle traffic 348 requests from users. Besides enabling policy management techniques, 349 constraint based routing allows providers to route traffic based on 350 the characteristics of the traffic flows. 352 2.6.1. ToS/CoS/QoS - Action Items 354 We recommend that IETF should look into the issue of Constraint Based 355 Routing. 357 2.7. Routing Protocol Security 359 2.7.1. Routing Security - Conclusions 361 After a lengthy discussion of the various problems of network 362 security, the group notes that: 364 1. Routers need intrinsic system security as good as or better than 365 any host computer. 366 2. Improving router security will not solve all problems. 367 3. Console access to the router can do everything. 368 4. One compromised router can create disaster. 370 5. ISPs and vendors should consider taking some control traffic out 371 of band, due to lack of wire speed authentication. 372 6. We discussed other issues that will be passed on to the 373 appropriate people involved with network security. 374 7. Identified areas of work to improve things (e.g., wire speed 375 authentication). 377 2.7.2. Routing Security - Action Items 379 The IETF should encourage work on "wire speed" authentication, 380 pair-wise authentication of routers in routing protocols, and 381 Byzantine robustness [5] in routing protocols. 383 2.8. Routing Policy 385 2.8.1. Routing Policy - Conclusions 387 During our discussion on routing policy the group reviewed what could 388 be done with BGP. The group noted that: 390 1. Some routing policies requested by ISPs or NSPs are not solvable 391 with BGP. Some of these "unsolvable" routing policies can be put 392 into effect using tunnels and static configuration. 393 2. BGP is only a mechanism for announcing reachability 394 3. BGP routing controls traffic direction without regard to traffic 395 volume. 396 4. BGP policy management is too delicate, too easy to mess up, and 397 fragile. 398 5. Router Configuration Language is very complex and error-prone 399 6. We can't count on symmetric routing, so ISPs/NSPs/Enterprise nets 400 should deal with it. 402 The group concluded the Internet needed a better routing policy 403 specification language. 405 2.8.2. Routing Policy - Action Item 407 Pass the concerns about the Routing Policy Syntax Language (RPSL) [1] 408 to chairs of the Routing Policy Syntax (RPS) working group [10]. 410 2.9. Network to Host Flow of Information 412 2.9.1. Host Information - Conclusions 414 Publishing information about traffic statistics along backbone routes 415 could improve the way Internet services replicate data for retrieval 416 from various sites. This replication could be especially important 417 for the retrieval of information off the web. Currently, web pages 418 refer people to caches local to their sites; for instance, a European 419 site might be used for United Kingdom customers and a North American 420 site for North American customers. Proponents of web caches want to 421 auto-configure the locations of web caches so a user's web browser 422 can automatically discover the local cache. Other applications share 423 this need for finding the best cache for a particular service. 425 2.9.2. Host Information - Action Items 427 The group recommends a BOF be held on Measuring Path Characteristics. 428 Measurement of path characteristics should include: 430 - format for exchange of measurement data 431 - mechanisms for distribution of measurement data 433 IPPM working group [6] is dealing with issues within the measurement 434 problem space. 436 2.10. Shorter Topics 438 2.10.1. Multi-strand Trunking 440 PPP did multi-link in a way that required too much computation and 441 could not be used for faster links. Internet technology should 442 treat multiple parallel trunks as 1 link at the IP layer, but with 443 multi-dimensional metrics. 445 Multi-strand Trunking - Action Items 447 There is design and development work at layer two which should be 448 done to support the multiple parallel trunks. This layer two work 449 is outside the scope of the IETF. Layer three routing should support 450 richer metrics in OSPF. 452 2.10.2. Routing Diagnostic and Development Tools 454 2.10.2.1. Routing Diagnostics - Conclusions 456 1. It would be nice to have an Authoritative Database listing those 457 prefixes permitted from each AS. The authoritative data base was 458 attempted before without success, but the group felt it might be 459 useful to try again. 460 2. SNMP version 3 should be deployed in order to make use of its 461 improved authentication, scope and rate limiting 462 3. Remotely-controlled traffic monitors should be used to measure 463 traffic 464 4. Better tools are needed for preventative problem detection 466 2.10.2.2. Routing Diagnostics - Action Items 468 1. Encouraged an authoritative database within the Internet 469 2. Notify SNMP version 3 working groups regarding needs for 470 authentication, scope, and rate limiting. 471 3. Encourage funding of better tools for remotely controlled traffic 472 sources and pro-active problem detection. 474 2.10.3. Anycast 476 2.10.3.1. Anycast - Conclusions 478 1. We need to describe the advantages and disadvantages of anycast. 479 2. Local-scoped well-known anycast addresses will be useful to 480 applications. 482 2.10.3.2. Anycast - Action Items 484 A BOF should be held to plan work on anycast. 486 If a working group forms, a paper on the advantages and disadvantages 487 of anycast should be included as part of the charter. 489 2.10.4. Load Sensitive IGP routing for Best Effort Traffic 491 2.10.4.1. Load Sensitive IGP - Conclusions 493 While load sensitive routing is interesting in some ways, it cannot 494 be considered until certain problems are worked out. Currently, 495 constraint based routing is assigning administrative metrics to allow 496 routing to adapt to different traffic patterns. Load sensitive 497 routing may increase oscillation and instability of routes. This 498 instability of routes, sometimes called churn, may affect the ability 499 of the routing infrastructure to scale. 501 Load sensitive routing would allow IGPs to better utilize links. 502 Past and current efforts in load sensitive routing include: QoS 503 OSPF [9], Q-OSPF [9], and load sensitive routers developed by BBN. 505 2.10.4.2. Load Sensitive IGP - Action items 507 The IRTF Routing Research group chair and Routing Area Director 508 should discuss this subject and determine what techniques from 509 Load Sensitive IGP routing are ready for IETF, and what requires 510 additional research. 512 2.10.5. Geographical Addresses and Renumbering 514 This topic was discussed, but without any conclusions or action 515 items. 517 3. Summary of Action items 519 3.1. Action Items for the IAB 521 1. The IAB should be concerned about the issues involving NATs 522 2. Authoritative Database (for addresses within domains) should be 523 encouraged within the Internet 524 3. Encourage funding of better tools for remotely controlled traffic 525 sources and pro-active problem detection. 527 3.2. Action Items for IETF Working Group Chairs 529 1. NAT: Forward our concerns, problems and suggestions to the 530 appropriate working groups 531 2. We recommend that IETF should work the issue of Constraint Based 532 Routing. 533 3. The IETF should encourage work on "wire speed" authentication, 534 pair-wise authentication of routers in routing protocols, and 535 Byzantine robustness in routing protocols. 536 4. Concerns about the Routing Policy Specification Language (RPSL) 537 should go to the Routing Policy Systems (RPS) working group 538 chair. 539 5. The group recommends a BOF be held on Measuring Path 540 Characteristics. The BOF should consider the data exchange 541 format of measurement and mechanisms to distribution of data 542 mechanism. It is noted that the IPPM working group is dealing 543 with issues within the measurement problem space. 544 6. There is layer two work which should be done to support the 545 multiple parallel trunks which is outside the scope of the IETF. 546 Layer three routing should support richer metrics in OSPF. 547 7. SNMP version 3 working groups should be notified about the issues 548 about authentication, scope, and rate limiting. 549 8. A BOF should be held to plan work on anycast. A document on 550 anycast should be part of the proposed working group charter. 552 3.3. Action Items for the IRTF Routing Research Group 554 1. We recommend that the IRTF Routing Research working group try to 555 encourage more analysis of routing data, not just the collection 556 of more data. 558 2. Encourage evaluation and written reports on the evaluation 559 of multicast protocols and mechanisms for different types of 560 protocols 562 3. The IRTF Routing Research group chair and the Routing Area 563 Director should discuss Load Sensitive IGP routing and determine 564 whether it is ready for the IETF. 566 4. Security Considerations 568 Security considerations were an important part of the discussions 569 at the workshop, but the workshop decided not to publish a summary 570 of these discussions. Other documents that address the issues of 571 routing infrastructure security have recently been published. 573 A. Participants 575 Harald Alvestrand Harald.Alvestrand@maxware.no, 576 Fred Baker fred@cisco.com, 577 Jeff Burgan burgan@corp.home.net, 578 Brian Carpenter brian@hursley.ibm.com, 579 Noel Chiappa jnc@ginger.lcs.mit.edu, 580 Rob Coltun rcoltun@fore.com, 581 Steve Deering deering@cisco.com, 582 Deborah Estrin estrin@usc.edu, 583 Dino Farinacci dino@cisco.com, 584 Paul Francis francis@slab.ntt.co.jp, 585 Elise Gerich epg@home.net, 586 Joel Halpern jhalpern@newbridge.com, 587 Sue Hares skh@merit.edu, 588 Cyndi Jung cmj@3Com.com, 589 Dave Katz dkatz@jnx.com, 590 Tony Li tli@juniper.net, 591 Peter Lothberg roll@stupi.se, 592 Louis Mamakos louie@uu.net, 593 Dave Meyer dmm@cisco.com, 594 Keith Moore moore@cs.utk.edu, 595 Bob Moskowitz rgm@htt-consult.com, 596 Thomas Narten narten@raleigh.ibm.com, 597 Vern Paxson vern@ee.lbl.gov, 598 Charlie Perkins Charles.Perkins@iprg.nokia.com 599 Radia Perlman Radia.Perlman@East.Sun.COM, 600 Yakov Rekhter yakov@cisco.com, 601 Allyn Romanow allyn@MCI.NET, 602 Martha Steenstrup msteenst@bbn.com, 603 George Swallow swallow@cisco.com, 605 References 607 [1] C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, 608 M. Terpstra, and C. Villamizar. Routing Policy Specification 609 Language (RPSL). Request for Comments (Proposed Standard) 2280, 610 Internet Engineering Task Force, January 1998. 612 [2] A. Ballardie. Core Based Trees (CBT) Multicast Routing 613 Architecture. Request for Comments (Experimental) 2201, 614 Internet Engineering Task Force, September 1997. 616 [3] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and 617 W. Weiss. An Architecture for Differentiated Service. Request 618 for Comments (Informational) 2475, Internet Engineering Task 619 Force, December 1998. 621 [4] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, 622 M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. 623 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol 624 Specification. Request for Comments (Experimental) 2362, 625 Internet Engineering Task Force, June 1998. 627 [5] Charlie Kaufman, Radia Perlman, and Mike Speciner. Network 628 Security: Private Communication in a Public World, pages 629 462--465. Prentice-Hall, Inc., 1995. 631 [6] W. Leland and M. Zekauskas (chairs). IP Performance Metrics 632 (IPPM), October 1997. 633 http://www.ietf.org/html.charters/ippm-charter.html. 635 [7] J. Moy. Multicast Extensions to OSPF. Request for Comments 636 (Proposed Standard) 1584, Internet Engineering Task Force, March 637 1994. 639 [8] K. Nichols, S. Blake, F. Baker, and D. Black. Definition of 640 the Differentiated Services Field (DS Field) in the IPv4 and 641 IPv6 Headers. Request for Comments (Proposed Standard) 2474, 642 Internet Engineering Task Force, December 1998. 644 [9] H. Sandick and E. Crawley (chairs). QoS Routing (qosr), April 645 1997. http://www.ietf.org/html.charters/qosr-charter.html. 647 [10] C. Villamizar and C. Alaettinoglu (chairs). Routing Policy 648 Syntax (RPS), July 1995. 649 http://www.ietf.org/html.charters/rps-charter.html. 651 [11] D. Waitzman, C. Partridge, and S. E. Deering. Distance Vector 652 Multicast Routing Protocol. Request for Comments (Experimental) 653 1075, Internet Engineering Task Force, November 1988. 655 Authors' Addresses 657 Questions about this memo can be directed to: 659 Stephen E. Deering Susan Hares 660 Cisco Systems, Inc. Merit, Inc. 661 170 West Tasman Drive 1071 Beal Avenue, 662 San Jose, CA 95134-1706 Ann Arbor, MI 48109 663 USA USA 665 Phone: +1 408 527-8213 Phone: +1 313 936-2095 666 EMail: deering@cisco.com EMail: skh@merit.edu 668 Radia Perlman Charles E. Perkins 669 Sun Microsystems Laboratories Nokia Research Center 670 2 Elizabeth Drive 313 Fairchild Drive 671 Chelmsford, MA 01824 Mountain View, CA 94043 672 USA USA 674 Phone: +1 978 442-3252 Phone: +1 650 625-2986 675 EMail: Radia.Perlman@sun.com EMail: charliep@iprg.nokia.com 676 Fax: +1 650 691-2170