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.
