home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 93mar / area.routing.93mar.txt < prev    next >
Encoding:
Text File  |  1993-05-14  |  8.7 KB  |  247 lines
  1.  
  2. Routing Area
  3.  
  4. Director(s):
  5.  
  6.  
  7.    o Bob Hinden:  hinden@eng.sun.com
  8.  
  9.  
  10. Area Summary reported by Bob Hinden/Sun
  11.  
  12. Inter-Domain Multicast Routing BOF (IDMR)
  13.  
  14. The entire IDMR session was spent in a discussion of the CBT protocol.
  15. Particular attention was given to the changes in the Protocol since the
  16. November IETF.
  17.  
  18.  
  19.    o MulticastOScopenControle possible solution to multicast scope control was *
  20.  *presented,
  21.      based on having a separate group per level of scope required.  This
  22.      resulted in a considerable debate as to how multicast scoping
  23.      should be defined and the requirements of users it should be able
  24.      to satisfy.  The solution presented was deemed unsuitable, and it
  25.      was agreed to continue the discussion on the IDMR mailing list.
  26.      The conclusion was that the Group should work towards a concise
  27.      definition of multicast scope control.
  28.  
  29.    o MulticastTDatahPacketsere was a brief discussion on the issue of multicast*
  30.  * data packets
  31.      carrying the group-id as an IP option.  The conclusion however, was
  32.      that there was no more suitable alternative.  It was also decided
  33.      that non-primary cores should be less stringent in accepting
  34.      join-requests.  Further, an additional error detection mechanism is
  35.      required by routers to distinguish on-tree packets arriving via a
  36.      child as link-level unicast.
  37.  
  38.  
  39. Paul Tsuchiya concluded the session with a description of how CBT will
  40. run over Pip.
  41.  
  42. Virtual Circuit Routing BOF (VCROUT)
  43.  
  44. The VCROUT BOF meet on Monday and Wednesday.  On Monday, Rob Coltun led
  45. a discussion on routing criteria for a seamless VC internet.  Much of
  46. the discussion centered on address as well as terminology.  Drew Perkins
  47. presented Fore Systems' routing strategy.
  48.  
  49. On Wednesday, Marco Sosa led a discussion on the scope of the Working
  50. Group's direction and goals.  The Group agreed that they would include
  51. both intra-domain and inter-domain routing within their scope, but
  52. initially focus on intra-domain routing.  The protocol for topology
  53. notifications and methods for aggregating topology information to
  54. provide possible routes to a call set-up will be addressed.  Rob then
  55.  
  56.                                    1
  57.  
  58.  
  59.  
  60.  
  61.  
  62. provided an overview of the proposal drafted by Marco and himself.
  63.  
  64. Allison Mankin gave a presentation on congestion control implementation,
  65. signaling, and its relationship to QOS and routing.  Finally, some
  66. modification to the draft proposal were suggested and discussed.
  67.  
  68. The Group plans to meet in Amsterdam as a working group.
  69.  
  70. Border Gateway Protocol Working Group (BGP)
  71.  
  72. The BGP Working Group met jointly with the IPIDRP Working Group.  Refer
  73. to the IPIDRP section of this report for a summary of their meeting.
  74.  
  75. Inter-Domain Policy Routing Working Group (IDPR)
  76.  
  77. There are two new Internet-Drafts, one by Rob Austein on DNS extensions
  78. for IDPR and one by Woody Woodburn which is the latest version of the
  79. IDPR MIB. The Group encourages people to read these Drafts and send
  80. comments to the IDPR mailing list.
  81.  
  82. The Internet pilot demonstration of IDPR is scheduled to begin next week
  83. and will run for approximately one month.  The results of the pilot, as
  84. well as a description of the installation, will be published in an
  85. Informational RFC at the conclusion of that period.
  86.  
  87. Discussion topics included the implications of domain hierarchies
  88. (``superdomains'' in the architecture document terminology) and resource
  89. allocation in the context of IDPR.
  90.  
  91. Super domain discussion included domain address representation; policies
  92. of super domains; and obtaining more detailed information about the
  93. contents of a super domain through mechanisms such as active
  94. distribution by constituent domains and queries from external domains.
  95.  
  96. Resource allocation discussion included a description of the ``fair
  97. share'' resource allocation mechanism as well as a general discussion of
  98. how to integrate resource allocation and policy routing.  Topics
  99. included route generation heuristics to improve the probability of
  100. generating routes that supply the necessary resources, as well as
  101. passing flow control information back to the beginning of a path.
  102.  
  103. IP Routing for Wireless/Mobile Hosts Working Group (MOBILEIP)
  104.  
  105. The MOBILEIP Working Group met twice during the Columbus IETF. There
  106. were six formal presentations on different approaches to mobile IP
  107. followed by a discussion of how to actually make progress.
  108.  
  109. After listening to 6 talks on the status of old proposals and on new
  110. proposals, the Working Group decomposed the problem into 5 pieces (with
  111. an additional 5 ``cross matrix'' pieces).  Each of the pieces was
  112. assigned to a Working Group member for them to edit a document
  113. documenting a solution to that part of the puzzle.
  114.  
  115.                                    2
  116.  
  117.  
  118.  
  119.  
  120.  
  121. ISIS for IP Internets Working Group (ISIS)
  122.  
  123. The ISIS Working Group met for one session.  The Group agreed to try and
  124. advance the Proposed Standard (RFC1195) and the MIB up the standard
  125. track to Draft and Proposed status respectively at the next IETF
  126. meeting.
  127.  
  128. The Group also discussed a number of new enhancements and extensions to
  129. the protocol.  These include:
  130.  
  131.  
  132.    o Support for CLNP Multicast (maybe define something new - not what
  133.      ANSI/ISO are defining).
  134.  
  135.    o Adding a designated router ``feature'' to the Protocol
  136.      specification.
  137.  
  138.    o Defining how to support multiple level 1 Areas in one router.
  139.  
  140.    o Defining multiple levels of hierarchy.
  141.  
  142.    o Adding Appletalk and IPX integration into the Protocol.
  143.  
  144.    o Increasing the LSP number limit to 64K bytes.
  145.  
  146.    o Increasing the metric range to 16 bit internal and 32 bit external.
  147.  
  148.    o Methods to run over non-broadcast multi-access networks (e.g.
  149.      SMDS, ATM, X.25, etc.).
  150.  
  151.  
  152. Multicast Extensions to OSPF Working Group (MOSPF)
  153.  
  154. The MOSPF Working Group met for one session.  John Moy discussed the
  155. MOSPF Analysis and Experience Draft that he prepared to accompany the
  156. MOSPF Protocol Specification, as required for all routing protocols
  157. submitted to the standards track.  Christian Huitema raised a concern
  158. about the scaling properties of MOSPF, and suggested the use of Reverse
  159. Path Forwarding with on-demand pruning as a backup mechanism for cases
  160. of router memory or processor exhaustion.  In the discussion that
  161. ensued, it was pointed out that, for the size of domains for which MOSPF
  162. is intended, the overhead of MOSPF is well within the capabilities of
  163. contemporary routers, given certain assumptions of worse-case behavior
  164. of multicast group members and senders.  However, it was observed that a
  165. good model for multicast workload does not yet exist, thus making it
  166. difficult to judge the value of Christian's proposed extensions.  The
  167. Group decided to submit the MOSPF draft, as is, to the IESG for
  168. publication as a Proposed Standard.
  169.  
  170. Open Shortest Path First IGP Working Group (OSPF)
  171.  
  172.  
  173.                                    3
  174.  
  175.  
  176.  
  177.  
  178.  
  179. After reviewing the four OSPF documents that were pending, the Group
  180. decided to:
  181.  
  182.  
  183.    o Submit the updated OSPF V2 spec for RFC publication, obsoleting
  184.      RFC1247 (some urgency exists, since the Group wants CIDR changes
  185.      communicated to the larger community);
  186.  
  187.    o Submit the OSPF Trap MIB as a Proposed Standard;
  188.  
  189.    o Publish a document describing how to implement OSPF on Frame Relay
  190.      as an Informational RFC; and
  191.  
  192.    o Delay the OSPF NSSA area document for small modifications.
  193.  
  194.  
  195. The Group spent the majority of the remaining time discussing a proposal
  196. for carrying BGP path information in OSPF (to eliminate Internal BGP).
  197. At the end of the meeting, the Group outlined a document describing RIP
  198. to OSPF transition strategies.
  199.  
  200. OSI IDRP for IP over IP Working Group (IPIDRP)
  201.  
  202. The IPIDRP and the BGP Working Groups met jointly with over 80 people in
  203. attendance for the two sessions.  Issues discussed during the sessions
  204. include the following:
  205.  
  206.  
  207.    o PIP's requirements for BGP/IDRP.
  208.    o Status of BGP-4 documents.
  209.    o Size of Local Preference in BGP-4.
  210.    o Size of MULTI_EXIT_DISC in BGP-4.
  211.    o IDRP for IP documents.
  212.  
  213.       -  IDRP for IP document.
  214.       -  IDRP for IP family document.
  215.       -  IDRP MIB.
  216.  
  217.    o BGP-4 Transport Session Statistics and Routing Statistics.
  218.    o IDRP/BGP-4 to OSPF.
  219.    o OSPF Paper.
  220.  
  221.  
  222. It was recommended that IDRP for IP be progressed to Proposed Standard
  223. as soon as one implementation was completed.
  224.  
  225. The BGP-4 has one implementation and was recommended to be progressed to
  226. Proposed Standard.
  227.  
  228. Source Demand Routing Working Group (SDR)
  229.  
  230. A brief tutorial on SDRP was given.  Changes to the packet format and
  231.  
  232.                                    4
  233.  
  234.  
  235.  
  236.  
  237.  
  238. forwarding specification since the last IETF were reviewed and approved
  239. without comment.  Prototype development on this portion of the protocol
  240. will continue.  Preliminary discussions were held on the contents of the
  241. usage document and on a proposed ``futures'' document.  A list of other
  242. tasks were enumerated and volunteers were drafted.
  243.  
  244.  
  245.  
  246.                                    5
  247.