home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / idr / idr-minutes-94dec.txt < prev    next >
Text File  |  1995-02-28  |  6KB  |  172 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Dave O'Leary/cisco Systems
  5.  
  6. Minutes of the Inter-Domain Routing Working Group (IDR)
  7.  
  8. The IDR Working Group held two sessions on Thursday, 8 December.
  9.  
  10.  
  11. Agenda Bashing
  12.  
  13.    o Guidelines for the use of autonomous system numbers
  14.    o CIDR to a Draft Standard
  15.    o BGP-4 to a Draft Standard
  16.    o IDRP for IPv6
  17.  
  18.  
  19. In addition to the above items the following topics were added:
  20.  
  21.  
  22.    o AS# -- RD mapping
  23.    o BGP-4 --> IDRP interaction
  24.    o OSPF --> IDRP interaction
  25.  
  26.  
  27. Guidelines For the Use of AS Numbers - Tony Bates
  28.  
  29. References are slides and the Internet-Draft, ``Guidelines for creation,
  30. selection, and registration of an Autonomous System (AS)''
  31. (draft-ietf-idr-autosys-guide-00.txt).  The draft is intended as an
  32. advisory document only, to clear up confusion rather than state policy.
  33.  
  34. The document addresses those singly-homed sites whose policy is the same
  35. as their provider, intent is to reduce AS number utilization and AS path
  36. lengths.  Currently there is no choice other than BGP (requiring a legal
  37. AS number) or a classless IGP between providers and customers (which is
  38. considered non-optimal by many).  Classless static also solves this and
  39. is used in many cases but does not help in cases of transition from one
  40. provider to another or for those who anticipate future multiple homing.
  41.  
  42. This document will probably need to be updated sometime to reflect the
  43. existence of BGP communities.
  44.  
  45. Jessica Yu will write some text on how the existence of someone else's
  46. policy should not necessarily affect the requirement for using an AS,
  47. and why this is a fuzzy area driven by the choice of the originating AS
  48. and how their policy is defined.
  49.  
  50. Concern was expressed relative to this document and its lack of text on
  51. where AS numbers should be used, so that less knowledgeable service
  52. providers do not read this draft the wrong way and try to stop using AS
  53. numbers in their networks.  Peter Lothberg will write some text.
  54.  
  55. The goal is to have a new version of this document by 14 January 1995.
  56. The consensus of the working group was to advance it as a Proposed
  57. Standard.
  58.  
  59.  
  60.  
  61. CIDR to Draft Standard - Peter Ford
  62.  
  63. There was clear consensus of the working group that the CIDR
  64. architecture should move forward as a Draft Standard.  The working group
  65. agreed to ask the IESG on 15 January 1995 to advance RFC 1518 and
  66. RFC 1519 to a Draft Standard.  Any comments on these documents should be
  67. posted to the mailing list as soon as possible (prior to 15 January).
  68.  
  69. Peter Ford has a rough draft of the CIDR experience document.  He is
  70. looking for writers and reviewers for this document.
  71.  
  72.  
  73.  
  74. BGP-4 to Draft Standard - Paul Traina
  75.  
  76. Known implementations are:  cisco, Wellfleet/Bay Networks, gated, 3Com,
  77. Rob Coltun's, and European Telebit.
  78.  
  79. There was clear consensus of the working group that BGP-4 should move
  80. forward as a Draft Standard.
  81.  
  82. Recent changes in the BGP documents were cleanup of the text relative to
  83. the use of the terms ``network,'' ``prefix,'' etc.
  84.  
  85. There was discussion on the use of ``open'' message for use by route
  86. reflectors/servers.  The change will be editorial; relabel the
  87. authentication field as the ``open parameters'' field since it is an
  88. extensible field that can still be used for authentication.  Its use
  89. will be detecting misconfiguration at other layers in the hierarchy.
  90.  
  91. The editors agreed to prepare revised text of BGP-4 (both the protocol
  92. specifications and the usage document) within two weeks.
  93.  
  94. The working group agreed to ask the IESG on 15 January 1995 to advance
  95. BGP-4 to a Draft Standard.  Any comments on the revised text of BGP-4
  96. (protocol specifications or usage document) should be posted to the
  97. mailing list as soon as possible (prior to 15 January).
  98.  
  99.  
  100.  
  101. Use of Colors
  102.  
  103. Paul Traina proposed to add a new optional transitive attribute to BGP-4
  104. -- ``route color.''
  105.  
  106. The attribute is defined as a list of long words (four octets) to use
  107. for policy control in addition to AS path.
  108.  
  109. Possible examples of application:
  110.  
  111.  
  112.    o do not leave this router
  113.    o do not leave this AS
  114.    o others locally significant between peers
  115.  
  116.  
  117. Sean Doran and Paul Traina will work on a usage document addressing how
  118. this will affect aggregation, local color versus global color, scope
  119. limitation versus AS path length (some concern/offense was expressed
  120. regarding the use of this mechanism).
  121.  
  122.  
  123.  
  124. IDRP Transport Over IPv6 - Paul Traina
  125.  
  126. Paul Traina presented a brief overview of the Internet-Draft,
  127. draft-ietf-idr-idrp-v6-00.txt.
  128.  
  129. A recent change (clarification) is that one message contains multiple
  130. attributes, and changes for consistency with BGP.
  131.  
  132. There was discussion of possible changes to IDRP - sending fewer bits
  133. versus complexity of implementation.  Yakov will remove text re:
  134. routeID (explicit withdrawals) and replace it with advertising just
  135. unreachable address prefixes.
  136.  
  137. The group discussed the use of Multi-Exit Discriminator (MED) --
  138. flexibility on a per RD peer basis which is not currently accommodated.
  139. This will remain unspecified at this point.
  140.  
  141. A revised version of the Internet-Draft is expected before the next
  142. IETF.
  143.  
  144. The Route Server implementation by IBM and ISI (as part of the Routing
  145. Arbiter project) will support IDRP for IPv6.
  146.  
  147.  
  148.  
  149. AS Number to RDCI/RDI Mapping
  150.  
  151. Since BGP-4 operates in terms of AS numbers, and IDRP operates in terms
  152. Routing Domain Identifiers (RDI) or Routing Domain Confederation
  153. Identifiers (RDCI), there is a need to define how AS numbers could be
  154. mapped into RDI or RDCI.
  155.  
  156. IPv4 mapping is dropped into mapping for IPv6.
  157.  
  158.  
  159.  
  160. Connection of IPv4 and IPv6 Domains
  161.  
  162. For transition to IPv6 it will be important to leak IPv4 routing
  163. information into IPv6 routing system.  Dimitry Haskin agreed to write a
  164. document that specifies how this leakage should be done.
  165.  
  166.  
  167. OSPF --> IDRP for IPv6 Interaction
  168.  
  169. Yakov Rekhter agreed to make the necessary editorial changes to the
  170. OSPF/IDRP for IPv4 interaction document to deal with IDRP for IPv6.
  171.  
  172.