Draft ROLC minutes

["Andrew G. Malis" <[e-mail]>]

Below are the Dallas minutes.  Sorry they took so long, but I wanted to try
to make sure I got everything in.  Before reading them, I highly suggest
you first grab everything you find in ftp://ftp.nexen.com/pub/rolc/.  All
of the viewgraphs and talks mentioned below are now available there,
including Hiroshi Suzuki's talk.  You'll notice that there are two
postscript files for his talk, part1 and part2, but that I was able to
combine them into one Acrobat (pdf) file.

Please reply asap if you have any comments - they are supposed to become
official a week from today.

Thanks,
Andy
-------
Draft Minutes of the Routing Over Large Clouds (ROLC)
Working Group

Dallas IETF, 4 December 1995 0930-1130 and
             5 December 1995 1530-1730.
Reported by Howard Berkowitz and Andrew Malis.

The ROLC WG met in two sessions at this IETF.  There were
approximately 145 attendees.

Agenda:
*  First Session
   *  Agenda bashing
   *  ATM Forum MPOA update
   *  Joint statement by the IPATM and ROLC chairs
   *  NHRP specification and open issues -
      draft-ietf-rolc-nhrp-06.txt
*  Second Session
   *  ATM Forum Liaison
   *  Local/Remote Forwarding Decision - draft-ietf-rolc-apr-03.txt
   *  Mobile NHRP Devices - draft-horikawa-mobile-nhrp-00.txt
   *  ATMARP/NHRP Translation
   *  Router-Router NHRP
   *  Status and Workplan

First Session:

ATM Forum MPOA Update

George Swallow, the ATM Forum Multi-Protocol Over ATM (MPOA)
Sub-Working Group chair, reported that the MPOA current approach is
based upon NHRP and MARS. No protocol design is being done; NHRP
"out-of-the-box" is desired.  The MPOA SWG appreciates the work
being done in the IETF to harmonize NHRP and MARS.  There is very
little interest in the ATM Forum in RFC 1577 (Classical IP over
ATM).  ATM Forum LAN Emulation (LANE) is used at layer 2.  Both
"edge devices" and routers are supported by MPOA. Server redundancy
is a major concern.  MPOA has additional concerns, such as edge
device-to-edge-device connectivity.  The external ATM Forum MPOA and
PNNI mailing lists, as reported at the Stockholm ATM Forum BOF,
still have not been set up by the ATM Forum. It is premature for the
IETF to be citing ATM Forum UNI 4.0; its public release date is
unclear, with a current February goal for straw vote.  Forum/ITU
politics may also delay its completion.

Joint statement by the IPATM and ROLC chairs

Mark Laubach (the IPATM chair) and Andy Malis presented a chair's
statement regarding ROLC and IPATM coordination of the transition
from ATMARP to ATMARP + NHRP to NHRP.  A mention was made that the
IESG has stated that a well- defined step-wise transition plan that
emphasizes interoperability with the installed base is required for
any evolution of a widely deployed proposed standard.  All clients
must be able to resolve the address of any other client by required
default behavior (for the given client type) regardless of
implementation or deployment.  In the following discussion, the ROLC
WG asked that references to NHRP be removed from Mark's IP/ATM
Classic2 draft, to allow a separate transition plan to be developed.

NHRP Specification and Open Issues

The WG next discussed some NHRP open issues from version -06
and the mailing list.

1.   MARS harmonization - Hardware Type field vs. Address
  Family field:  The motivation for each choice was continued
  from the mailing list discussion.  Good points were made on
  either side, after which the clear WG consensus was to use
  Address Family to identify the NBMA address type.  Grenville
  Armitage made the corresponding change to the MARS
  specification to allow continued NHRP and MARS harmonization
  - see draft-ietf-ipatm-ipmc-10.txt.

2.   MARS harmonization - address field coding and parsing:
  NHRP was zero-filling addresses to 32-bit boundaries, while
  MARS was not.  The chair noted that it would be nice for
  them to be same, if only for code reuse in your
  implementations.  After discussing the relative merits, the
  WG agreed to "align" with MARS and not zero-fill addresses
  to 32-bit boundaries.

3.   Destination prefix vs. mask:  The consensus was to go
  back to the prefix rather than the mask.

4.   Using prefixes with purge messages:  The consensus was
  to allow prefixes with purges.

5.   Purge acks: The WG discussed whether or not purges
  should be acknowledged.  The consensus was yes.  It is up to
  each purge sender to decide whether to wait for the ack and
  whether or not to resend the purge if the ack doesn't come
  back, but purge receivers must always send acks.  There was
  little consensus one way or the other for adding a bit to
  the purge specifying whether or not the receiver should send
  an ack; this should be further discussed on the list.

6.   MTU: The suggestion was made to use currently unused
  header space for MTU discovery.  There was clear consensus
  to add this feature, as it is consistent with RFC 1626
  requirements.

7.   Server redundancy: This is not addressed in the current
  spec.  A strict reading suggests that if there is more than
  one NHS in a LIS, then NHRP clients must register with all
  of them.  The WG agreed that addressing server redundancy is
  required before NHRP is "ready for prime time".  The WG
  agreed that it would be a reasonable goal to leverage (and
  interoperate with) the IPATM WG's synchronization method, if
  possible.  This discussion will be continued on the mailing
  list.

8.   Autoconfiguration:  The issue of how to configure
  clients and servers came up during the redundancy
  discussion.  There was strong consensus for
  autoconfiguration capabilities, supported either from
  network management via the NHRP MIB, or via a configuration
  server.  The point was made that while ATM anycasts are
  useful to find configuration servers, they should not be
  used to find NHRP servers.  There was consensus to use NBMA-
  level configuration services if possible; this led to a
  liaison to the ATM Forum regarding ROLC's interest in using
  the ATM Forum's LAN Emulation Configuration Server (see
  below).  The point was also made that ATM Forum anycasts
  cannot be used in an IETF document until UNI 4.0 is publicly
  available.  This discussion will also be continued on the
  list.

9.   [This was actually discussed in the second session, but
  logically fits in here].  The question was asked why clients
  are configured with their server's IP address.  The
  consensus was that this was just a holdover from server
  mode, and that it should be removed from the spec.

Second Session:

Joint ROLC/IPATM Liaison the ATM Forum

The ATM Forum liaison was discussed and amended. The liaison
included two sections, one suggesting leveraging the LANE
configuration server for IETF uses, the second asking for
LAN Emulation Configuration Server redundancy.  The liaison
was later presented at the IPATM WG meeting, where it was
accepted and forwarded to the ATM Forum liaison, Joel
Halpern.

Local/Remote Forwarding Decision

Yakov Rehkter presented draft-ietf-rolc-apr-03.txt.  His
talk discussed issues such as: Why do we care how the
local/remote decision made?  When can SVCs be used
effectively?  When is the overhead of SVC setup justified?
Other issues discussed included  connection setup/teardown,
Quality of Service, and SVC sharing.  He pointed out that we
should rethink the subnet model, and replace it with a local
vs. remote model. Numerous options then result,
significantly larger than with the classic LIS model. If the
model is relaxed, can link layer connectivity always be
reached?  Try to establish connectivity--if not reachable,
then fall back to the routed path.  How should we do address
assignment in the absence of the subnet model?  Instead, use
the notion of "groups."  A group implies assignment of end
host and router addresses from a single prefix.  Routers in
the group advertise routes to the prefix.  In discussion,
the WG agreed to the term "Local Address Group" (LAG) for
this group.  The WG also agreed that Yakov will update the
draft based upon the discussion, and there will be a
subsequent WG last call, followed by submitting the draft to
be published as an Informational RFC.

Mobile NHRP Devices

Hiroshi Suzuki presented draft-horikawa-mobile-nhrp-00.txt.
He began his talk by noting that it is more of a "NHRP
Client Autoconfiguration" than a "Mobile NHRP" talk,
although mobility issues were also included.  He stated that
autoconfiguration is required to make supporting a large
number of clients practical.  He presented the client's use
of anycast to a "well-known" address to find any NHRP server
on the NBMA, not necessarily one in your LIS.  If a server
receives a registration for a client in a LIS other than its
own, then the server forwards the registration to the
client's home server along the usual routed path (just like
forwarding a NHRP Request).  This procedure only works when
the client is in the same NBMA cloud as its home LIS.  The
WG really liked this registration optimization, and agreed
to include it in the spec.  To allow secure registration,
NHRP also needs end-to-end authentication in addition to the
current hop-by-hop authentication.  The WG agreed that in
registration packets, encryption would be end-to-end,
otherwise hop-by-hop as before.

ATMARP/NHRP Translation

Rob Coltun presented one viewgraph on his approach to
ATMARP/NHRP translation.  His ATMARP and NHRP servers are co-
resident.  If an ATMARP  pertaining to the local LIS arrives
at the server, the ARP code handles it.  If it is beyond the
local LIS, the ATMARP code translates it into a NHRP
request, and forwards it to the NHRP code.  The same model
is also used for incoming NHRP requests.

Router-Router NHRP

Yakov Rehkter presented his approach to router-router NHRP,
based upon two messages he sent to the mailing list.  Yakov
discussed tradeoffs required for cut-through paths,
including increased state and control traffic, how to
determine whether a cut-through path is still valid, how to
avoid black holes and routing loops, how to determine when
to bring down SVCs, and interactions with BGP and inter-
domain routing.  Yakov will be documenting this information
in a forthcoming draft, which the WG agreed will be the
basis for further work.

Status and Work Plan

The WG agreed that the charter and work plan need to be
revised; this will be done on the list.  The tentative work
plan discussed in the meeting is:

  Dec 95  Produce version 07 of the NHRPv1 spec, new LAG
          (was APR) draft.

  Jan 96  Final calls on these documents, submit to IESG

  Mar 96  Discuss companion documents - NHRPv1 Applicability
          Statement, MIB, Protocol Analysis, router-to-
          router (NHRP v2), server-to-server
          synchronization,  transition plan, using shortcuts
          for IP multicasting

  Jun 96  Discuss implementation/interoperability issues,
          finalize NHRPv1 companion documents, further
          discuss NHRPv2.

  Dec 96  Complete NHRPv2.

The meeting adjourned following this discussion.

Later in the week, the ROLC and IPATM chairs met with the
Routing area director (Joel Halpern) and the Internet area
directors (Susan Thomson and Frank Kastenholz) to discuss
the transition plan and direction of the working groups.
The recommendations to the working groups from this meeting
are that:

1.   The IPATM Classic2 draft should proceed with ATMARP and
  without reference to NHRP, and include ATMARP server
  synchronization.

2.   The IPATM and ROLC working groups should coordinate MIB
  development, explore leveraging the same server
  synchronization methods, and keep in mind that future
  IAB/IETF directions may require authenticated address
  registration (i.e., this is a heads up, and don't preclude a
  straightforward evolution to this as part of the
  synchronization work).

3.   A future ROLC RFC will be used to specify how to
  substitute NHRP for ATMARP; i.e., IPATM will continue to
  develop ATMARP in its work at this time.

End of Minutes