home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 95jul / area.routing.95jul.txt < prev    next >
Text File  |  1995-10-18  |  6KB  |  152 lines
  1.  
  2. Routing Area
  3.  
  4. Director:
  5.  
  6.  
  7.    o Joel Halpern:  jhalpern@newbridge.com
  8.  
  9.  
  10. Area Summary reported by Joel Halpern/Newbridge Networks
  11. Corporation
  12.  
  13.  
  14. Inter-Domain Multicast Routing Working Group (IDMR)
  15.  
  16. The IDMR Working Group met over two sessions in Stockholm.
  17.  
  18. The presentations fell into two categories:  those concerning ongoing
  19. implementation and simulation work, and those regarding hierarchical
  20. multicast.
  21.  
  22. It was evident that implementation and simulation work both in CBT and
  23. PIM has been the subject of much work.  Bay Networks is currently
  24. implementing CBT and hopes to release it this summer, whilst Cisco
  25. continue with their PIM implementation.  Workstation implementations
  26. continue in both PIM and CBT.
  27.  
  28. Simulation results conducted by Harris Corporation once again showed
  29. that shared trees compare favourably (especially in terms of delay and
  30. complexity) with shortest-path trees.  Original estimates of very poor
  31. delay characteristics of shared trees have proved inconclusive.
  32.  
  33. The recent growth of the MBone (its size has doubled over the past 8
  34. months) has meant that it was necessary to focus on the architectural
  35. and engineering aspects of the MBone so that it can survive this growth.
  36. Deering et al.  recently proposed Hierarchical Multicast whereby the
  37. MBone should be divided into non-overlapping `regions', with Level 1
  38. routers operating one multicast routing protocol inside a region
  39. (intra-region), and Level 2 routers operating DVMRP between regions
  40. (inter-region).
  41.  
  42. The presence of DVMRP at Level 2 is considered an incremental first step
  43. in the deployment of hierarchical multicast for the short term.  The
  44. proposal for its implementation at Level 2 in the short term is due to
  45. the extensive implementation experience we have had with DVMRP. However,
  46. Level 2 DVMRP should eventually be replaced by whichever IDMR protocol
  47. is chosen by the working group as being the most effective in terms of
  48. scalability, simplicity, and the (non-)complexity of its interface with
  49. Level 1 routers.
  50.  
  51. Hierarchical CBT was presented, showing how CBT can interoperate with a
  52. variety of multicast protocols both at Level 1 and Level 2.  A similar
  53. presentation was made for PIM. It was especially evident from these
  54. presentations that the issue of core (or RP) advertisement and selection
  55. needs further investigating with the goal of finding a scalable
  56. solution.
  57.  
  58. The consensus of opinion was that much more implementation experience is
  59. needed in order to establish a Level 2 protocol, and also to establish
  60. whether multiple Level 1 protocols can co-exist.  This is very much
  61. dependent on whether a simple, uniform, and non-complex Level 1/Level 2
  62. interface can be defined.
  63.  
  64.  
  65. Inter-Domain Routing Working Group (IDR)
  66.  
  67. Agenda for the Tuesday IDR meeting:
  68.  
  69.  
  70.    o Agenda bashing
  71.    o BGP-4 to Standard
  72.    o DPA proposal (Tony Bates, MCI)
  73.    o Route Server to Experimental
  74.    o Route Damping proposal
  75.  
  76.  
  77. Yakov will issue a last call to the group within a month for all the
  78. BGP-4 documents.  The DPA proposal was reviewed, and two vendors have
  79. indicated their intent to implement this proposal.  The Route Server
  80. document works on solving the IBGP full mesh problem.  The document will
  81. move to Experimental, and has been implemented by one router vendor.  An
  82. alternative solution to the IBGP full mesh problem has been implemented
  83. by Cisco systems, and will be written up prior to the next meeting.
  84.  
  85. Route flapping has become an issue in the Internet.  Curtis Villamizar
  86. wrote up a document on how to damp out route flapping two years ago.
  87. This algorithm has implemented, and an updated document will be forward
  88. to the group by next IETF.
  89.  
  90.  
  91. IP Routing for Wireless/Mobile Hosts Working Group (MOBILEIP)
  92.  
  93. The Mobile IP Working Group met three times in Stockholm; once jointly
  94. with the IPng Working Group (IPNGWG) to discuss mobility for IPv6; and
  95. twice to continue to reach closure on mobility for IPv4.  The next two
  96. paragraphs summarize each of these respective topics.
  97.  
  98. IPv6 -- The consensus seemed to be that:  (a) IPv6 mobility should
  99. exploit the enhanced functionality of IPv6 (as compared to IPv4) and
  100. should not be simply a transliteration of IPv4 mobility; and (b) that
  101. the MOBILEIP Working Group's charter should be modified (if necessary!)
  102. to include responsibility for IPv6 mobility.  That is, mobility for IPv6
  103. should be `owned' by the MOBILEIP Working Group.
  104.  
  105. IPv4 -- Patent issues are still plaguing the MOBILEIP Working Group.  At
  106. the request of the co-chairs, Joel Halpern (Routing Area Director) will
  107. request funds from ISOC to have legal counsel investigate the scope of
  108. infringement of the current working group draft on the patent by Charlie
  109. Perkins (IBM). Otherwise, the substantive content of the draft seems
  110. ready for implementation; in fact, many working group members plan to
  111. test inter-operability of their respective implementations, tentatively
  112. scheduled for the end of August.  The group agreed that a wholesale
  113. rewrite of the draft (editorial changes not content changes) was in
  114. order.
  115.  
  116.  
  117. New Internet Routing and Addressing Architecture Working Group
  118. (NIMROD)
  119.  
  120. The NIMROD Working Group met on 19 and 20 July.  Most of the meeting
  121. time was taken with the following presentations:
  122.  
  123.  
  124.    o Overview of the Implementation Model
  125.    o Agent Discovery Protocol
  126.    o Path Set-up Protocol
  127.    o Reliable Transaction Protocol
  128.    o Query Response and Update Protocols
  129.  
  130.  
  131. The main point of discussion was on connectivity restrictions between
  132. agents of a node and the agents of its subnodes.  The consensus of the
  133. group was to that the `tight' restrictions were too confining and that a
  134. way to make a component node act as a `virtual' forwarding node for the
  135. parent node should be supported---for example, as part of the
  136. agent-discovery flooding protocol.
  137.  
  138.  
  139. Routing Over Large Clouds Working Group (ROLC)
  140.  
  141. The ROLC Working Group met in Stockholm, with 87 attendees.  The group
  142. substantially completed work on NHRP Version 1, which includes
  143. host-host, host-router, router-host, and limited router-router
  144. operation.  Version 05 of the NHRP specification will be produced
  145. following the meeting, and after obtaining final consensus on the list,
  146. will be submitted for consideration as a Proposed Standard.
  147. Internet-Drafts discussing the full router-router case were solicited
  148. for the next IETF meeting.  The group also discussed the NHRP
  149. Applicability Statement, Protocol Analysis, and MIB documents, and will
  150. continue work on them, to conclude at the next IETF meeting.
  151.  
  152.