home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rolc / rolc-minutes-95apr.txt < prev    next >
Text File  |  1995-05-26  |  6KB  |  183 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Howard Berkowitz/PSC International and
  5. Andrew Malis/Ascom Nexion
  6.  
  7. Minutes of the Routing Over Large Clouds Working Group (ROLC)
  8.  
  9. The ROLC working group met in two sessions.  The first session is
  10. reported on in these minutes.  The second session, which has a separate
  11. set of minutes (following these), was a joint meeting of the ROLC and
  12. IPATM Working Groups.
  13.  
  14. There were over 120 attendees at the first session.
  15.  
  16.  
  17. Agenda
  18.  
  19.    o Agenda bashing
  20.      No changes were made to the agenda.
  21.  
  22.    o ATM Forum MPOA Update
  23.      Presented by George Swallow, cisco Systems, Chair, ATM Forum
  24.      Multiprotocol Over ATM Working Group
  25.  
  26.    o NHRP implementation experience
  27.  
  28.    o NHRP open issues and draft-ietf-rolc-nhrp-IV.txt
  29.      Presented by Dave Katz, cisco Systems
  30.  
  31.    o NHRP Applicability Statement (draft-ietf-rolc-nhrp-appl-01.txt)
  32.      Presented by Derya Cansever, GTE Laboratories
  33.  
  34.    o NHRP MIB (draft-ietf-rolc-nhrp-mib-00.txt)
  35.      Presented by Mike Patrick, Motorola ISG
  36.  
  37.    o Status and Workplan
  38.  
  39.  
  40. ATM Forum Multiprotocol over ATM (MPOA) Update
  41.  
  42. The initial BOF was held last September, and the Forum began a working
  43. group in November before the last IETF. The scope and requirements are
  44. complete.
  45.  
  46. The plan is to support MPOA with an Overlay Model comparable to ROLC. It
  47. is intended to be compatible with integrated PNNI, and a future Peer
  48. Model is not precluded.  Any solution must interoperate with LAN
  49. emulation and non-ATM devices.
  50.  
  51. In the reference model, the MPOA service cloud interconnects with LAN
  52. emulation as a separate service over ATM. The exact nature of this
  53. interconnection has yet to be defined.
  54.  
  55. It is intended to be ``a good citizen of the Internet.''
  56.  
  57. MPOA and NHRP relationship:  An MPOA requirement is to build on NHRP.
  58. There is a strong feeling this should be more general with regard to the
  59. network layer, however, the group is concentrating on ATM, rather than
  60. supporting general link layers.
  61.  
  62.  
  63. NHRP Implementation Experience
  64.  
  65. No implementation experience was shared in the meeting.  The chair said
  66. there are at least two implementations in progress.  cisco Systems
  67. announced that they are one of the two, and plan to begin testing soon.
  68.  
  69.  
  70. NHRP Open Issues and Draft
  71.  
  72. The new draft was distributed on the list as
  73. draft-ietf-rolc-nhrp-IV.txt.  An official -04 version will be submitted
  74. as an Internet-Draft several weeks following the meeting, and including
  75. all comments and changes from the meeting.
  76.  
  77. Dave Katz gave an overview of the changes to the specification.  This is
  78. the same list of changes he included in the introduction to draft -IV
  79. itself.
  80.  
  81. Dave then led the discussion.
  82.  
  83.  
  84.    o The need was discussed for a separate document discussing the
  85.      router-to-router case, because of its complexity.  Dave will start
  86.      a new Internet-Draft on the topic.
  87.  
  88.    o NHRP servers along the path are now not allowed to cache NHRP
  89.      entries information unless the new bit is set indicating that the
  90.      information is stable.
  91.  
  92.    o If metrics are not preserved between routers (e.g., in OSPF-BGP
  93.      interactions), then there is the potential for looping.  Full
  94.      semantic preservation of metrics prevents the formation of such
  95.      loops.  NHRP is also loop free when used in one AS, or the new
  96.      stable bit is set in the NHRP reply, or if stub networks have no
  97.      back doors.
  98.  
  99.    o The goal that NHRP is usable in connectionless (SMDS) as well as
  100.      connection-oriented (ATM) environments.
  101.  
  102.    o The chair encouraged people to comment on the looping problem (or
  103.      anything else, for that matter).  Revision -04 may be subject to
  104.      the Last Call for Proposed Standard; comments are solicited
  105.      following its publication.
  106.  
  107.    o Curtis Villamizar wants the specification to state things more
  108.      clearly.  It is known that there are scenarios where routing loops
  109.      can exist, and they cannot all be solved.  This should be mentioned
  110.      in the applicability statement.
  111.  
  112.    o The question was asked if we are denigrating NHRP because some of
  113.      the actions routers take?  The purpose of this working group is
  114.      large clouds; the solution is not viable if it only works over
  115.      limited topology.  Dave Piscitello replied that if the limited
  116.      topology is widely used, then the solution is still useful.  NHRP
  117.      will also be applicable to cases where there is no exterior
  118.      protocol.
  119.  
  120.  
  121. NHRP Applicability Statement
  122.  
  123. Derya discussed the changes he has planned for the applicability
  124. statement, draft-ietf-rolc-nhrp-appl-01.txt:
  125.  
  126.  
  127.    o Clarify the router-to-router case
  128.    o Not a replacement for routing protocols
  129.    o Clarification of potential looping cases
  130.    o Needs to be harmonized with NHRP-IV draft
  131.  
  132.  
  133. The chair reminded the working group that the applicability statement
  134. and protocol analysis must be submitted in order to standardize , as
  135. well as the MIB and implementation experience when available.
  136.  
  137.  
  138. NHRP MIB
  139.  
  140. Mike led a discussion of some issues with the current draft of the MIB,
  141. draft-ietf-rolc-nhrp-mib-00.txt.
  142.  
  143.  
  144.    o The MIB has not yet been compiled.
  145.  
  146.    o The section on cut-through circuits will be moved to the
  147.      applicability statement.
  148.  
  149.    o Traps:  customers like them, but engineers do not.  The current
  150.      plan is to not use traps.
  151.  
  152.    o Unnumbered links over ATM: Consensus that these need to be
  153.      supported.  Every unnumbered link should have an ifIndex entry.
  154.      Consider OSPF methodology here.
  155.  
  156.    o RFC 1573 logical interface addresses---is this being done?  Mike
  157.      will query.
  158.  
  159.    o The MIB does not allow a LIS to be implemented on multiple NHRP
  160.      network IDs.  This was agreed to be acceptable assumption.
  161.  
  162.    o May need additional indexing for QoS, and different MAC addresses
  163.      for different QoS. MAC address plus QoS forms a tuple (cf.  SNA
  164.      Virtual Route).
  165.  
  166.  
  167. Status and Workplan
  168.  
  169. The chair asked to be told, in public or private, of implementations
  170. underway.  Kanan Shah will write the forthcoming protocol analysis
  171. document.
  172.  
  173.  
  174.      July 95:  Discuss implementation experience; submit NHRP document
  175.      to the IESG as a Proposed Standard; continue to review companion
  176.      documents.
  177.  
  178.      December 95:  Submit companion documents to IESG.
  179.  
  180.  
  181. The charter will be updated to reflect this new workplan.
  182.  
  183.