File: rfc2902.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (899 lines) | stat: -rw-r--r-- 32,773 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899






Network Working Group                                           S. Deering
Request for Comments: 2902                                   Cisco Systems
Category: Informational                                           S. Hares
                                                            Merit Networks
                                                                C. Perkins
                                                     Nokia Research Center
                                                                R. Perlman
                                             Sun Microsystems Laboratories
                                                               August 2000


               Overview of the 1998 IAB Routing Workshop

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document is an overview of a Routing workshop held by the
   Internet Architecture Board (IAB) during March 25-27, 1998.  The
   major points of discussion are listed, along with some conclusions
   and action items for many of the points of discussion.

Table of Contents

   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. Introduction

   March 25 to March 27, 1998 the Internet Architecture Board (IAB) held
   a workshop on Routing.  The workshop focused on current problems
   within the Internet and the long term solutions that should be
   addressed.  This document summarizes the discussions the group had on
   routing, and lists the conclusions reached by the workshop.  Section
   2 lists the conclusions reached by the participants of the workshop
   and the suggestions for additional work or redirection of current
   work.  Sections 2.1-2.10 attempt to extract the major points of what
   was, in actuality, many multifaceted discussions, sometimes occurring
   all at the same time.  Appendix A contains a list of the participants
   who attended the workshop.  The full body of the report can be found
   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 using
       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 improved
       services (Section 2.9)

   In addition the following topics were briefly covered:

    a. Multi-strand trunking
    b. Better tools for monitoring and diagnosis of network problems
    c. Routing protocol bandwidth minimization
    d. Automatic renumbering and automatic organization
    e. Anycast
    f. Load-sensitive routing
    g. Geographical addressing

   These shorter topics are contained in section 2.10.

   It would be unrealistic to assume that the workshop had definitive
   answers to all the technical problems that were raised.  The best
   that can be hoped is that we raised most of the relevant issues and
   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 to
   back up opinions.  Much of the discussion amounted to an exploration
   of the intuition of the experts in attendance, intuition gained after
   years of experience in making the Internet work.  More work is needed
   to validate the intuition and experience by way of scientific
   experimentation and analysis.  Unfortunately, it's not so easy to
   find a spare collection of global Internets upon which one might
   perform controlled experiments.

2. Conclusions and Action Items

   The participants came to a number of conclusions after the
   discussions referred to in sections 2.1-2.10.  These conclusions,
   presented in this document, provide summary statements and action
   items for the IETF community.

2.1. Scaling of Unicast Routing and Addressing

2.1.1. Unicast Routing - Conclusions

   The participants of the workshop came to the following conclusions

    1. Most of the current unicast routing stability problems can be
       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 the
       unicast routing are:

        -  Flaps - which will only get worse unless work is undertaken
        -  Multi-homing

    3. We'd like more research into what's breaking; not just more data,
       but more analysis of the data

   The group reviewed the following potential solutions:

    -  Architected NAT (improving the existing Network Address
       Translation schemes to provide better scaling)
    -  IPv6 (deploying an IP version 6 infrastructure)
    -  MAP/Encap (map to aggregatable addresses and encapsulate the
       original packet)
    -  Do nothing
    -  Aggressive renumbering (try to continue to encourage renumbering
       to improve utilization of the IP version 4 address space)
    -  Metro addressing (use a geographical or metropolitan based
       addressing scheme)

2.1.2. Unicast Routing - Action Items

   We recommend that the IRTF Routing Research group should encourage
   more analysis of routing data, not just the collection of more data.

2.2. Levels of Addressing of Addressing and Routing

   Levels of hierarchy do not matter to the customers.  Address
   hierarchy must be distinguished from routing hierarchy.  The group
   examined whether the current Internet has enough levels of hierarchy
   in Internet addresses or routing infrastructure.  The group did not
   find that levels of hierarchy should be added to the Internet, at
   least for now.  Flat routing at the AS level seems to be workable; if
   this changes in the future, hierarchy would need to be revisited, and
   studied with due consideration to convergence time for routing
   algorithms and trust management.  There is no universal agreement
   that adding levels of hierarchy at this point in time provides a
   well-defined benefit.  Furthermore, two levels is difficult for many
   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) devices

2.3.1. NAT devices - Conclusions

   Upon reviewing the NATs, the group

    1. Noted that NAT devices are fairly widely deployed
    2. Identified various problems with the use of NAT devices within
       the internet
    3. Discussed the interaction between NAT devices and applications
    4. Listed the following options regarding NAT devices:

        -  Eliminate NATs
        -  Fix NATs to interact better with the rest of the Internet
        -  Fix applications to interact better with NAT boxes
        -  Don't do certain things -- like IP Security (IPSec)

2.3.2. NAT devices - Action Items

   1. Forward our concerns, problems and suggestions to the appropriate
      working groups
   2. Note architectural work outside the NAT working group
   3. Suggest to the IAB that it continue to be concerned about the
      issues involving NATs

2.4. Multicast

2.4.1. Multicast - Conclusions

   Since the multicast model was created, many multicast applications
   have been tried over the Internet multicast routing fabric.  The
   group began to discuss the multicast model in terms of enabling
   multicast applications to run efficiently, and scale favorably with
   future growth.  Multicast applications place varying requirements on
   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 periods
    -  number of groups utilized per application or per set of
       cooperating applications, and
    -  amount of time during which the group exists
    -  topological distance between members of the group.
    -  volatility of membership




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 varying
   requirements of different multicast applications.  The current
   multicast model establishes multicast routing paths upon reception of
   a data packet.  The discussion on the viability of the multicast
   model examined the viability of the model in terms of the uses of
   multicast routing by applications and the scalability to full
   Internet usage.  For example, providing for many groups of small
   conferences (a small number of widely-dispersed people) with global
   topological scope scales badly given the current multicast model.

   The group felt the existing multicast protocols and multicast should
   be evaluated in terms of the requirements listed above.  The group
   suggested that the evaluation should include the multicast protocols
   DVMRP [12], MOSPF [8], PIM [4], CBT [2], and Express [5], as well as
   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 joins
       specify the core
    3. Having the ID of the group include the core, and having joins
       and data specify both
    4. Sending data via unicast to all members, and
    5. Sending data via unicast transport to the RP.

   The group acknowledged that the current multicast model does not
   scale well for all scenarios that applications use.

   The group noted that reliable multicast is surprisingly orthogonal to
   the issues about the scaling of the multicast model to all possible
   applications.

2.4.2. Multicast - Action Items

   Encourage evaluation and written reports on these multicast
   protocols, and mechanisms for different types of protocols.

   Notify the IRTF Routing Research Group of the need to charter
   activity in this area.

2.5. Routing Stability

2.5.1. Routing Stability - Conclusions

   Damping the effects of route updates enhances stability, but possibly
   at the cost of reachability for some prefixes.  A prefix can be
   damped and reachable via another path, so that for such prefixes the
   effects of damping are less serious than for other prefixes.  The
   performance of various algorithms for enhancing stability should be



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 are
   reachable or not reachable.  Using current damping approaches,
   approximately 1% of the prefixes are affected at any one point in
   time.  We should try to find out how many prefixes are unreachable
   because of damping.

2.5.2. Routing Stability - Action Items

   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 more
   stable.

2.6. ToS/CoS/QoS

   The group noted that the terms Type of Service (ToS), Class of
   Service (CoS), and Quality of Service (QoS) are imprecise as
   currently used.  The discussion started by defining the terminology
   as follows:

   ToS:  hop by hop routing based on destination plus ToS bits [9]
   CoS:  classes of service based on service contracts.  These classes
         of service are enabled by a variety of mechanisms which include
         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 requests
          *  setting up a path that satisfies the constraints
          *  routing the data

   There is no smooth dividing line between between ToS and QoS. ToS is
   relative.  QoS is absolute.  The group discussed whether there is a
   demand for ToS, CoS and QoS. Differentiated-services [3] as discussed
   in the IETF is ToS++.

   The group also discussed a more general concept of "Constraint Based
   Routing" which was defined as traffic engineering on large aggregated
   flows.  Constraint based routing allows the providers to better
   utilize the bandwidth in their network to handle traffic requests
   from users.  Besides enabling policy management techniques,
   constraint based routing allows providers to route traffic based on
   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 Items

   We recommend that IETF should look into the issue of Constraint Based
   Routing.

2.7. Routing Protocol Security

2.7.1. Routing Security - Conclusions

   After a lengthy discussion of the various problems of network
   security, the group notes that:

    1. Routers need intrinsic system security as good as or better than
       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 out
       of band, due to lack of wire speed authentication.
    6. We discussed other issues that will be passed on to the
       appropriate people involved with network security.
    7. Identified areas of work to improve things (e.g., wire speed
       authentication).

2.7.2. Routing Security - Action Items

   The IETF should encourage work on "wire speed" authentication, pair-
   wise authentication of routers in routing protocols, and Byzantine
   robustness [6] in routing protocols.

2.8. Routing Policy

2.8.1. Routing Policy - Conclusions

   During our discussion on routing policy the group reviewed what could
   be done with BGP. The group noted that:

    1. Some routing policies requested by ISPs or NSPs are not solvable
       with BGP. Some of these "unsolvable" routing policies can be put
       into effect using tunnels and static configuration.
    2. BGP is only a mechanism for announcing reachability
    3. BGP routing controls traffic direction without regard to traffic
       volume.
    4. BGP policy management is too delicate, too easy to mess up, and
       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-prone
    6. We can't count on symmetric routing, so ISPs/NSPs/Enterprise nets
       should deal with it.

   The group concluded the Internet needed a better routing policy
   specification language.

2.8.2. Routing Policy - Action Item

   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 Information

2.9.1. Host Information - Conclusions

   Publishing information about traffic statistics along backbone routes
   could improve the way Internet services replicate data for retrieval
   from various sites.  This replication could be especially important
   for the retrieval of information off the web.  Currently, web pages
   refer people to caches local to their sites; for instance, a European
   site might be used for United Kingdom customers and a North American
   site for North American customers.  Proponents of web caches want to
   auto-configure the locations of web caches so a user's web browser
   can automatically discover the local cache.  Other applications share
   this need for finding the best cache for a particular service.

2.9.2. Host Information - Action Items

   The group recommends a BOF be held on Measuring Path Characteristics.
   Measurement of path characteristics should include:

    -  format for exchange of measurement data
    -  mechanisms for distribution of measurement data

   IPPM working group [7] is dealing with issues within the measurement
   problem space.

2.10. Shorter Topics

2.10.1. Multi-strand Trunking

   PPP did multi-link in a way that required too much computation and
   could not be used for faster links.  Internet technology should treat
   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 Items

    There is design and development work at layer two which should be
    done to support the multiple parallel trunks.  This layer two work
    is outside the scope of the IETF. Layer three routing should
    support richer metrics in OSPF.

2.10.2. Routing Diagnostic and Development Tools

2.10.2.1. Routing Diagnostics - Conclusions

   1. It would be nice to have an Authoritative Database listing those
      prefixes permitted from each AS. The authoritative data base was
      attempted before without success, but the group felt it might be
      useful to try again.
   2. SNMP version 3 should be deployed in order to make use of its
      improved authentication, scope and rate limiting
   3. Remotely-controlled traffic monitors should be used to measure
      traffic
   4. Better tools are needed for preventative problem detection

2.10.2.2. Routing Diagnostics - Action Items

   1. Encouraged an authoritative database within the Internet
   2. Notify SNMP version 3 working groups regarding needs for
      authentication, scope, and rate limiting.
   3. Encourage funding of better tools for remotely controlled traffic
      sources and pro-active problem detection.

2.10.3. Anycast

2.10.3.1. Anycast - Conclusions

   1. We need to describe the advantages and disadvantages of anycast.
   2. Local-scoped well-known anycast addresses will be useful to
      applications.

2.10.3.2. Anycast - Action Items

   A BOF should be held to plan work on anycast.

   If a working group forms, a paper on the advantages and disadvantages
   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 Traffic

2.10.4.1. Load Sensitive IGP - Conclusions

   While load sensitive routing is interesting in some ways, it cannot
   be considered until certain problems are worked out.  Currently,
   constraint based routing is assigning administrative metrics to allow
   routing to adapt to different traffic patterns.  Load sensitive
   routing may increase oscillation and instability of routes.  This
   instability of routes, sometimes called churn, may affect the ability
   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 OSPF
   [10], Q-OSPF [10], and load sensitive routers developed by BBN.

2.10.4.2. Load Sensitive IGP - Action items

   The IRTF Routing Research group chair and Routing Area Director
   should discuss this subject and determine what techniques from Load
   Sensitive IGP routing are ready for IETF, and what requires
   additional research.

2.10.5. Geographical Addresses and Renumbering

   This topic was discussed, but without any conclusions or action
   items.

3. Summary of Action items

3.1. Action Items for the IAB

   1. The IAB should be concerned about the issues involving NATs
   2. Authoritative Database (for addresses within domains) should be
      encouraged within the Internet
   3. Encourage funding of better tools for remotely controlled traffic
      sources and pro-active problem detection.

3.2. Action Items for IETF Working Group Chairs

   1. NAT: Forward our concerns, problems and suggestions to the
      appropriate working groups
   2. We recommend that IETF should work the issue of Constraint Based
      Routing.
   3. The IETF should encourage work on "wire speed" authentication,
      pair-wise authentication of routers in routing protocols, and
      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 Path
      Characteristics.  The BOF should consider the data exchange format
      of measurement and mechanisms to distribution of data mechanism.
      It is noted that the IPPM working group is dealing with issues
      within the measurement problem space.
   6. There is layer two work which should be done to support the
      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 issues
      about authentication, scope, and rate limiting.
   8. A BOF should be held to plan work on anycast.  A document on
      anycast should be part of the proposed working group charter.

3.3. Action Items for the IRTF Routing Research Group

   1. We recommend that the IRTF Routing Research working group try to
      encourage more analysis of routing data, not just the collection
      of more data.

   2. Encourage evaluation and written reports on the evaluation of
      multicast protocols and mechanisms for different types of
      protocols

   3. The IRTF Routing Research group chair and the Routing Area
      Director should discuss Load Sensitive IGP routing and determine
      whether it is ready for the IETF.

4. Security Considerations

   Security considerations were an important part of the discussions at
   the workshop, but the workshop decided not to publish a summary of
   these discussions.  Other documents that address the issues of
   routing infrastructure security have recently been published.

A. Participants

      (Email addresses as of the meeting date.)

      Harald Alvestrand               Harald.Alvestrand@maxware.no
      Fred Baker                      fred@cisco.com
      Jeff Burgan                     burgan@corp.home.net
      Brian Carpenter                 brian@hursley.ibm.com
      Noel Chiappa                    jnc@ginger.lcs.mit.edu
      Rob Coltun                      rcoltun@fore.com
      Steve Deering                   deering@cisco.com
      Deborah Estrin                  estrin@usc.edu



Deering, et al.              Informational                     [Page 12]

RFC 2902       Overview of the 1998 IAB Routing Workshop     August 2000


      Dino Farinacci                  dino@cisco.com
      Paul Francis                    francis@slab.ntt.co.jp
      Elise Gerich                    epg@home.net
      Joel Halpern                    jhalpern@newbridge.com
      Sue Hares                       skh@merit.edu
      Cyndi Jung                      cmj@3Com.com
      Dave Katz                       dkatz@jnx.com
      Tony Li                         tli@juniper.net
      Peter Lothberg                  roll@stupi.se
      Louis Mamakos                   louie@uu.net
      Dave Meyer                      dmm@cisco.com
      Keith Moore                     moore@cs.utk.edu
      Bob Moskowitz                   rgm@htt-consult.com
      Thomas Narten                   narten@raleigh.ibm.com
      Vern Paxson                     vern@ee.lbl.gov
      Charles E. Perkins              cperkins@eng.sun.com
      Radia Perlman                   Radia.Perlman@East.Sun.COM
      Yakov Rekhter                   yakov@cisco.com
      Allyn Romanow                   allyn@MCI.NET
      Martha Steenstrup               msteenst@bbn.com
      George Swallow                  swallow@cisco.com

References

   [1]  Alaettinoglu, C., Bates, T., Gerich, E., Karrenberg, D., Meyer,
        D., Terpstra, M. and C. Villamizar, "Routing Policy
        Specification Language (RPSL)", RFC 2280, January 1998.

   [2]  Ballardie, A., "Core Based Trees (CBT) Multicast Routing
        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): Protocol
        Specification", RFC 2362, June 1998.

   [5]  Holbrook, H., Cheriton, D, "EXPRESS Multicast", SIGCOMM 99,
        September 1999.

   [6]  Charlie Kaufman, Radia Perlman, and Mike Speciner.  Network
        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 Metrics
        (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 of
        the Differentiated Services Field (DS Field) in the IPv4 and
        IPv6 Headers", RFC 2474, December 1998.

   [10]  H. Sandick and E. Crawley (chairs).  QoS Routing (qosr), April
        1997.  http://www.ietf.org/html.charters/qosr-charter.html.

   [11] C. Villamizar and C. Alaettinoglu (chairs).  Routing Policy
        Syntax (RPS), July 1995. http://www.ietf.org/html.charters/rps-
        charter.html.

   [12] Waitzman, D., Partridge, C. and S. Deering, "Distance Vector
        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' Addresses

   Questions about this memo can be directed to:

   Stephen E. Deering
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134-1706
   USA

   Phone:  +1 408 527-8213
   EMail:  deering@cisco.com


   Susan Hares
   Merit, Inc.
   1071 Beal Avenue,
   Ann Arbor, MI 48109
   USA

   Phone:  +1 313 936-2095
   EMail:  skh@nexthop.com


   Radia Perlman
   Sun Microsystems Laboratories
   2 Elizabeth Drive
   Chelmsford, MA 01824
   USA

   Phone:  +1 978 442-3252
   EMail:  Radia.Perlman@sun.com


   Charles E. Perkins
   Nokia Research Center
   313 Fairchild Drive
   Mountain View, CA 94043
   USA

   Phone:  +1 650 625-2986
   EMail:  Charles.Perkins@nokia.com
   Fax:    +1 650-625-2502








Deering, et al.              Informational                     [Page 15]

RFC 2902       Overview of the 1998 IAB Routing Workshop     August 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Deering, et al.              Informational                     [Page 16]