Final ROLC minutes from Stockholm

[Andy Malis <[e-mail]>]

Minutes of the Routing Over Large Clouds (ROLC) Working Group

Reported by Greg Ruth (GTE Laboratories Inc.) and Andrew Malis (Ascom
Nexion), with assistance from David Horton (Centre for Information
Technology Research, University of Queensland).

The ROLC WG met in one session at this IETF.  There were 87 attendees.


Agenda

1. Agenda bashing
2. Classical IP over ATM update
3. ATM Forum/MPOA update
4. NARP and NHRP implementation experience
5. NHRP specification and open issues - draft-ietf-rolc-nhrp-04.txt
6. Applicability Statement - draft-ietf-rolc-nhrp-appl-II.txt
7. Protocol Analysis Document
8. NHRP MIB - draft-ietf-rolc-nhrp-mib-00.txt
9. Status and Workplan


Classical IP over ATM Update

Mark Laubach is updating the "Classical IP and ARP over ATM" RFC, and
plans to have a new draft out by August 1.  A change in that document
is that NHRP will be used as a fallback if there is no answer to the
ATMARP request.  The implication of this is that he needs an NHRP RFC
to refer to, and he challenged the group to produce an RFC in time.


ATM Forum/MPOA Update

Joel Halpern gave a brief update on recent progress at the ATM Forum's
MPOA (MultiProtocol Over ATM) SWG, chaired by George Swallow.  Joel
described the MPOA effort as closely paralleling the NHRP effort, but
intended to be protocol independent supporting IP, IPX, DECNET-IV,
Appletalk, etc.  At the June 95 meeting a baseline document was adopted
as the basis for further development.  The ATM Forum invites IETFers
(and the world at large) to review this document and comment.  There is
a mutual desire to bring ROLC and MPOA standards into closer alignment
with one another, the major current difference being NHRP's
encapsulation in IP headers.

The ATM Forum has provided public access to a few ATMF documents by the
following means:

* Web site:  http://atmforum.com
* anonymous ftp from ftp.atmforum.com:
* pub/contributions/atm94-0471.ps (P-NNI)
* pub/contributions/atm95-0824.ps or .txt (MPOA)

It was recommended that you read the postscript version of the MPOA
document.

Two mailing lists will be set up to discuss the above documents with
the public:

* [e-mail]
* [e-mail]

To register with either list, send a traditional subscription request to
the -request mailbox.  Note: as of 1 August, these lists were not yet
operational.


NARP and NHRP Implementation Experience

No NARP implementation experience was reported.

The chair reported that Ascom Nexion has an implementation in progress.

Bruce Cole (Cisco) reported that he has an NHRP implementation now
shipping, support for purge messages has been added, no support for
router-to-router, no real customer use yet.  The implementation will be
updated to reflect changes in the specification.

David Horton (Centre for Information Technology Research, University of
Queensland) presented some overheads concerning his implementation.  To
summarize, it implements both the NHRP client (NHC) and server (NHS) in
the same device, and currently uses different protocol numbers to
identify each.  The server handles multiple LISes, includes an SNMP
agent for monitoring, doesn't include server-server forwarding (yet),
does support purge, and is SunOS-based.  His future plans include one
protocol number with the NHC and NHS choosing which packets to ignore
when both receive, forwarding between multiple NHSes, extensions, SNMP
R/W for configuration, and an NHC SNMP agent.


NHRP Specification and Open Issues

The WG next discussed some NHRP open issues from the mailing list.

0. Remove router-to-router parts of the spec from the NHRP document -
consensus was to allow all "safe" router-to-router cases to remain and
reserve treatment of the rest to another document.  This way the NHRP
document (now referred to as NHRP Version 1) can go forward.  Internet
Drafts dealing with the full router-router case were solicited for the
Dallas meeting.  The safe cases are those described in the NHRP spec as
having the "stable" (B) bit set.

1. How should a client and server behind the same ATM address be
distinguished?  Three possible solutions are: a) give them different IP
addresses; b) assign each different protocol numbers; c) let them sort
out incoming NHRP messages between themselves.  The consensus was that
this is an implementation issue (it doesn't affect interoperability),
and should not be included in the protocol spec.

2. Include destination address in Purge requests - agreed.

3. Code Responder Address Extension and Prefix Extension consistently -
agreed.  The Prefix Extension is now coded as a mask rather than an
integer prefix length.

4. Add an "Invalid Extension" error code (9) - agreed.

5. Allow clients to send Purge Requests to servers (e.g. if the client
is about to go down) - agreed.

6. Order extensions to facilitate parsing - rejected.

7. Add an "Invalid Reply Received" error code (10), e.g. when no request
was sent but a reply was received - agreed.

8. Should we define a format for multiple Vendor Private Extension
(VPE) entries or just allow multiple instances of VPEs - allow multiple
instances.

9. Preventing the "domino effect" (if a datagram is forwarded along the
routed path, all the routers on the path will send NHRP Requests for
the destination address) - various solutions were suggested, including
having intermediate routers maintain a temporary state or requiring
them not to initiate their own requests depending on the port data
comes in on, but none was a clear win.  Since the coexistence of
different solutions will not impair interoperability, it was decided to
let each implementer do as he chooses.  The consensus was to document
the problem in the draft, list the possible solutions, and require
implementers to choose one.

10. Request for Address Prefix - deferred (since this is a
router-router issue, it does not have to be resolved in this draft.)

11. Router-router improvements - deferred, for the same reason.

The WG was asked if there were any other issues to discuss.  Rob Coltun
would like an NHRP request that goes to end stations, rather than the
end station's NHS, so that the end station can do load sharing.  For
example, a file server may have multiple ATM interfaces between which
it would like to spread the incoming load.  The end station would
indicate whether or not it should receive requests when it registers
with its NHS.  Rob was asked to write this up to discuss further over
the list and at the next meeting.


Applicability Statement

Derya Cansever (GTE Laboratories) presented his latest draft of the
applicability statement (draft-ietf-rolc-nhrp-appl-II.txt).  It was
suggested that for now the discussion of routing looping mention that,
because the NHRP Version 1 spec will only treat "safe" router-to-
router interactions, looping is not a problem for Version 1 of the
protocol.  The document will continue to include the description of the
problem, so that the knowledge is not lost.  It was also suggested that
there should be a statement to the effect that NHRP is not, at present,
appropriate for IP multicasting.


Protocol Analysis Document

The protocol analysis document has not been released yet, and the
author, Kanan Shah, was not able to attend the Stockholm meeting.  A
draft is expected before the next IETF meeting.  Kanan will be
attending that meeting.


NHRP MIB

The new MIB editor, Avri Doria, was introduced to the WG.  Avri has
received the MIB document, along with all comments submitted to date.
He is planning to roll currently received comments into the MIB.  All
are encouraged to read the MIB and comments already posted to the list,
and to submit comments of your own.


Removing IP Encapsulation and Server Mode

During open discussion, Rob Coltun requested that the WG simplify NHRP,
and allow it to be directly adopted by the ATM Forum MPOA group, by
removing server mode and its IP encapsulation.  During the discussion,
Joel Halpern described how NHRP can be transition into a network
without server mode.  As NHRP is deployed, requests will begin to be
sent to directly attached neighbors, along the routed path.  If the
next hop is also NHRP-capable, the request will be properly handled; if
not, it will be dropped on the floor because the receiver doesn't
recognize the protocol type.  In that case, datagrams will simply
follow the routed path as before, so nothing breaks.  Configuration is
much easier than it had been for server mode.

The chair listed the necessary changes to the spec:

* All server mode references must be removed from the text

* The IP encapsulation must be removed from the packet formats.

* An LLC/SNAP encapsulation is required.  The chair will sent a request
to the IANA for a PID codepoint in the IANA's OUI space.

Given the scope of these changes, the chair asked for clear consensus
for this change, and it was provided by the WG.  There were no
objections, including those with existing or in- progress
implementations.  There was no support for retaining server mode.


Work Plan

The NHRP Version 1 spec will be updated (in a timely manner) based upon
the above changes, and published as -05.  Following review on the list
and electronic WG consensus, it will be submitted to the Routing Area
Director for IESG consideration as a Proposed Standard RFC.

Internet drafts on the full router-router case are solicited for
discussion over the list and at the Dallas meeting.

The applicability statement and protocol analysis, when complete, will
become informational RFCs.

We plan to submit the MIB as a Proposed Standard RFC following the
Dallas meeting.  The work plan in the charter will now read:

Jul 95  Discuss implementation experience, NHRP open issues, companion
        documents

Aug 95  Submit NHRP Version 1 spec to IESG as Proposed Standard
        following post-Stockholm revisions

Dec 95  Discuss router-router case, after Dallas meeting submit
        MIB to IESG as Proposed Standard, and Applicability Statement
        and Protocol Analysis for Version 1 as Informational RFCs.

Mar 96  Finalize router-router case as NHRP Version 2, submit
        NHRP Version 2 as upgrade to NHRP Version 1.

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