home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 92mar / bgpcidr-minutes-92mar.txt < prev    next >
Text File  |  1993-02-17  |  5KB  |  123 lines
  1. This is an unedited version - Megan 04/20/92
  2.  
  3. BGP/CIDR BOF
  4. Wednesday, 18 March, 1992, 1:30-3:30pm.
  5. San Diego IETF
  6. Chaired by Yakov Rekhter (IBM Watson) and Peer Ford (LANL)
  7.  
  8. The BGP working group met jointly with people interested in 
  9. Classless InterDomain  Routing (CIDR) in a BOF to discuss the  
  10. development of an addressing plan which can be used for IP.
  11. CIDR  would allow collapsing adjacent network addresses into a single prefix, 
  12. and that prefix would be passed within the routing system   as the 
  13. route to all the "collapsed" networks.  CIDR is proposed to mitigate
  14. the scaling problems in the Internet's routing system which are due to 
  15. ``flat routing'' and the fact that the Internet will shortly  (1-3 years) 
  16. run out of class B addresses.  When the Internet runs out of class B addresses,
  17. the current available option is to allocate class C network addresses which 
  18. will require networks which have more than 255 end systems to  advertise 
  19. multiple network addresses to the global Internet routing system.
  20. The purpose of the BOF was to discuss various schemes for assigning and 
  21. collapsing addresses, including collapsing along a multi-level
  22. hierarchy, what the hierarchies would look like (size and placement),
  23. what the mapping between network providers and collapsed prefixes would
  24. look like.  There was a significant turnout of interested people and
  25. the discussion was quite spirited.
  26.  
  27. Yakov Rekhter led off the discussion with a brief overview of CIDR and 
  28. an explanation of the goals of the BOF.  He then presented a proposal for 
  29. Address Assignment Authorities (AAAs).  Following are notes from his 
  30. slides:
  31.  
  32. {beginning of slides}
  33. Goal: "Recommended Guidelines for IP Address Assignment."
  34.     To achieve:
  35.         consistency
  36.         efficiency 
  37.         ease of management and coordination
  38.  
  39. "Address Assignment Authority" (AAA)
  40.  
  41.     Distributed way of managing address space
  42.     Promote routing information efficiency 
  43.     Recursive ==> delegation of AAA
  44.  
  45.  
  46. Need to extend CIDR
  47.  
  48.     Pure class "C" supernetting provides _limited_ extension with
  49.         respect to the IP address space
  50.  
  51.     Large portions of A & B are still unused!
  52.  
  53.     "AAA"  concept needs to be applied to the _whole_ IP address space.
  54.  
  55. How  to carve address space?
  56.  
  57.     Top-Down to ensure feasible routing (wrt scaling)
  58.     How many levels
  59.     Branching Factor at each level
  60.         (deep trees vrs bushy trees)
  61.     Need to determine number of top level AAAs.
  62.  
  63. CIDR & "NSAP Address Guidelines"
  64.  
  65.     Attempt to solve the same problem
  66.     May benefit from coordination between NSAP address assignment and
  67.         IP address assignment
  68.     
  69.     Single AAA --> IP & NSAP
  70.  
  71.     IP and NSAP topology is likely to be congruent
  72.     Address administration boundaries are likely to be congruent:
  73.         a service provider provides both IP and CLNP services
  74.         the same geographical area provides both IP and CLNP services
  75.  
  76. {end of Slides}
  77.  
  78.  
  79. Yakov went on to propose a possible allocation of AAA's, which was to 
  80. assume a top down allocation of 1000 AAAs which would require 
  81. coding top level AAA coding  of 10 bits.  Within the  class c 
  82. address space this would imply that each AAA would have a 
  83. maximum of 1000 class C network addrs.
  84. This  was a good starting point for discussing network topology 
  85. issues, and "who would be candidates for being AAAs?".
  86.  
  87. There were several people disagreeing with Yakov's proposal for picking 
  88. a fixed size breakout for top level AAAs.  Several people 
  89. proposed  an allocation of top level AAAs which was scaled by the 
  90. size of the community one was trying to serve, perhaps 
  91. using the population size or the size of the telephone networks as
  92. scaling factors.  It was noted that using a Kampei style address
  93. assignment scheme might be a good thing to do here.
  94.  
  95. There was concern expressed for deploying CIDR too soon, before 
  96. a sufficient technology base was deployed for aggregating multiple 
  97. class C network addresses.    Several people noted that 
  98. this may have severe impacts on intra-domain routing protocols since
  99. an aggregated prefix would have to be exploded to its constituent 
  100. class C networks if the routing protocols did not handle 
  101. aggregation correctly (RIP and EGP).
  102.  
  103. There was significant discussion of how to carve up class A and class B
  104. network addresses effectively.  There was general concurrence that
  105. for the time being class A's should not be allocated.  This would be until 
  106. there is a technology base which can be used with carved up A's.  It was 
  107. noted that this would be feasible once  most routers "knew  how to 
  108. do variable length subnets".
  109.  
  110. There was discussion on how Class C# (Solensky and Kastenholz) could 
  111. coexist with CIDR.
  112.  
  113. Jon Postel gave a short description of what the IANA does and how it 
  114. decides who gets what network addresses.
  115.  
  116. The discussion clearly overran the time allotment and future 
  117. discussion of this issue was proposed to continue on Email 
  118. using the big-internet@munnari.oz.au mailing list.  Yakov Rekhter
  119. agreed to discuss with the IESG about forming a working group to 
  120. work on an IP addressing plan.
  121.  
  122.  
  123.