Final ROLC minutes

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

These are the final ROLC minutes.  Thanks to Carl for his comments.

Andy
-------
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 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 view was expressed that while ATM anycasts are useful to find
configuration servers, they should not be used to find NHRP servers,
but the WG did not reach consensus on this point.  There was
discussion of whether to use NBMA-level configuration services when
available; 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.
The autoconfiguration discussion will 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 to 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:

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

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).

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

__________________________________________________________________________
Andrew G. Malis   Ascom Nexion                      voice: [phone]
[e-mail]   289 Great Rd., Acton MA 01720 USA   FAX: [phone]