CURRENT_MEETING_REPORT_

Reported by Andrew Malis/Ascom Timeplex

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

There were 108 attendees, many of whom were newcomers.  The chair
announced that in order to get work done, the group would focus its
discussion on the current draft and not rehash earlier decisions
(especially the requirements and goals).  He then presented a set of
overheads to start the meeting and provide some background to
first-timers.

During the presentation, Curtis Villamizar reminded the group that at
the Seattle meeting, a goals and requirements document was discussed.
While they have been documented in both the Seattle and Toronto minutes
and proceedings, The chair invited him to write such a document.  He may
do so if he has the time.


ATM Forum Update

The working group received an ATM Forum update from Drew Perkins and
Joel Halpern, direct from the previous week's ATM Forum meeting in
Kyoto.

The primary news was from the Multiprotocol over ATM group.  Most of the
discussion there was concerning requirements, along with some discussion
of reference models.  The main agreement from the meeting was there will
be one host behavior, query-response (based upon Classical IP over ATM,
NHRP, and ATM Forum LAN Emulation).


Implementation Experience Reports

The one detailed report was from Kanan Shah of NRL. She has been
finishing her code and it is almost at the testing stage.  Testing will
take place on the ATDnet (a large-scale OC-48 ATM testbed that rings the
Washington DC area).  She plans on testing with Rob Coltun's PNNI
routing code.  Dave Katz said that cisco also has an implementation
under way (being developed by Bruce Cole), but was not at liberty to
further discuss its status.


Current NHRP Draft Review

Dave Katz, along with Dave Piscitello, the NHRP editors, led a detailed
review of the current draft, draft-ietf-rolc-nhrp-03.txt, which had been
distributed on the mailing list the previous week.  Among the major
issues discussed were:

   o There has been a change in the packet format.  The MBMA family
     identifier is now a 16-bit number, and can be found in ``Assigned
     Numbers.''

   o The Authentication option has also been changed.  An option has
     been added for MD5.

   o Curtis Villamizar brought up a question as to the semantics of the
     S bit, which will be better clarified in the text.  There will be
     further investigation of the usefulness of the ``S'' bit, which is
     used to identify whether a potential looping scenario exists.

   o The working group needs to further investigate the usefulness of a
     ``C'' bit to distinguish destinations attached directly to NBMA
     fabric from those that are not, and a ``J'' bit to say ``I assert
     that the destination I'm informing you of is directly reachable via
     me (no intervening routers).''

   o Curtis was recognized for his contribution in Section 8.1.
   
   o The working group needs to improve the description of destination
     masks (guidelines for constructing the mask, means by which
     requester distinguishes the appropriate mask length).

   o There was discussion on ``hole punching'' in cached aggregated
     destinations.

   o A discussion on options took place referencing non-optional and
     optional options.  For clarification, there is an option bit that
     tells the implementation what to do if it does not support
     particular options.  The terminology has been changed to
     ``discretionary'' and ``non-discretionary'' options.  Three of the
     options have been made discretionary:  destination mask option
     (Section 5.6.1); QoS option (Section 5.6.6); vendor-private
     (Section 5.6.8).

   o The discussion on page 2 that suggests that NHRP obviates the need
     for LISs will be revised.

   o A discussion of routing loops was led by Curtis.  The solution when
     a routing loop is detected is to break the VC. The group concluded
     that routing loops only occur in the router-to-router case, and
     then only if routers use NHRP information to take precedence over
     information learned by routing protocols.  Curtis is going to send
     mail to the list on the subject.

   o The question of when you use Classical ARP and when you use NHRP
     was raised.  The sequence of events will be:
   
      1. Only ARP servers are used as per RFC 1577.
      2. NHRP is phased in:
   
         -  Hosts continue to register with the ARP server (until ARP
            servers go away, for the benefit of non-NHRP hosts).  ARP
            servers will leak registrations to NHRP servers, so NHRP
            hosts do not have to register twice if they do not wish to
            (but then they must agree to certain defaults, such as the
            registration timeout period).  [Note that this is one way;
            NHRP servers never leak information to ARP Servers.]  If
            NHRP hosts wish to override these default values, then they
            must also register with the NHRP server.  Explicit
            registrations always take precedence over leaked
            registrations.

         -  NHRP source hosts send all address resolution requests to
            the NHRP server (without regard to the ``mask and match''
               operation).

         -  NHRP source hosts may send ARP requests to their ARP server
            if they get a NHRP NAK and the destination is in the same
            LIS.

      3. NHRP servers completely replace ARP servers.  All hosts are
         NHRP-capable.

   o Intermediate router operation:  If the IR is willing to set up a
     direct VC to the destination, it must be willing to cache the fact
     it has generated and/or forwarded the NHRP request for that address
     (so that it will not generate another).  If it is not willing to
     set up a VC, then it will not need to cache the fact that the
     request was forwarded.

   o On a related issue, the document should adequately cover how to
     restrict generation of NHRP requests (will every packet generate
     one if one is already in flight, will every NHS generate a request
     along the routed path, etc.).

   o Note that when a router returns an NHRP reply for its own IP
     address, it should mark the S bit as originating from a host.

   o A request to the group was made for someone to help with
     authentication, and Sandra Murphy of TIS volunteered to provide
     assistance.

   o It was agreed that more text should be added to the document
     discussing the aging of information.

   o The suggestion was made for a host implementation cookbook.

   o There was a request for volunteers who are willing to explore other
     protocols in the context of NHRP. Other protocols of interest are
     IPv6 and IPX. There were no volunteers in the room.  Please send
     mail to the chair if you are interested.


Dave and Dave will be producing a new revision reflecting the
discussion.


New Work Items

The Routing Area Director told the working group that a protocol
analysis document, while required for protocol standardization, was
probably premature at this point.  However, Kanan Shah has volunteered
to begin its preparation.

Two other documents were assigned to volunteers:


   o Protocol Applicability:  Derya Cansever.
   o The NHRP MIB: Mike Patrick.  Mike will begin by compiling an
     initial list of objects of ``interest'' for debugging, operational
     support, tuning knobs, and so on, and sending them to the list for
     review and suggestions.


Anyone interested in helping out with these documents should contact
either the authors or the chair.


Work Plan Update

   o It was decided that the NHRP document should be submitted to the
     IESG as a proposed standard following at least one more revision.
     The working group has a goal of Feb.  95 submission.

   o The working group should submit the companion applicability
     document to the IESG in April 95.

   o The working group should have a draft of the MIB document by April
     95.


An updated charter will be forthcoming.