home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ospf / ospf-minutes-94jul.txt < prev    next >
Encoding:
Text File  |  1994-11-02  |  9.2 KB  |  224 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.  
  10.  
  11. ``Extending OSPF to Support Demand Circuits''
  12.  
  13.  
  14. The Internet-Draft, draft-ietf-ospf-demand-00.txt, was reviewed.  John
  15. Moy gave an overview of the features provided and the mechanisms
  16. employed.  The intent is to enhance OSPF so that it runs efficiently
  17. over dial-up networks.  The mechanisms get rid of all periodic OSPF
  18. protocol traffic (i.e., Hellos and flooding refreshes).  Comments on the
  19. draft included:
  20.  
  21.  
  22.    o John warned that the last paragraph in Section 2.3 of the
  23.      Internet-Draft is incorrect, and that implementors should skip this
  24.      for now.
  25.  
  26.    o People wanted to document the assumption that either side of the
  27.      circuit can dial.  Apparently this is not true for all modems.
  28.  
  29.    o There was a great deal of discussion about the support for
  30.      oversubscribed interfaces (e.g., a single basic rate ISDN channel
  31.      that supports more than two endpoints over time).  The draft
  32.      mentions increasing the cost of a connection that cannot be opened
  33.      due to being blocked (i.e., oversubscribed), in hope of getting the
  34.      established links to form a spanning tree.  Some people were
  35.      opposed to changing costs in this fashion.  Others were in favor.
  36.      The draft will be expanded to describe the functionality in more
  37.      detail.
  38.  
  39.    o Also on the subject of oversubscription, some network designs are
  40.      incapable of forming a spanning tree, thereby preventing
  41.      simultaneous access of all destinations.  The draft should explain
  42.      this.
  43.  
  44.    o It was proposed that, instead of LSAs that do not age, the endpoint
  45.      of a demand circuit should refresh LSAs (originating from the other
  46.      side of the circuit) by proxy.  It was John's contention that this
  47.      is actually more complicated.
  48.  
  49.    o Fred Baker offered to add an object to the OSPF MIB that indicates
  50.      whether a particular OSPF interface is a ``demand interface.''
  51.  
  52.  
  53.  
  54. Technical Changes to the Base OSPF Specification
  55.  
  56. The representation of point-to-point links will be enhanced to allow the
  57. point-to-point link to be advertised as a subnet (a la RIP). This change
  58. had been previously discussed on the OSPF mailing list.
  59.  
  60. The specification already requires a router to reject LSA updates that
  61. arrive more frequently than interval X (step 5a of Section 13).  This
  62. is to rate-limit neighbors that are not obeying the 5 second limit on
  63. LSA originations.  The current value of X is 5 seconds.  It is proposed
  64. to change X to 1 second.  This makes it less likely that a router will
  65. reject an update that it should not (because of differing clock speeds
  66. and granularities).
  67.  
  68. Also in flooding (Section 13, Step 8), if a router receives a less
  69. recent LSA, instead of the current behavior of silently ignoring the
  70. LSA, it will now flood back its database copy.  This helps in two cases
  71. involving MaxAge LSAs:  1) where they are stuck in a retransmission
  72. queue on a slow link and 2) where a router is not properly flushing them
  73. from its database.  In both of these cases, if the router responds back
  74. with the MaxAge LSA, the originator will then pick the next highest
  75. sequence number and the LSA will be overwritten.  (In addition, this
  76. change is needed for the demand circuit additions).
  77.  
  78. John also proposed to get rid of the PostScript in the next update of
  79. the OSPF specification, but this was soundly defeated.
  80.  
  81.  
  82.  
  83. A New Authentication Mechanism for OSPF Based on MD5
  84.  
  85. Fred Baker presented a new authentication mechanism for OSPF based on
  86. MD5.  This has since been published as an Internet-Draft,
  87. draft-ietf-ospf-md5-00.txt.  Comments on the proposal included:
  88.  
  89.  
  90.    o There was some confusion over the amount of padding required for
  91.      MD5 as specified in RFC 1321.
  92.  
  93.    o It was felt that specifying a non-decreasing sequence number was
  94.      good, both for replay detection and to avoid delaying for
  95.      RouterDeadInterval seconds upon restart.  It was suggested that a
  96.      router have some way to ensure a non-decreasing send sequence
  97.      number across restarts (e.g., a time of day clock).
  98.  
  99.    o Ran Atkinson said that secure SNMP is probably not the best way to
  100.      do key distribution.  He suggested that we simply specify manual
  101.      key distribution and leave key management to the Security Area
  102.      (contact person Steve Bellovin).
  103.  
  104.    o It was noted that since there is a secret per-LAN, you cannot
  105.      really verify who the sender is, just that it is one of your
  106.      trusted neighbors.
  107.  
  108.    o It was requested that, for efficiency reasons, the OSPF packet
  109.      checksum be avoided when MD5 authentication is being used.  The MD5
  110.      algorithm already performs a checksum of packet contents.
  111.  
  112.    o Dennis Ferguson was interested in having an inexpensive way to
  113.      indicate that two OSPF routers are in different Autonomous Systems,
  114.      and therefore should not communicate via OSPF. This is generally
  115.      done by giving them different secrets, but it was feared that the
  116.      additional overhead of MD5 might get onerous.  A suggestion was to
  117.      allocate space in the ``authentication'' part of the OSPF header
  118.      (not all of which is used when doing MD5) for this purpose.
  119.  
  120.  
  121.  
  122. ``Point-to-MultiPoint Interface''
  123.  
  124.  
  125. Fred then revisited his ``OSPF Point-to-MultiPoint Interface''
  126. Internet-Draft (draft-ietf-ospf-pmp-if-00.txt).  The purpose of this new
  127. interface type is to simplify configuration on non-mesh-connected Frame
  128. Relay networks.  The draft specifies use in a star topology, but will be
  129. updated to address a general topology of PVC connections.  Dennis
  130. suggested that the right way to look at the point-to-multipoint
  131. interface is as a way of profiling the representation of a Frame Relay
  132. network as multiple point-to-point connections that (1) are always
  133. numbered, (2) have an associated mask and (3) whose own addresses are
  134. advertised in LSAs (instead of the neighbors'), with a cost of 0.  John
  135. mentioned that the point-to-multipoint interface does not obsolete NBMAs
  136. -- NBMAs are still more efficient in full mesh connected networks (e.g.,
  137. X.25 or Frame Relay with SVCs).
  138.  
  139. The following comparison was made between the three ways of representing
  140. a Frame Relay network:  a) as one or more NBMAs, b) as multiple
  141. point-to-point networks and c) using the point-to-multipoint interface.
  142. This is from the point of view of a router connecting to a Frame Relay
  143. network through n PVCs.  The point-to-point networks can be either
  144. numbered or unnumbered.  The point-to-multipoint interface provides a
  145. ``non-standard'' subnet model since two routers on the same subnet do
  146. not have to be directly connected by a PVC.
  147.  
  148.  
  149.  
  150.      Feature                   1-n NBMAs    n P-Ps  P-MP
  151.     ______________________________________________________________
  152.  
  153.      router links (router LSA) 0            n       n
  154.      stub links                0            0-n     1
  155.      transit net links         1-n          0       0
  156.     ______________________________________________________________
  157.  
  158.      # OSPF ifcs               1-n          n       1
  159.      # ifc addresses           1-n          0-n     1
  160.      # OSPF adjacencies        1-n          n       n
  161.     ______________________________________________________________
  162.  
  163.      subnet model              1-n subnets  none    1 non-standard
  164.  
  165.  
  166.  
  167. Document Disposition
  168.  
  169. The OSPF Working Group has twelve documents currently in RFC or
  170. Internet-Draft form.  The group decided on the disposition of each.  In
  171. general, it was decided that rather than wait for implementation
  172. experience on several of the new proposals, they would be published as
  173. Experimental RFCs.
  174.  
  175.  
  176.    o RFC 1583:  OSPF specification - Will submit for Full Standard
  177.      status, after folding in the Point-to-point interface, MD5
  178.      authentication and some small technical changes (see above).
  179.      Responsible:  John Moy.
  180.  
  181.    o RFC 1245:  OSPF Analysis - Does not need to be updated.
  182.      Informational RFC.
  183.  
  184.    o RFC 1246:  OSPF Experience - Does not need to be updated.
  185.      Informational RFC.
  186.  
  187.    o RFC 1587:  OSPF NSSAs - Currently at Proposed Standard.  We desire
  188.      to advance, but need more experience.  Network Systems indicated
  189.      that they have an implementation.  We need another independent
  190.      implementation, and some deployments.  Right now the text does not
  191.      need to be updated.
  192.  
  193.    o RFC 1586:  Frame Relay Guidelines - Informational RFC. Desire
  194.      reissue since affected by the new Point-to-Multipoint interface.
  195.      Responsible:  need volunteer.
  196.  
  197.    o RFC 1253:  OSPF MIB - Want to advance to Draft Standard.  Being
  198.      updated by Fred Baker.
  199.  
  200.    o Point-to-multipoint Internet-Draft - Merge with base OSPF
  201.      specification.  Responsible:  John Moy.
  202.  
  203.    o External attributes LSA Internet-Draft - Update and publish as
  204.      Experimental RFC. Responsible:  Dennis Ferguson.
  205.  
  206.    o Demand circuit support Internet-Draft - Update and publish as
  207.      Experimental RFC. Responsible:  John Moy.
  208.  
  209.    o MD5 Authentication - Update and merge into base OSPF specification.
  210.      Responsible:  Fred Baker and John Moy.
  211.  
  212.    o OSPF Database Overflow - Still unwritten.  John Moy to write and
  213.      publish as Experimental RFC.
  214.  
  215.    o OSPF for IPng - See below.
  216.  
  217.  
  218. OSPF for IPng
  219.  
  220. Finally, the IPng Working Group requested that we update Paul Francis'
  221. OSPF for SIPP document, and turn it into an OSPF for IPng specification.
  222. Fred Baker and Dennis Ferguson volunteered to spearhead this effort.
  223.  
  224.