home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 93nov / area.routing.93nov.txt < prev    next >
Text File  |  1994-02-17  |  10KB  |  254 lines
  1.  
  2. Routing Area
  3.  
  4. Director:
  5.  
  6.  
  7.    o Bob Hinden:  hinden@eng.sun.com
  8.  
  9.  
  10. Area Summary reported by Bob Hinden/Sun Microsystems
  11.  
  12.  
  13. New Internet Routing and Addressing Architecture BOF (NIMROD)
  14.  
  15. The group reviewed the current draft working group charter and the
  16. latest proposed terminology list.  General satisfaction was expressed
  17. with the current state of both.
  18.  
  19. Discussion then moved on to some of the open architectural issues.
  20. Among the points discussed were:
  21.  
  22.  
  23.    o Can areas overlap?
  24.  
  25.    o Are abstraction levels identified explicitly?
  26.  
  27.    o Do the nodes in the graph of the network represent interfaces or
  28.      routers/networks?
  29.  
  30.    o Do interfaces have locators?
  31.  
  32.    o Are the labels which elements of locators globally unique?
  33.  
  34.    o Do locators grow up, down, and can they be expanded in the middle?
  35.  
  36.    o Are partial locators possible?
  37.  
  38.    o Do routers have locators?
  39.  
  40.    o Do we have separate namespaces for interfaces and endpoints?
  41.  
  42.    o What is the smallest thing which can be an endpoint?
  43.  
  44.    o Do we have a hop-by-hop mode, or just source routed packets and
  45.      flows?
  46.  
  47.    o Do we retain the EGP/IGP split?
  48.  
  49.    o When do we tackle multicast?
  50.  
  51.  
  52. The following action items were decided on:
  53.  
  54.  
  55.    o The meetings at the next IETF should be scheduled for Tuesday and
  56.      Wednesday mornings if possible.
  57.  
  58.    o All new open issues raised during the working group meeting are to
  59.      be sent to the working group mailing list.
  60.  
  61.    o The chair will include the new points, re-sort the list into
  62.      priority order, add a new category of ``local'' for issues, and
  63.      resubmit.
  64.  
  65.    o A document showing the outcome of the discussions on the open items
  66.      will be prepared and sent to the list.
  67.  
  68.    o A moderated list discussion will take on remaining open issues.
  69.  
  70.    o Scheduling a Boston interim meeting will be investigated.
  71.  
  72.    o The working group agreed to have a draft of the architecture RFC,
  73.      prepared by the end of January 1994, for final examination at the
  74.      March IETF.
  75.  
  76.  
  77.  
  78. Border Gateway Protocol Working Group (BGP) and OSI IDRP for IP Over IP
  79. Working Group (IPIDRP)
  80.  
  81. The BGP and IPIDRP Working Groups met jointly.  All outstanding
  82. technical issues with the BGP-4 protocol were resolved.  The resulting
  83. changes will be incorporated in the appropriate documents, and the
  84. documents will be submitted as Internet-Drafts before Thanksgiving with
  85. the purpose of advancing BGP-4 to a Proposed Standard.  The group also
  86. discussed IDRP status and several future enhancements to BGP/IDRP,
  87. including domain partition repair and router servers.
  88.  
  89.  
  90.  
  91. Inter-Domain Multicast Routing Working Group (IDMR)
  92.  
  93. The two PIM documents (PIM = Protocol Independent Multicast, formerly
  94. ESL), dense and sparse modes, were presented and discussed.  Though some
  95. details about the phase shift between sparse and dense mode need to be
  96. worked out, the general consensus of the group is that the multiple
  97. scaling modes approach is desirable.  Implementation of PIM will
  98. continue.
  99.  
  100. No work was done on CBT, but a status report was given describing CBT's
  101. state of implementation (almost done).  There is still interest in CBT
  102. as valuable work, either as a potential alternative to PIM (if PIM
  103. proves overly difficult), or as an Experimental Protocol.
  104.  
  105. The group decided to propose a new name and charter to better reflect
  106. that the focus is no longer strictly inter-domain, but rather scaling
  107. versus quality in general.  Paul Francis will generate the proposal.
  108.  
  109.  
  110.  
  111. Inter-Domain Policy Routing Working Group (IDPR)
  112.  
  113. The IDPR working group met for one session during this IETF. It spent
  114. the majority of the time discussing what is being called IDPR version 2.
  115. Version 2 contains support for multicast and multipath routing as well
  116. as policy-based resource allocation.  The gated implementation of
  117. version 2 will begin its testing phase next month.  In the early spring,
  118. an Internet-Draft will be produced describing the changes to the IDPR
  119. version 1 protocols to support this functionality.
  120.  
  121. The group also received a presentation (via videotape) on the "Routing
  122. by Preference" work of Yuko Murayama and colleagues, and we plan to
  123. discuss this more on the mailing list.
  124.  
  125. At the request of the Routing Area Director, the IDPR working group will
  126. conclude with this IETF. The group will restart when either an
  127. additional independent implementation of IDPR version 1 can be submitted
  128. for Draft Standard or when the Internet Draft specification of version 2
  129. is complete.  In the meantime, the mailing list will remain open.
  130.  
  131. Also, there are two new Internet-Drafts, both updated versions of
  132. existing documents.  One is the MIB and one is the DNS modifications for
  133. IDPR. We plan to submit the MIB for consideratin as a Proposed Standard.
  134.  
  135.  
  136.  
  137. IP Routing for Wireless/Mobile Hosts (MOBILEIP)
  138.  
  139. The MOBILEIP Working Group held an interim meeting on the 9th and 10th
  140. of September in Summit, New Jersey.  The two day meeting was quite
  141. productive.  We agreed on a basic model for how mobile-ip works.  We
  142. then discussed the various messages and information that would need to
  143. be passed between the various entities.  We selected an editor for the
  144. working group document---Charles Kunzinger from IBM. (Charlie was
  145. previously editor of the ISO IDRP effort.)
  146.  
  147. The MOBILEIP Working Group met twice at the 28th IETF. Charlie Kunzinger
  148. gave a tutorial introduction to the first draft document he has
  149. produced.  The group then reviewed this draft and also reviewed the work
  150. of three other members of the working group (who have formed an
  151. alliance; before they had between them four or five documents, and now
  152. only one).
  153.  
  154. The group plans to have a firmer draft by the end of the year.  There
  155. are plans for another interim meeting in January.  We hope to have a
  156. draft specification by the Seattle IETF (and maybe even an
  157. implementation or two).
  158.  
  159.  
  160.  
  161. IS-IS for IP Internets Working Group (ISIS)
  162.  
  163. The ISIS Working Group meet for one session.  The major topic discussed
  164. was multicast support in ISIS. Three types of multicast were identified:
  165. ``anycast'' for the nearest service location, dense multicast, and
  166. sparse multicast.  The first two could be supported by ISIS while sparse
  167. multicast is best done by some multicast tree approach.  This work needs
  168. to be brought to the attention of the IDMR Working Group.
  169.  
  170. The working group also discussed the IPX and Appletalk integration
  171. scheme (available as an Internet-Draft) and Novell's NLSP protocol which
  172. was derived from ISIS. The group drew up a list of work items, some of
  173. which would require enhancing the protocol as defined in the latest ISIS
  174. Internet-Draft.  Incorporating these changes would probably require
  175. defining a new version of the ISIS protocol.
  176.  
  177.  
  178.  
  179. Open Shortest Path First IGP Working Group (OSPF)
  180.  
  181. The OSPF Working Group met on Wednesday, November 3.  The following
  182. items were discussed:
  183.  
  184.  
  185.    o Status Overview
  186.    o OSPF Scaling Issues - "Ringing It Out At The Next Level"
  187.    o On-Demand Circuit Proposal
  188.    o NSSA Implementation And Status
  189.    o MIB Changes And Status
  190.  
  191.  
  192.  
  193. RIP Version II Working Group (RIPV2)
  194.  
  195. The RIP-2 Protocol Internet-Draft was approved by the working group for
  196. submission for consideration as a Draft Standard to replace RFC 1388.
  197. The MIB was similarly approved to replace RFC 1389.
  198.  
  199. There are two new implementations of RIP-2, bringing the total to four.
  200. Details on the implementations will be provided in a revision of the
  201. RIP-2 Protocol Analysis which will be done this month.
  202.  
  203. The Demand Circuit Routing Internet-Draft by Gerry Meyer was approved
  204. for submission for consideration as a Proposed Standard.  The Protocol
  205. Analysis Internet-Draft will be submitted as an Informational RFC.
  206.  
  207. Consideration of the SIPP-RIP draft, particularly the Loop Detection
  208. algorithm, was postponed until RIP-2 has been accepted as a Draft
  209. Standard (so as not to affect that effort).  Discussion of the algorithm
  210. will be started next month on the ietf-rip mailing list and will be
  211. discussed in detail in Seattle.
  212.  
  213.  
  214.  
  215. Routing over Large Clouds Working Group (ROLC)
  216.  
  217. The ROLC Working Group met for two sessions.  The first session had a
  218. brief review of the charter, and a discussion of the assumptions about
  219. media and network topology.  The group briefly discussed the IS-IS over
  220. NBMA and RIP over demand circuit documents.  There were some issues
  221. raised, which will be carried back to the relevant working groups.
  222.  
  223. The second session was devoted to a discussion of two documents.  The
  224. discussion of the Braden/Postel/Rekhter architectural document raised a
  225. number of issues.  There was definite support from this working group
  226. for the general purpose and approach.  The group consensus was that
  227. certain solutions less favored in the document (query/response
  228. mechanisms) were important tools.
  229.  
  230. The group then reviewed the details of the NHRP proposal.  It discussed
  231. the behavior in the normal case, and the responsiveness to changes in
  232. underlying routing.  One major flaw which could produce loops was
  233. pointed out.  An approach to the solution was also suggested.  It will
  234. be necessary for the group to work more on this issue.  There was also
  235. the suggestion that we adopt a solution which only works in the absence
  236. of address aggregation within the large cloud.  The solution and its
  237. applicability will be discussed on the e-mail list, while discussion of
  238. the more general case continues.
  239.  
  240.  
  241.  
  242. Source Demand Routing Working Group (SDR)
  243.  
  244. The working group performed a protocol walk-through of the SDR document,
  245. and found that only editorial changes were needed.  The working group
  246. will be reviewing these changes shortly, and submitting the
  247. specification for approval as an Experimental RFC.
  248.  
  249. The working group held brief discussions about route selection and
  250. efficient mapping of packets to SDRP routes.  Progress on other working
  251. group issues was somewhat lacking.  Due to personal emergencies, several
  252. key members of the working group were not able to attend.
  253.  
  254.