home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 94dec / nosi-minutes-94dec.txt < prev    next >
Text File  |  1995-02-28  |  10KB  |  245 lines
  1.  
  2. Next Generation and OSI BOF (NOSI)
  3.  
  4. Reported by Ross Callon/Bay Networks and Brian Carpenter/CERN
  5.  
  6. About 35 people attended this BOF, chaired by Brian Carpenter.
  7.  
  8. In the IPv6 base document, and in discussions in the Toronto IETF, it
  9. was suggested that it would be useful to be able to map NSAP addresses
  10. into IPv6 addresses.  This appears to be related to CLNP to IPv6
  11. transition.  However, there is no consensus on whether the IETF needs to
  12. do anything in this space (for example, work might be done in ISO
  13. instead).  We need to understand the requirements first, then consider
  14. work items, and where (what group) they should be done.
  15.  
  16. Thus, the agenda for this BOF:
  17.  
  18.  
  19.    o Agree on general OSI to IPv6 conversion requirements
  20.    o Agree on major network layer scenarios
  21.    o Identify useful mechanisms and hear from their proponents
  22.  
  23.  
  24. SC6 (ISO/IEC JTC1/SC6) presumably has an issue, regarding whether to
  25. continue work on CLNP. We might want to consider (as individuals) giving
  26. some ideas to them.  Note that Jack Houldsworth was present in the BOF
  27. as ISO liaison.  DEC is also planning support for customers using DECNET
  28. Phase V (using CLNP) to use DECnet over IP -- we would like to
  29. understand from the DEC folks how this is being done.
  30.  
  31. Question from the floor:  What is the forum for experimental work on OSI
  32. applications over the Internet?  Nobody had an answer.
  33.  
  34. Brian Carpenter presented conversion requirements:
  35.  
  36.  
  37.    o R1.  Existing CLNP networks want to migrate to TP4 over IPv6
  38.  
  39.    o R2.  Existing CLNP network wants to migrate to Internet
  40.      applications over IPv6
  41.  
  42.    o R3.  Planned CLNP net changes plan to instead go to TP4 over IPv6
  43.  
  44.    o R4.  Planned CLNP network change their plan to instead to Internet
  45.      application over IPv6
  46.  
  47.    o R5.  TP0/CONS net wants to migrate to TP0 over IPv6
  48.  
  49.    o R6.  (Are there others?)
  50.  
  51.  
  52. It was pointed out that the ``TP4'' and ``TP0'' in above requirements
  53. should really say ``OSI applications.''  Customers do not care which
  54. transport layer protocol is being used.  The API over the transport
  55. layer may need to stay the same.  It was also pointed out that the above
  56. requirements are not mutually exclusive; they just show the range of
  57. possibilities.
  58.  
  59. Brian then gave four possible scenarios for the network layer:
  60.  
  61.    o Proposal 1:  The final goal is a pure IPv6 network with pure IPv6
  62.      addresses, with no trace of CLNP nor NSAPs.
  63.        + Simple end scenario.
  64.        - CLNP investment lost.
  65.          (This last point is controversial; some knowledge may be
  66.          maintained, and the knowledge that is maintained may be the
  67.          bulk of the retrievable investment.)
  68.  
  69.    o Proposal 2:  Final goal is an IPv6 network in which some hosts have
  70.      NSAP addresses.
  71.        + (?)  NSAP addressing plans preserved.
  72.          (This alleged advantage was vigorously debated, with some folks
  73.          feeling that there is no significant advantage either way, in
  74.          that the bulk of the effort can be used even if the exact 20
  75.          byte addresses are not).  -- Extra complexity in hosts and
  76.          routers.
  77.        - Two address plans connected only by IDRP.
  78.          (It was politely pointed out that this is bogus.)
  79.        - No CLNP service despite having OSI addresses.
  80.  
  81.    o Proposal 3:  Final goal is a pure IPv6 network with a pure IPv6
  82.      addressing and routing, but NSAP addresses are transported
  83.      end-to-end as an option.
  84.        + Preserves NSAP plans as pseudo-EID.
  85.        + Complexity limited to participating hosts.
  86.        - Two independent addressing schemes.
  87.        - Still no CLNP service.
  88.  
  89.    o Proposal 4:  Tunnel CLNP over IPv6.
  90.        + No modification to IPv6.
  91.        + Preserves CLNP investment.
  92.        - CLNP hosts only see each other.
  93.  
  94.  
  95. There was no discussion about the viability of scenarios 1 and 4.
  96. However, 3 found little support and 2 is controversial (see later
  97. discussion on address mapping).
  98.  
  99. Mechanisms:
  100.  
  101.  
  102.    o M0:  The Null mechanism:  Tell CLNP users to run IPv6.
  103.  
  104.    o M1:  Develop a CLNP to IPv6 transition plan (``Avoid Brutal User
  105.      Transition'' ABUT).
  106.        + Stepwise transition like SIP/TUBA.
  107.        - Some folks think that this might be expensive.
  108.          (Not clear what they mean by ``expensive,'' or what is the
  109.          alternative.)
  110.  
  111.    o M2:  Squeeze NSAPs into 16 bytes.
  112.        - Does not appear to explain all of the transition steps that are
  113.          necessary.
  114.  
  115.    o M3:  Map IPv6 addresses within the NSAP format.
  116.        + Useful for stepwise transition.
  117.        - This also is not complete plan (may be part of M1, for
  118.          example.)
  119.  
  120.    o M4:  Carry full NSAPs in IPv6 extension headers.
  121.        + Preserve rull NSAP space.
  122.        - Complicates routing (how, details uncertain).
  123.        - Implementation complexity.
  124.  
  125.    o M5:  Carry NSAPs as end-to-end option.
  126.  
  127.    o M6:  Encapsulation of CLNP over IPv6:  nextheader=CLNP.
  128.      (This is easy given current standards and software.)
  129.  
  130.    o M7:  Update RFC 1006 (TP0 or TP4 over TCP over IP).
  131.      (Seems to be simple.)
  132.  
  133.    o M8:  Support TP4 directly over IPv6.
  134.      (This is easy given current standards and software.)
  135.  
  136.    o M9:  Map NSAPs to IPv6 addresses via DNS.
  137.  
  138.  
  139. Ross Callon gave an overview of ABUT (TUBA backwards) which he will
  140. summarise for the mailing list.  Essentially it is a dual stack
  141. transition as proposed for TUBA and IPv4 to IPv6.
  142.  
  143. Jim Bound gave a description of a mechanism for mapping NSAPs into 16
  144. byte IPv6 addresses.
  145.  
  146.  
  147.    o Split CLNP address into a high part and low part
  148.    o Map the high part and recombine with the low part
  149.  
  150.  
  151. For details see draft-carpenter-ip6-nsap-map-00.txt.
  152.  
  153. This draft is alleged to cover all known deployed CLNP addressing
  154. schemes (ICD and DCC formats with unused and reserved bytes deleted).
  155. Proponents of other schemes need to show why this is insufficient.
  156.  
  157. Ross pointed out that the ABUT transition scheme does not require any
  158. particular relationship between CLNP and IPv6 addresses.  Each
  159. organisation can use whatever means it wants (assuming that the
  160. addresses are topologically reasonable).  It is permitted and reasonable
  161. to use the Jim/Brian address mapping, but ABUT does not require that all
  162. organisations coordinate their means of mapping NSAPs into IPv6
  163. addresses.
  164.  
  165. Jack Houldsworth gave an overview of NSAPs.  He pointed out the
  166. flexibility of NSAPs (for example, the ability to encode X.121, F.69,
  167. E.163 and E.164, etc).  One question came up regarding which of these
  168. formats are actually used?  Clearly E.164, DCC, and ICD are being used.
  169. Perhaps the biggest difference between NSAPs and IPv6 addresses is that
  170. NSAPs explicitly allows embedding of many different other address
  171. families, whereas IPv6 addresses are expected to be assigned for IPv6 in
  172. a topological/well packed manner.  Jack also proposed a scheme where the
  173. IPv6 address field would be the ``top'' of an NSAP, with the leftover
  174. part in an IPv6 option.  For details see
  175. draft-houldsworth-ip6-nsap-use-00.txt.
  176.  
  177. A transition mechanism for ABUT was proposed by Ross Callon here.  If
  178. what comes back from DNS is an IPv6-type NSAP address, then use simple
  179. IPv6.  Otherwise, do another DNS lookup to map the ``real'' NSAP into
  180. IPv6, and then encapsulate the full NSAP address.  We could first
  181. migrate the CLNP world towards trivially IPv6-mappable addresses.
  182.  
  183. Alan Lloyd discussed options for sorting out addressing.  His goals are:
  184. To provide ``harmonisation'' between ISO NSAPs and IPv6 addresses; to
  185. permit ISO to administer some of the IP address blocks; to provide a
  186. network design approach that enables address convergence to IPv6.  He
  187. stated a requirement:  to have compatible address forms for NSAPs and
  188. IPv6.  IPv6 in NSAPS are easy.  For NSAPs in IPv6, propose to assign
  189. first bytes of IPv6 addresses to be compatible with some NSAP AFIs.
  190. These need to use assigned NSAPs which fit into 16 bytes.  This thereby
  191. allows ``bi-lingual'' addresses.  For details see
  192. draft-lloyd-ip6-iso-itu-reg-00.txt.
  193.  
  194. The view that IPv6 addresses and NSAP addresses (such as those for ATM)
  195. should be harmonised, i.e.  part of the same global address space, was
  196. strongly defended by Alan Lloyd.  [However, it seems to be at odds with
  197. the architectural view of IP as ``one protocol to bind them all'' with
  198. an over-riding address space.  This architectural issue was not clearly
  199. identified during the BOF, but has since been raised on the mailing
  200. list.  Further debate on this is required.]
  201.  
  202. Multiple people were concerned about the implications of splitting the
  203. NSAP address between two parts of the header -- the first ``n'' bits in
  204. the IPv6 address, and the rest in an extension.  Keith Sklower was
  205. concerned about embedding the NSAP length as the high order part of the
  206. address, since this causes an explosion in the number of routing entries
  207. in forwarding tables.  Jim Bound and Ross Callon expressed support for
  208. the notion of providing a graceful migration from CLNP to IPv6, but also
  209. expressed strong concern with specific technical aspects of Alan's
  210. proposal, stating that the proposal had to work well and be
  211. implementable, reasonable efficient, and manageable.
  212.  
  213. Dan Harrington, DEC presented an alternative proposal.  The ``top'' of
  214. an NSAP (actually the part useful for routing) is in the IPv6 address,
  215. and the entire NSAP is carried in a header extension.  This is similar
  216. to the Houldsworth/Lloyd proposals but perhaps slightly cleaner.
  217.  
  218. It appears that all of these proposals are compatible with the ABUT
  219. transition scheme, in which either CLNP or IPv6 is used end to end for
  220. any particular datagram.
  221.  
  222. Work items:
  223.  
  224.  
  225.    o Description of the ABUT plan (Ross Callon)
  226.    o Address mapping needs to be worked on (all, combined proposal
  227.      needed)
  228.    o Tunneling (simple, but volunteer needed)
  229.    o TP4 over IPv6 (new work, volunteer needed)
  230.    o RFC 1006+ (fairly simple, Scott Bradner was heard to volunteer)
  231.  
  232.  
  233. Action items:  proposers will write up their own proposals if not done.
  234.  
  235. The group expects to meet again in Danvers.  The objective would be to
  236. decide whether ABUT and/or a combined address mapping proposal should be
  237. followed up (working group chair and activists needed for that).  The
  238. architectural issue about address space harmonisation also needs to be
  239. resolved.
  240.  
  241. To subscribe to the NOSI mailing list, use
  242. majordomo@sunroof.eng.sun.com, and write subscribe nosi in the text.  At
  243. present this is not an archived list.
  244.  
  245.