Editor's Note: These minutes have not been edited.
Internetworking Over NBMA (ION) WG
The meeting minutes were taken by Karen O'Donoghue and edited by George Swallow.
Andy Malis and George Swallow chaired the ION working group meeting, which
met during two sessions on Tuesday April 8, at 0900-1130 and 1300-1500.
Andy presented the agenda and the current status of WG documents not being
presented during the working group session.
The following document is awaiting RFC publication:
draft-armitage-ion-cluster-size (rumored to be RFC 2121)
The following drafts are in various stages of IESG review:
draft-ietf-iplpdn-frmib-dte (at the RFC editor)
draft-ietf-ion-bcast (completed IESG last call)
draft-ietf-ion-fr-update (completed IESG last call)
draft-ietf-rolc-nhrp (on hold by IESG awaiting SCSP)
draft-ietf-ion-marsmcs (Forwarded to IESG on 3/28/97)
Additional documents in progress:
draft-ietf-ion-mib (in progress)
draft-ietf-nhrp-mib (in progress)
draft-ietf-ion-mars-mib (in progress)
draft-ietf-ion-sig-uni4.0 (next revision, 03, will be released after
Memphis)
draft-ietf-ion-inarp-update (will start WG last call after Memphis)
draft-ietf-r2r-nhrp (work should continue in earnest after Memphis
meeting)
draft-carlson-nhrp-client (in progress)
The following internet drafts were presented and discussed.
1. RFC 1577 Update, Mark Laubach and Joel Halpern, draft-ietf-ion-classic2
Joel Halpern presented the current status of the draft. The latest
revision will be published shortly after the Memphis meeting. All comments
raised on the mailing list were incorporated with the exception of the
comment regarding E.164 NSAP addresses. It was not clear how to satisfy
the comment within the scope of the current effort. It was reiterated that
the intention of this document is to begin the transition to NHRP. A WG
last call will be issued once the draft appears.
2. Next Hop Resolution Protocol (NHRP), Jim Luciani, draft-ietf-rolc-nhrp
Jim Luciani made an informative presentation on NHRP,
draft-ietf-rolc-nhrp-11, which has already gone through WG last call and
has been forwarded to the IESG. The substantial changes to NHRP in revision
11 include the following:
- the addition of an NHRP Resolution Reply NAK
- removal of direct replies,
- addition of an S bit,
- renaming of the B bit to the D bit.
The document is very stable at this point, but is being held up awaiting
the completion of SCSP.
3. Server Cache Synchronization Protocol (SCSP), Jim Luciani,
draft-ietf-ion-scsp
The document has been divided as decided at the last meeting in San Jose.
The essential mechanisms have been pulled into a protocol independent
draft, "draft-ietf-ion-scsp". The nhrp and atmarp protocol specific
portions have been moved to their own respective documents. The protocol
independent piece will be going to going to WG last call. Another draft
will be produced for each of the others.
The significant changes to draft-ietf-ion-scsp include:
- removal of nhrp and atmarp protocol specific portions to respective
documents
- hello, cache alignment, and cache state update on a per SG basis only
- a clearer demarcation between protocol dependent and protocol independent
portions
- use of a cache key to identify an atomic element of synchronization
- CSAS record to encapsulate all information necessary to identify the
newness of an advertisement
- CSA record reformatted to include 2 pieces (newness information and
protocol specific portions)
- generic fragmentation engine removed
- additional information on SCSP point-to-multipoint and broadcast mediums
- protocol ID (PID) field reintroduced
- family ID mechanism introduced (allowing for grouping of hello protocol
instances)
- CSU replies now contain only CSAS records
- removed P bit from CSA record
- reworded cache alignment text
SCSP-NHRP (draft-ietf-ion-scsp-nhrp): Significant aspects of this document
include:
- LIS = SG
- procedures for when an NHC wishes to leave a SG
- values for SCSP mandatory common part
- values for SCSP CSAS records
It was clarified that the ID assumes IPv4 addresses. The question about
applicability to IPv6 was raised. It was pointed out that IPv6 would not be
using NHRP to move registration information.
SCSP-ATMARP (draft-ietf-ion-scsp-atmarp): Jim presented the first cut at
this document. A key issue is what to do when an ATMARP client wishes to
rejoin a SG. ATMARP doesn't have a requestID or a purge, therefore you have
to wait. The current text tells the client what to do. The document needs
to tell the server what to do in order that the client will not be able to
crash the server. Joel Halpern presented some of the alternatives that
could be used to address this problem.
To summarize the status of the SCSP documents, the NHRP draft is being held
by the IESG pending completion of the SCSP work. The SCSP protocol
independent document is ready for working group last call. The SCSP-NHRP
document is quite close to being ready. It was decided to continue
discussion for one month on the mailing list and then to issue the WG last
call. The SCSP-ATMARP document needs additional work. Joel Halpern agreed
to help on this particular document.
4. NHRP Protocol Applicability Statement, Derya Canserver,
draft-ietf-ion-nhrp-appl
Derya Canserver presented the latest revision of the nhrp applicability
document. M. Ohta voiced some concern that scalability issues raised on
the mailing list were missing from the document. Group consensus appeared
to be that the scalability issue was a concern, and that it was adequately
discussed in the document. George Swallow voiced some concern about the
statement that the r2r case was not addressed. Analysis has shown that the
r2r case works fine if you are not crossing metric boundaries. George
agreed to provide text to clarify this in the document. The intention of
the WG group is to turn this document around quickly and get it out for a
last call.
5. Transient Neighbors for IPv6 over ATM, Grenville Armitage,
draft-ietf-ion-tn
Grenville Armitage presented the document as released in March 1997. Major
changes to the document include:
* input from the San Jose meeting
* augmented MARS now mandatory
* rules for host tokens added
* rules for host side packet forwarding clarified
No issues were raised, and it is expected to go to WG last call soon.
6. MARS and SCSP, Grenville Armitage
The document draft-armitage-ion-mars-scsp has not been revised since
November 1996. It provides a general overview. A new document,
draft-armitage-ion-distmars-spec, is a first cut at specific details of
MARS using SCSP. Grenville realizes this document is incomplete. He asked
for volunteers to assist in the development of the specification.
7. VENUS, Grenville Armitage, draft-armitage-ion-venus
The WG last call on this document has now closed. There were some changes
to the abstract suggested on the mailing list to clarify the intentions of
the document. These changes are going to be made, and the document will
be forwarded to the IESG as soon as possible for publication as an
informational RFC.
8. EARTH, Michael Smirnow, draft-smirnow-ion-earth
This work incorporates two major concepts: multicast logical IP subnets
(MLIS) and multiprotocol over MLIS (MOM). There were a number of concerns
raised during discussion of the document. The limitation of MARS to a
single LIS was made to avoid some of the issues being raised with this
document. The existing routing protocols will not work with this document.
If the routing protocols are fixed and the MARS limitation is removed, it
is unclear what the difference between this approach and MARS would be.
While the working group appreciated his efforts, there was no consensus to
accept this as a work item. It was decided to continue discussion on the
mailing list. It may lead to an experimental RFC.
Working group session adjourned at 1100 am and reconvened at 1300.
9. Intra LIS Multicast Routers over ATM, David Meyer,
draft-farinacci-intralis-multicast
This draft offers a simple means of multicast support for a LIS which
contains no host. This document is based on the assumption that every
router in a LIS knows (can obtain extra to this protocol) the IP and ATM
addresses of all the other routers in the LIS. Each router maintains at
least one point-to-multipoint VC that includes all the other routers in the
LIS. It currently address PIM sparse-mode only, but the authors claim that
the technique is extensible to other multicast protocols. There was
consensus in the working group to address the topic. The solution may
require optimizations to specific multicast routing protocols. Issues that
need to be addressed include applicability, encapsulation, complexity, and
interoperability. The authors agreed to carry the work forward to the
mailing list.
10. Receiver Initiated Shortcut Path (RISP), Yao-Min Chin,
draft-ogawa-receiver-shortcut-path
Yao-Min Chen presented RISP, draft-ogawa-receiver-shortcut-path.00. The
discussion showed that this largely covered ideas that the WG had
considered in developing NHRP, but were not incorporated. Since the
functionality is close to NHRP, the draft was not accepted. The authors
were encouraged to bring forward a draft for a receiver initiated call as
an option to NHRP.
11. Intra-area IP unicast among routers over legacy ATM, Juha Heinanen
Juha Heinanen made a presentation on using ATM addresses carried in opaque
LSA in OSPF as a means for accomplishing IP unicast among routers within an
OSPF area. It was noted that similar mechanisms could be incorporated into
IS-IS and BGP.
The primary motivation is to provide a simple solution in the near term.
Juha felt that label switching would not address the problem because: it
would take too long to develop; upgrading ATM networks is not easy or
cheap; need a solution supported by the public ATM network.
Some key assumptions of this proposal include: the set of routers is small
enough to form a single area for the link state routing protocol; and the
maximum number of routers is less than 100.
The majority of the technical work is currently going on in the OSPF
working group. Rob Coulton briefly discussed the technical work being
pursued in OSPF. This working group will most likely result in an
informational RFC to document how to take advantage of the OSPF work.
End of minutes
======================================================================
George Swallow Cisco Systems (508) 244-8143
250 Apollo Drive
Chelmsford, Ma 01824