The IP Over NBMA (ION) Archive

[George Swallow <swallow@cisco.com>]

Attached are the draft minutes of the ion wg from the Monreal IETF.
Please any comments to me and/or the list as you see fit.  Have them
in by this Thursday as I plan to post the final minutes on Friday.

...George
======================================================================

Draft minutes of the Internetworking over NBMA (ion) Working Group

Montreal IETF, 24 June 1996 1300-1500 and 25 June 1996 1300-1500 and
1530-1730. 

Notes were taken by Karen O'Donoghue.  (Many thanks from the Chairs).

The ion group met in three sessions at this IETF with a total of 279
attendees. The sessions were co-chaired by Andrew Malis
(malis@nexen.com) and George Swallow (swallow@cisco.com).  The first
session was primarily devoted to ongoing efforts (status, NHRP, RFC
1577 update, and RFC 1755 update). The second session dealt with IPv6,
and the third session addressed multicast.


First session, Monday 6/24, 1300-1500:

- Agenda Bashing and Administrivia

Andy Malis introduced the new working group, Internetworking over NBMA
(ion), and the new co-chair, George Swallow.  In addition, he thanked
Mark Laubach for his efforts as chair of the IP Over ATM (ip-atm)
working group.  The proposed agenda for the three sessions was discussed
and accepted.

The first issue addressed was one that was inherited from the iplpdn
working group, the Frame Relay DTE MIB. This document
(draft-ietf-iplpdn-frmib-dte-07.txt) is currently in last call.  A few
minor issues have come up, and these will be worked on the mailing list.
If these issues require extensive discussions, this ID may be moved to
the new Frame Relay services MIB working group currently being
chartered.

The second issue addressed was the naming of internet drafts for this
working group.  An ID which has achieved some working group consensus,
has an editor, and can be viewed as working group output should use
"draft-ietf-ion" in the name.  An ID which represents the views of the
author and for which the working group chairs have been notified of
the incoming draft, should use "draft-author-ion" in the name.  A
primary motivation for this approach is to give the co-chairs a
"heads-up" on incoming documents.  Unannounced drafts may be submitted
as is the IETF custom; however, the name of the draft should include
the author but not "ietf" or "ion".

- ATM Forum Activities

Joel Halpern gave a short update on ATM Forum activities.  The ATM Forum
has agreed in principle to make available all approved documents in a
public ftp site (ftp.atmforum.com); however, complete implementation of
this is still underway.  In particular, the traffic management
specification is available; however, the PNNI document is not yet on the
site.

George Swallow gave an update on the MPOA activities of the ATM Forum.
The MPOA work is progressing.  Since the last IETF meeting, the MPOA
WG has defined mandatory behavior for edge devices and addressed NHRP
extensions to support edge devices.  In particular a 'trigger' message
has been defined which allows a route server to request that an edge
device initiate a NHRP query.  Also, a cache imposition protocol has
been defined.  This allows the final router to install the proper exit
encapsulation in the exit edge device.  Tags are available to optimize
exit processing.  These will be carried in a TLV.

- MARS Update

Andy Malis provided an update of the MARS document.  Version 12 of the
MARS document was voted out by the ip-atm working group at the Los
Angeles IETF.  However, this document fell through the cracks during the
IESG turnover.  The IESG last call was issued in June and will close July
2.  In the absence of any significant comments, this document should go
to the RFC editor soon for publication as a proposed standard.

- NHRP

Jim Luciani provided a discussion on the changes that were incorporated
in NHRP Rev 8 (draft-ietf-rolc-nhrp-08).  A fairly detailed list of
changes is provided in the slides for this discussion.

A number of issues were identified and discussed: 

1.	NHRP Subnetwork ID - This was originally thought to be an
interesting idea, but it is a pain to implement.  When asked, no one
indicated that they were currently or planning to use it; therefore, it
was removed.

2.	Reuse of CIE for extensions - The information in the CIE
(Client Information Entry) is also present in several extentions, but
formatted differently.  The proposal was to use the same format to
make parsing simpler.  This seemed reasonable to the group.

3.	MD5 authentication and sequencing of extensions - There was
fairly lengthy discussion on this topic. The final outcome was that
"Ordering of the extensions inserted by the sender must be preserved and
must be inserted first in the list."  Fields requiring MD5 authentication
will come first.  The MD5 authentication comes next, followed by
fields not covered by the authentication.  Thus the authentication TLV
servers as the delimiter between the authenticated and unauthenticated
portions of the message.

4.	Routing of Registration Requests - Allow an NHC to include its
protocol address as the destination protocol address and let the routed
path get the packet to a correct NHS. This allows routing to deal with
the issue. This also was accepted.  

Jim will generate revision 09.  Since we appear to have reached
consensus on all of the open issues, we anticipate going to working
group last call shortly after the next draft is available.

- Serve Cache Synchronization Protocol

Jim Luciani next provided a discussion of the Server Cache
Synchronization Protocol (SCSP) (draft-luciani-rolc-scsp-03.txt). This
document is the combination of Joel Halpern's and Jim Luciani's input
to the Los Angeles IETF.  It has been chosen as the baseline for the
SCSP effort.  Changes since the last presentation include: the concept
of a Server group ID (SGID) was added; SCSP was defined as a
stand-alone protocol with a header; ATMARP and NHRP encodings in the
current draft were put in appendices; and MARS encodings were broken
out into a different specification.  SCSP has been adopted by LANE and
MPOA.  Discussion followed on spanning tree versus designated servers.

No major issues were identified in the discussions.  However, given the
recent availability of the draft, further discussion is encouraged on
the list.

- RFC 1577 Update

Mark Laubach discussed the latest status of the RFC 1577 update
(draft-ietf-ion-classic2-02).  Since the last meeting, all references to
server synchronization have been removed, appendices have been removed,
and a table of contents has been added.  The latest draft also includes a
pointer to the Classical MIB ID and includes the MTU material from RFC
1626.  There was some discussion on whether or not the MTU specification
should be a separate document.  It was decided to leave the MTU material
in the RFC 1577 update.

The authors requested the opportunity to make one final pass at the
document.  It is anticipated that this will go to wg final call shortly
after its appearance.

- ATM Signaling Support for IP

Maryann Perez Maher provided a discussion of the RFC 1755 update
(draft-ietf-ion-sig-uni4.0-00) to incorporate UNI 4.0.  The focus of
this effort is support for best-effort IP.  The UBR service category is
most natural, but the others are allowed as well.  Traffic parameter
negotiation is encouraged.  Frame discard is a must.  It was felt that ABR
should be described further.  The issll working group will discuss ABR.

Given the recent availability of the draft, further discussion is
encouraged on the list.


Second session, Tuesday, 6/25 1300-1500:

- IPv6 and Neighbor Discovery

Grenville Armitage provided an overview of the working group concepts
and issues for IPv6 over NBMA.  The current document
(draft-ietf-ion-ipv6nd-00.txt) reflects the general consensus of the
working group up to this point, and lists issues remaining to be
resolved.  To support NBMA, IPv6 links become "logical links".
Neighbors are nodes on the logical link or announced through the IPv6
ND Redirect.  IPv6 neighbor discovery is one layer up from IPv4 "ARP"
and is generic across link technologies.  IP multicast is assumed
meaning MARS will be a fundamental component.  Some open issues
include link local address generation and how to perform intra-LL ND
while allowing the discovery of "shortcut" paths.

- Transient Neighbors for IPv6 over ATM

In this discussion, Grenville Armitage provided his opinion (as
contained in draft-armitage-ion-tn-00) on some of the issues regarding
neighbor discovery for IPv6.  In particular, he felt that neighbor
discovery was generally necessary and sufficient, containing most of
what is needed.  The work is a revision of a model presented at the LA
IETF.  This model tries to use conventional host-side operation of the ND
protocol while still allowing the establishment of cut-through ATM
routes.  This is done using Redirects to create Transient Neighbors, IPv6
protocol operation, and partial NHRP for location of off-link
destinations.  The egress router identifies candidates for cut-through,
uses NHRP to find a better first hop, then issues a redirect to the
source.

- A Framework for IPv6 over ATM

Markus Jork presented the material contained in draft-ietf-ion-ipv6atm-
framework-00.  Goals of this work include: 1) define what an IPv6 "link"
is on ATM networks; 2) provide full IPv6 ND over ATM networks; 3)
require no new protocols to perform ND functions; 4) require no changes
to the IPv6 network layer for ATM; 5) maintain IPv6 address
configuration models; 6) maintain IPv6 security models and associations;
7) utilize existing technology; 8) maintain all ND, addrconf, and
security semantics; 9) scalable; 10) provide fault tolerance, redundancy
and failover; 11) minimize/eliminate ATM server state information; and
12) be simple and easy to implement.

- IPv6 over NBMA Networks

Ran Atkinson presented the work contained in
draft-ietf-ion-ipv6-nbma-00.  In this draft, NHRP is used to provide
IPv6 Neighbor Discovery and Address Autoconfiguration support. Ran
discussed IPv6 interface tokens, duplicate address detection, and
address resolution.  Interface tokens use IEEE 802 addresses where
possible.  Alternatively, E.164, X.121 or NSAP-like addresses can be
utilized.  Duplicate address detection would add a uniqueness bit and
modest extensions to NHRP with NHRP providing duplicate address
detection.

At this point, the chairs opened the floor for discussion of the three
proposals presented. There were a number of clarification questions on
the three presentations.  Referring to
draft-ietf-ion-ipv6atm-framework-00, Joel Halpern asked whether or not
we really wanted two multicast mechanisms.  Markus responded that a
second mechanism wasn't necessary and that MARS could be used instead.

After some discussion, the chairs asked each of the presenters what
they believed the differences in the proposals were and what the best
way forward would be. The general consensus was that the major
difference was where to run NHRP (on the host or on the router).  It
was also urged that the solution to neighbor discovery should attempt
to minimize the use of multicast/broadcast as the number of possible
recipients could be quite large.  There was agreement that a merged
draft will be produced from the three proposals with a goal to have
one server (MARS) instead of two. This draft is expected in advance of
the next IETF meeting.


Third session, Tuesday, 6/25 1530-1730

- Multicast Server Architectures for MARS based ATM Multicasting
- Multiple MCS support using an enhanced version of the MARS server

Rajesh Talpade presented his two drafts (draft-talpade-ion-marsmcs-00
and draft-talpade-ion-multiplemcs-00) in a combined presentation.  The
multiple MCS approach provides for fault tolerance, load sharing, and
auto configuration with minimal changes needed to MARS.

The definition of how to coordinate several Multicast Servers within
MARS was accepted as a new work item.

One discussion point was the mechanism used to coordinate multiple MCSs.
Use of SCSP directly between MCSs was discussed as a mechanism for
coordinating MCSs.  The consensus of the group that a second layer of
control was not advisable.  MCSs get their information from MARS, so the
information can be expected to be consistent.  The consensus of the
group was that the coordination function should be part of MARS.


- On the use of MARS and SCSP together

Grenville Armitage presented a draft on distributed MARS architectures
and SCSP (draft-armitage-ion-mars-scsp-00).  He presented a summary of
MARS concepts, a discussion of fault tolerant and load sharing
scenarios, and a discussion of open issues. Motivations for multiple
MARS include fault tolerance and load sharing.  For fault tolerance,
there are multiple MARSs, but only one is serving the entire Cluster
at any one time.  For load sharing, there are multiple MARSs
partitioning the Cluster between them.  The multiple MARSs in the load
sharing scenario doesn't necessarily provide fault tolerance.  Various
issues were raised:  How is the information between the MARSs
coordinated?  Where are cache synchronization protocols appropriate?

There was general consensus that load sharing and reduncancy should both
be addresses by a single mechanisms.  It was also generally agreed that
SCSP should be part of the solution, though the extent of its use was
not agreed.  Grenville will produce a new draft with a more concrete
proposal.

- Using the MARS model in non-ATM NBMA networks

Grenville Armitage presented a quick overview of his draft
(draft-armitage- ion-mars-nbma-00) on the applicability of the MARS
model to other NBMA networks.  No specific actions were requested from
the draft.  It was provided as material for supporting the new ion
charter.

- MARS MIB

Chris Chung presented the draft of the MARS MIB
(draft-ietf-ion-mars-mib-00) authored by himself and Maria Greene.
This draft is based on version 12 of the MARS specification.  A survey
was taken to see how many had implemented the IP- ATM MIB (8) and
the NHRP MIB (5). 

- Multicast Inscalability
 
Masataka Ohta presented his draft on multicast scaling issues
(draft-ietf- ohta-mcast-large-cloud-01).  The author pointed out that
NHRP may not be usable in some scenarios.  The group concluded that this
was orthogonal to the overall utility of NHRP.  The author was invited
to address these issues in the NHRP applicability statement.  In
addition, a future work item for this group would be to address the
scalability of multicast.

End of Minutes




======================================================================
George Swallow       Cisco Systems                   (508) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824