Final Danvers ROLC minutes

[Andy Malis <[e-mail]>]

Routing Over Large Clouds (ROLC) Working Group Minutes
IETF Meeting, April 3, 1995
Danvers, Massachusetts

Chair: Andrew Malis, Ascom Nexion
Minutes: Howard Berkowitz and Andrew Malis

Mailing lists:
General Discussion:[e-mail]
To Subscribe:      [e-mail]
Archive:           ftp://cnri.reston.va.us/ietf-mail-
                   archive/rolc/

The ROLC working group met in two sessions.  The first session is
reported on in these minutes.  The second session, which has a
separate set of minutes, was a joint meeting of the ROLC and IP/ATM
working groups.

There were over 120 attendees at the first session.

Agenda
1. Agenda bashing
2. ATM Forum MPOA Update
   Presented by George Swallow, cisco Systems, Chair, ATM Forum
   Multiprotocol Over ATM Working Group
3. NHRP implementation experience
4. NHRP open issues and draft (draft-ietf-rolc-nhrp-IV.txt)
   Presented by Dave Katz, cisco Systems
5. NHRP Applicability Statement (draft-ietf-rolc-nhrp-appl-01.txt)
   Presented by Derya Cansever, GTE Laboratories
6. NHRP MIB (draft-ietf-rolc-nhrp-mib-00.txt)
   Presented by Mike Patrick, Motorola ISG
7. Status and Workplan


1. Agenda Bashing
No changes were made to the agenda.


2. ATM Forum Multiprotocol over ATM (MPOA) Update
George Swallow

The initial BOF was held last September, and the Forum began a WG in
November before last IETF The scope and requirements are complete.

The plan is to support MPOA with an Overlay Model comparable to ROLC.
It is intended to be compatible with integrated PNNI, and a future
Peer Model is not precluded.  Any solution must interoperate with LAN
emulation and non-ATM devices.

In the reference model, the MPOA service cloud interconnects with LAN
emulation as a separate service over ATM.  The exact nature of this
interconnection has yet to be defined.

It is intended to be "a good citizen of the Internet".

MPOA and NHRP relationship:

An MPOA requirement is to build on NHRP.  There is a strong feeling
this should be more general with regard to the network layer, however
the group is concentrating on ATM, rather than supporting general link
layers.


3. NHRP Implementation Experience

No implementation experience was shared in the meeting.  The chair
said there are at least two implementations in progress.  cisco
Systems announced that they are one of the two, and plan to begin
testing soon.


4. NHRP Open Issues And Draft
Dave Katz

The new draft was distributed on the list as draft-ietf-rolc-
nhrp-IV.txt.  An official -04 version will be submitted as an Internet
Draft several weeks following the meeting, and including all comments
and changes from the meeting.

Dave Katz gave an overview of the changes to the specification.  This
is the same list of changes he included in the introduction to draft
-IV itself.

Dave then led the discussion.

* The need was discussed for a separate document discussing the
router-to-router case, because of its complexity.  Dave will start a
new Internet Draft on the topic.

* NHRP servers along the path are now not allowed to cache NHRP
entries information unless the new bit is set indicating that the
information is stable.

* If metrics are not preserved between routers (e.g., in OSPF-BGP
interactions), then there is the potential for looping.  Full semantic
preservation of metrics prevents loops from forming.  NHRP is also
loop free when used in one AS, or the new stable bit is set in the
NHRP reply, or if stub networks have no back doors.

* The goal that NHRP is usable in connectionless (SMDS) as well as
connection-oriented (ATM) environments.

* The chair encouraged people to comment on the looping problem (or
anything else, for that matter).  Revision -04 may be subject to the
last call for Proposed Standard; comments are solicited following its
publication.

* Curtis Villamizar wants the specification to state things more
clearly.  We know there are scenarios where routing loops can exist,
and we can't solve them all.  This should be mentioned in the
applicability statement.

* The question was asked if we denigrating NHRP because some of the
actions routers take?  The purpose of this WG is large clouds; the
solution is not viable if it only works over limited topology.  Dave
Piscitello replied that if the limited topology is widely used, then
the solution is still useful. NHRP will also be applicable to cases
where there is no exterior protocol.


5. NHRP Applicability Statement
Derya Cansever

Derya discussed the changes he has planned for the applicability
statement, draft-ietf-rolc-nhrp-appl-01.txt:

* Clarify the router-to-router case

* Not a replacement for routing protocols

* Clarification of potential looping cases

* Needs to be harmonized with NHRP-IV draft

The chair reminded the working group that the applicability statement
and protocol analysis must be submitted in order to standardize , as
well as the MIB and implementation experience when available.


6. NHRP MIB
Mike Patrick

Mike led a discussion of some issues with the current draft of the
MIB, draft-ietf-rolc-nhrp-mib-00.txt.

* The MIB has not yet been compiled.

* The section on cut-through circuits will be moved to the
applicability statement.

* Traps: customers like them, but engineers don't. Current plan is not
use traps.

* Unnumbered links over ATM: Consensus that these need to be
supported.  Every unnumbered link should have an ifIndex entry.
Consider OSPF methodology here.

* RFC 1573 logical interface addresses--is this being done?  Mike will
query.

* The MIB does not allow a LIS to be implemented on multiple NHRP
network IDs.  This was agreed to be acceptable assumption.

* May need additional indexing for QoS, and different MAC addresses
for different QoS.  MAC address plus QoS forms a tuple (cf. SNA
Virtual Route).


7. Status and Workplan

The chair asked to be told, in public or private, of implementations
underway.  Kanan Shah will write the forthcoming protocol analysis
document.

July 95: Discuss implementation experience, submit NHRP document to
IESG as a Proposed Standard, continue to review companion documents.

Dec 95: Submit companion documents to IESG.

The charter will be updated to reflect this new workplan.