CURRENT_MEETING_REPORT_

Reported by Greg Ruth/GTE Laboratories and
Andrew Malis/Ascom Nexion

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

These minutes were reported by Greg Ruth and Andrew Malis with
assistance from David Horton.

The ROLC Working Group met in one session at the 33rd IETF. There were
87 attendees.


Agenda

   o Agenda bashing
   o Classical IP over ATM update
   o ATM Forum/MPOA update
   o NARP and NHRP implementation experience
   o NHRP specification and open issues (draft-ietf-rolc-nhrp-04.txt)
   o Applicability Statement (draft-ietf-rolc-nhrp-appl-II.txt)
   o Protocol Analysis Document
   o NHRP MIB (draft-ietf-rolc-nhrp-mib-00.txt)
   o 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 1 August.  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 1995 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:


   o Web site:  http://atmforum.com

   o 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:


   o x-pnni@atmforum.com
   o x-mpoa@atmforum.com


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 LISs, includes an SNMP agent
for monitoring, does not 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 NHSs, extensions, SNMP
R/W for configuration, and an NHC SNMP agent.


NHRP Specification and Open Issues

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

 0. Remove router-to-router parts of the specification 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 specification 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 does not
    affect interoperability), and should not be included in the
    protocol specification.

 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 implementors 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 working group 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 specification 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 working group.
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 working group
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 transitioned 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 does not
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 specification:


   o All server mode references must be removed from the text.
   o The IP encapsulation must be removed from the packet formats.
   o An LLC/SNAP encapsulation is required.  The chair will send 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 working group.  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 specification will be updated (in a timely manner)
based upon the above changes, and published as -05.  Following review on
the list and electronic working group 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 specification to the IESG as a Proposed 
         Standard following post-Stockholm revisions.

 Dec 95  Discuss router-router case.  After the Dallas meeting, submit 
         the MIB to the IESG as a 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 an upgrade to NHRP Version 1.