home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD1.mdf / INET / IETF / OSPF / 94DEC.MIN < prev    next >
Encoding:
Text File  |  1995-06-26  |  8.2 KB  |  199 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5. Reported by John Moy/Cascade Communications
  6.  
  7. Minutes of the Open Shortest Path First IGP Working Group (OSPF)
  8.  
  9. The OSPF Working Group met on Wednesday, December 7th at the San Jose
  10. IETF.
  11.  
  12.  
  13.  
  14. OSPF Extensions for IPv6
  15.  
  16.  
  17. Fred Baker led a discussion of the Internet-Draft ``OSPF Extensions for
  18. IPv6'' (draft-ietf-ospf-ipv6-ext-00.txt).  Fred characterized the
  19. support as follows:
  20.  
  21.  
  22.    o Integrated routing of IPv4 and IPv6.
  23.  
  24.    o Certain OSPF areas are labeled as ``IPv6-capable.''  All routers in
  25.      these areas must be capable of IPv6 routing, although not all
  26.      networks within need be assigned IPv6 addresses.  On those networks
  27.      with IPv6 addresses, OSPF will run over IPv6.  There is no gradual
  28.      conversion of an area to being ``IPv6-capable''; it must instead be
  29.      done on a flag day.
  30.  
  31.    o There are new LSA types which are the IPv6 equivalents of the
  32.      present OSPF LSAs.  The IPv6 LS type is obtained by adding 16 to
  33.      the IPv4 LSA type.  For example, the IPv6 router-LSA is LSA type 17
  34.      (16+1).
  35.  
  36.    o In the IPv6 LSAs (and in the IPv6-encapsulated OSPF packet format),
  37.      the Router ID, Link State ID, Advertising Router and Area ID have
  38.      been increased from 4 to 16 bytes.  The mask field remains at 4
  39.      bytes, but now indicates the number of significant bits.  Fred said
  40.      that the requirement for contiguous masks has now been blessed by
  41.      the IESG. Besides these changes, the only IPv6 LSA that is
  42.      significantly different from its IPv4 equivalent is the router-LSA.
  43.      In particular, since router-LSAs are now getting large, a way of
  44.      fragmenting IPv6 router-LSAs is defined.
  45.  
  46.    o For IPv6, there is a new Opaque-LSA type.  For example, if IPX
  47.      addresses are embedded in IPv6 the Opaque-LSA can be used to carry
  48.      SAP information.
  49.  
  50.  
  51. In the discussion that followed, a number of points were brought up:
  52.  
  53. There will not be an IPv6 equivalent of the type-8 (external-attributes)
  54. LSA. It will be subsumed by the opaque-LSA. In support of this, we must
  55. document that the Link State ID of the opaque-LSA (when carrying
  56. BGP/IDRP path info) must equal the tag in the IPv6 AS-external-LSAs.
  57. For this reason, maybe the tag field should be extended to 16 bytes?
  58.  
  59. Some people saw problems with requiring a flag day to convert areas to
  60. being IPv6-capable.  The DECNet Phase IV to Phase V migration was given
  61. as an example.  It was noted that there are mechanisms for piece-wise
  62. converting areas to new functionality (like is being done for the OSPF
  63. demand circuit support), but that they are somewhat complicated.
  64.  
  65. There was a good deal of discussion of Integrated routing.  Many people
  66. seemed to think that integrated routing is OK in this case, since IPv4
  67. and IPv6 are so similar.  It was noted that the problem with Integrated
  68. IS-IS was that the OSI and IP area boundaries typically did not match.
  69. Fred also said that integrated routing of IPv4 and IPv6 is being
  70. mandated by the IPng directorate.  Other people said that assuming IPv6
  71. and IPv4 would be so similar might be a mistake.  It was also noted that
  72. the SIN approach makes transition easier, again referencing Phase IV to
  73. Phase V conversion.
  74.  
  75. IPv6 addresses that cannot be translated to IPv4 addresses must be
  76. discarded at IPv4-only area boundaries.
  77.  
  78. IPv6-capable routers need both an IPv6 Router ID and an IPv4 Router ID.
  79. It was noted that these could both be provided by a single translatable
  80. IPv6 address belonging to one of the router's interfaces.
  81.  
  82.  
  83.  
  84. OSPF MD5 Authentication
  85.  
  86.    o Ran Atkinson described the current OSPF MD5 authentication
  87.      Internet-Draft (draft-ietf-ospf-md5-02.txt), and then led a lively
  88.      discussion of its contents.  The following issues were brought out:
  89.  
  90.    o Instead of ``lifetime,'' it would be clearer to talk about a key's
  91.      ``start time'' and ``end time.''  End time is necessary so that
  92.      keys can be taken out-of-service; otherwise, compromised keys will
  93.      continue to be accepted.
  94.  
  95.    o The document mandates multiple keys be supported so that a smooth
  96.      changeover from one key to another can be accomplished.
  97.  
  98.    o The document needs to be clearer about the use of new keys.  There
  99.      are two times that are important here:  a) When a new key will be
  100.      accepted in received packets and b) when the new key will be used
  101.      for transmitted packets.  There must be some overlap for smooth
  102.      transition.  It was noted that the RouterDeadInterval gives a grace
  103.      period; some people did not want to have to depend upon this
  104.      however.  Also, perhaps the new key's start time should be related
  105.      to the old key's end time.
  106.  
  107.    o There were questions on whether routers now need a time-of-day
  108.      clock, or whether relative time suffices.  If time-of-day clock is
  109.      necessary, there was a question on how synchronized routers' clocks
  110.      must be.
  111.  
  112.    o There was a question of how routers should operate on restart.
  113.      Should they have to get keys anew, or should the keys persist
  114.      across restarts?
  115.  
  116.  
  117.  
  118. Changes to the OSPF MIB
  119.  
  120.  
  121. Fred Baker described the changes that have occurred to the OSPF MIB
  122. since RFC 1253.  More additions have to be made for the Demand Circuit
  123. and Database Overflow support.  Also, the MIB does not reflect IPv6 in
  124. any way.  Since we want to republish the MIB soon, any changes should be
  125. sent to Fred as soon as possible.
  126.  
  127.  
  128.  
  129. Extending OSPF to Support Demand Circuits
  130.  
  131.  
  132. John Moy summarized the current ``Extending OSPF to support demand
  133. circuits'' Internet-Draft (draft-ietf-ospf-demand-01.txt), and explained
  134. the changes made to the previous draft.  The following issues we brought
  135. up during the discussion:
  136.  
  137.  
  138.    o Some people wanted a more explicit description of how call
  139.      collisions are handled/avoided.  More words on how to randomize
  140.      timers is needed.
  141.  
  142.    o In order to deal with call collisions, and also to avoid
  143.      unnecessary calling charges, perhaps an exponential backoff
  144.      procedure for failed call attempts is a good idea.
  145.  
  146.    o Other people expressed concern that OSPF should not specify
  147.      handling of things (like call collision) that are better off solved
  148.      in a generic way by the data-link layer.
  149.  
  150.    o The requirements of both ends of a circuit be capable of dialing
  151.      was a problem for some people.  John noted that the real
  152.      requirement was only that the connection initiator be able to dial.
  153.  
  154.    o Charles Slater requested that routing changes not be sent over a
  155.      link until the link was established for data traffic.  John said
  156.      that that was difficult to do in some situations, and impossible in
  157.      others, while still having the routing work completely.  Charles
  158.      indicated that he was willing to live with some level of routing
  159.      failures in order to optimize dial-up charges.  John indicated that
  160.      the current way of isolating routing changes, namely configuring
  161.      area boundaries, should be better described in the specification.
  162.      Area boundaries function like routing filters, which is what some
  163.      dial-up routers do today.
  164.  
  165.    o It was mentioned that it is sometimes impossible to determine
  166.      whether a busy signal truly means busy.  It may mean instead that
  167.      part of the network is broken.
  168.  
  169.    o It was noted that often to get the most effective use of dial-up
  170.      lines, you need application-dependent routing, which is not
  171.      supported by the draft.
  172.  
  173.  
  174. Dawn Li then presented testing results of 3Com's implementation of the
  175. demand circuit support.  3Com and ACC have both implemented the previous
  176. draft of the demand circuit support.
  177.  
  178. Gerry Meyer then contrasted RIP support for demand circuits with OSPF's.
  179. RIP specifies how to handle oversubscription, while OSPF only provides a
  180. suggestion.  John said that the suggestion could be upgraded to a
  181. required behavior, if experience/simulation shows that it is a good way
  182. to handle oversubscription.  Gerry recommended that this be done as soon
  183. as possible.  RIP also does not route through 3rd parties, always
  184. establishing demand circuits directly to the destination.
  185.  
  186.  
  187. OSPF Database Overflow
  188.  
  189. John Moy then quickly summarized the ``OSPF Database Overflow''
  190. Internet-Draft (draft-ietf-ospf-overflow-00.txt), which is the result of
  191. previous working group discussions.
  192.  
  193.  
  194. Extending OSPF to Better Support RSVP
  195.  
  196. The meeting ended with Tom Pusateri asking for help in extending OSPF to
  197. better support RSVP. Interested parties should contact Tom.
  198.  
  199.