Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/ion/ion-minutes-96jun.txt

Text File | 1996-10-07 | 15KB | 304 lines

Editor's note:  These minutes have not been edited.



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
([e-mail]) and George Swallow ([e-mail]). 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, with draft-talpade-ion-
marsmcs-00 forming the base of this work. The second draft describes
the more general multiple MCS mechanism for fault-tolerance and load
sharing using MARS, and is the subject of ongoing research.

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