home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / osinsap / osinsap-minutes-90may.txt < prev    next >
Text File  |  1993-02-17  |  7KB  |  165 lines

  1.  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by Philip Almquist/ Consultant
  7.  
  8. General Issues
  9.  
  10.  
  11.   1. How is what we do constrained by existing GSA procedures?  Not
  12.      much, apparently, since GSA will probably modify their planned
  13.      procedures if NIST so recommends.
  14.   2. Where should the output of this group go?  An RFC, most likely, and
  15.      we should (and probably can) also get it into the GOSIP User's
  16.      Guide.
  17.   3. Have we gotten foreign comments on the draft paper?  Basically, no.
  18.      This may not be problem since most foreign sites may want to get
  19.      NSAP addresses from their national authorities rather than the
  20.      Internet.  However, comments from non-US members of the Internet
  21.      are encouraged.
  22.  
  23.  
  24. Discussion of the Draft Document
  25.  
  26. Unfortunately, a number of the attendees had been unable to read the
  27. paper carefully beforehand, because it was distributed in Postscript
  28. that didn't seem to be printable on some printers.  The chair promised
  29. that this problem would be resolved before the next meeting.
  30.  
  31. Mary Youssef noted that the document did not adequately address how
  32. large routing domains should be or will be; nor does it discuss how
  33. interdomain routing will be accomplished.  It is crucial to understand
  34. these issues if we want to design a scheme that will be practical given
  35. the political and technical realities of the Internet.  Desire for local
  36. autonomy will provide a push towards small routing domains (similar in
  37. size to IP autonomous systems), whereas the current lack of an
  38. interdomain routing protocol will provide a push towards very large
  39. routing domains (for example, a regional network and its members might
  40. form a single routing domain).  Ross Callon suggested that we were
  41. overreacting to the lack of an interdomain routing protocol because
  42. Internet deployment of OSI would be slow enough that static interdomain
  43. routing would work until OSI has a real protocol for this purpose.  Tony
  44. Hain disagreed, noting that DOE will have 50-100 routing domains once
  45. they deploy DECNet Phase V. Rob Hagens spoke strongly against making
  46. kludges in our design for the sake of short term workability.
  47.  
  48. Someone pointed out that, for NSAP assignment, we should be concerned
  49. about the size of administrative domains rather than routing domains.
  50. An ``administrative domain'' is one or more routing domains that share
  51. the same NSAP address prefix.  Thus, it is the size and distribution of
  52. administrative domains that determines how large the Internet can grow
  53. before it collapses under the weight of the amount of information that
  54. must be carried around in the interdomain routing protocol.  It was
  55. pointed out that the term "administrative domain" is a politically
  56.  
  57.                                    1
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64. unwise choice of wording, since it suggests that members of an
  65. administrative domain have to cede administrative control of their
  66. networks to the administrative domain, when in fact the only thing that
  67. has to be centralized is the allocation of blocks of NSAP addresses.
  68.  
  69. For example, a regional network could obtain a block of NSAP addresses
  70. and become an administrative domain, allocating chunks of its block of
  71. NSAP addresses to individual campuses.  The regional would only have to
  72. advertise to backbone networks its single block of NSAP addresses (via a
  73. single prefix), rather than one or more per campus as is done in the IP
  74. world.  However, there are some cases where a campus might have a good
  75. reason to use NSAP addresses that were not from the regional's block of
  76. addresses, but regionals could (and probably should?)  charge extra for
  77. advertising these addresses to national backbones to discourage address
  78. entropy and the resultant excessive growth of routing information in the
  79. Internet.  However, we need to be sure that we don't create policies
  80. which have the side effect of making it expensive for a campus to switch
  81. WAN providers without immediately changing the NSAP addresses of all its
  82. hosts.
  83.  
  84. The discussion returned to what seems to be the central issue:
  85. information explosion.  There are two approaches:
  86.  
  87.  
  88.    o minimize the size of the routing information that needs to be
  89.      conveyed
  90.    o devote more, faster hardware to exchanging routing information
  91.  
  92.  
  93. We need to find the proper balance between these two approaches.  Ross
  94. Callon suggested that most sites will be Internet leaf nodes, so we
  95. probably win the most by collapsing data near the leaves of the tree.
  96. However, for sites which are very small (and there will be a lot of
  97. them) not much collapsing will be possible at the the leaf boundary, so
  98. we'll need to have further collapsing farther up the tree to get
  99. effective size reduction of the routing data about small sites.
  100.  
  101. It was pointed out that the paper uses a stylized model of the Internet
  102. (backbones, regionals, and campuses), that ignores such real world
  103. realities as back doors, mid-level networks which are not regionals (eg,
  104. CSNET), etc.  It isn't immediately clear whether the stylized model
  105. leads us to the right conclusions.  Tony Hain will try to write up a
  106. more realistic model.
  107.  
  108. The issue of how mobile hosts fit into an essentially geographical
  109. addressing scheme was brought up and quickly dropped because nobody has
  110. a good answer.
  111.  
  112. The issue of whether we need a temporary interdomain routing protocol
  113. for the Internet was discussed and deferred to OSI Area Directors and
  114. the OSI General Working Group.  A draft version of BRP was suggested as
  115. a likely candidate.
  116.  
  117.                                    2
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124. Paul Tsuchiya presented his draft paper, ``Efficient Routing Hierarchies
  125. Using Multiple Addresses''.  This paper describes a hierarchical address
  126. allocation scheme which very strictly mirrors the hierarchical Internet
  127. topology.  Since a host's address largely determines the route used to
  128. get to it, hosts which are accessible via multiple regionals or
  129. backbones may be assigned multiple addresses, providing alternate path
  130. routing and a primitive form of policy-based routing.  The group seemed
  131. to find the approach interesting but did not reach a firm conclusion
  132. about its applicability.
  133.  
  134. It was agreed that once we start to understand how to do address
  135. assignment and run OSI in the Internet we need to somehow disseminate
  136. this knowledge to the managers of at least the mid-level networks.  One
  137. good way to accomplish this might be a tutorial and discussion session
  138. at a future IETF meeting.
  139.  
  140. ATTENDEES
  141.  
  142.     Philip Almquist           almquist@jessica.stanford.edu
  143.     Lan Bosack                bosack@mathom.cisco.com
  144.     Ross Callon               callon@erlang.dec.com
  145.     Allan Cargille            cargille@cs.wisc.edu
  146.     Martina Chan              mchan@mot.com
  147.     A. Lyman Chapin           Lyman@merit.edu
  148.     Richard Colella           colella@osi3.ncsl.nist.gov
  149.     Curtis Cox                zk0001@wnyosi4.navy.mil
  150.     Ella Gardner              epg@gateway.mitre.org
  151.     Martin Gross              martin@protolaba.dca.mil
  152.     Robert Hagens             hagens@cs.wisc.edu
  153.     Tony Hain                 hain@nmfecc.arpa
  154.     David Miller              dtm@mitre.org
  155.     Cyndi Mills               cmills@bbn.com
  156.     Mark Needleman            mhnur@vccmvsa.bitnet
  157.     John Vollbrecht           jv@merit.edu
  158.     Dan Wintringham           danw@igloo.osc.edu
  159.     Richard Woundy            rwoundy@ibm.com
  160.     Mary Youssef              mary@ibm.com
  161.  
  162.  
  163.  
  164.                                    3
  165.