Subject: Draft malloc minutes from IETF 42

From: Steve Hanna <[email-masked]>
Date: Wed, 9 Sep 1998 15:24:18 -0400 (EDT)

Here is a draft set of minutes for the malloc session at IETF 42. Please send 
comments to me or to the list by Friday, August 11, 1998 noon EDT. The final 
version of the minutes are due at the secretariat by Friday 5:00 PM EDT.

Thanks,

Steve Hanna

-------------

Minutes of MALLOC Working Group
IETF 42 (Chicago, IL)
Tuesday, August 25, 1998

Minutes reported by M. Smirnov and S. Hanna.

Agenda:

Agenda Bashing       Hanna
Introduction         Hanna
MASC                 Radoslavov
AAP                  Handley
MDHCP                Hanna
MZAP                 Thaler
Advance Allocation   Thaler

This is the first meeting of MALLOC as an IETF working group.

I. Agenda and Introduction

Steve Hanna presented the agenda and started with the introduction, 
which covered an overview of the MALLOC architecture with 3 levels and
subsequent protocols: MASC for interdomain, AAP for intradomain and 
MDHCP for host-client interactions for multicast address allocation. 
The introduction was concluded with the overview of the status of MALLOC 
documents: architecture needs minor revisions (see later in minutes);
MASC, AAP, MDHCP and MALLOC API have been recently updated, however 
some open issues do exist.

II. MASC

Pavlin Radoslavov gave a detailed overview of MASC according to 
draft-ietf-malloc-masc-01.txt. Pavlin presented the goals, claim-collide 
mechanism, MASC topology with possibly multiple relations (parent:child, 
sibling:sibling, internal:peer) in it. He underlined that there is 
no requirement for a strict hierarchy, the MASC topology is following 
unicast topology. A sample topology was introduced. MASC update messages 
were presented with their formats and processing rules. The following issues 
were also addressed: claims comparison function, expanding/renewing the 
prefix (via reclaim in advance), releasing (via timestamp mechanism). 
Clash example based on the previously introduced example of MASC topology 
was presented, as well as issues of dealing with zones and changing the network
provider. It was noted that MASC storage must keep only local domain 
allocations.

In the following discussion it was proposed to start with a smaller
range of addresses managed by MASC while asking IANA to keep the rest
of the whole range being unassigned. There was a consensus that
address ranges should not be mentioned in the document while the TCP
port number should be retained. It was also suggested and generally
accepted to move to a 32 bit MASC domain ID. 

III. AAP

Mark Handley presented the new release of AAP: explanation was improved, 
terminology (MASC router, MAAService, AAP node) was added; however there 
is no IPv6 yet in the draft. The architecture permits every node to be a 
server, all AAP messages are multicast. Six AAP messages are ASA, SSIG, ACLM,
AITU, AU, ASRP. There is no explicit Address Deletion message now while it 
is believed that timing mechanisms will do the job. Mark has noted a 
number of open issues and possibilities for improvements: server signature
(SSIG) could be designed better, it is not clear whether address prefixes 
(in ASA - Address set Announce) should be prefixes, masks or ranges, AAP
tunnelling (with a proxy MAAS in a previous domain).

The AAP discussion addressed the following questions. How many address
sets would usually be included in an ASA (Address Set Announce)
message? This depends on the behavior of the MASC server sending the
message. Currently, we expect that such servers would manage their
addresses in such a way that the number of address sets in an ASA
message would be one or two.

Two new messages - Address Claim (ACLM) and Address Intent To Use
(AITU) - are serving in principle the same purpose. Which one should
be used would be based on a server load (busy server or quiet
server). The document assumes that the decision on whether a server is
a busy or a quiet one is a local decision and should be kept for
implementation. Dave Thaler suggested that AITU is better anyway.

The requirement in the current draft for AAP servers to have stable
storage should be understood in such a way that if, e.g. a router 
has a stable storage then this router could serve as a MAAS.

A question on ASRP (Address Space Report): How does a MASC router know
when it's time to decrease the allocation of addresses in a domain?
By the absence of reports.

The opinion was expressed that the absense of explicit
deletion in AAP is questionable. While it could be considered an
application side issue (which also could be linked with the
pre-allocation), the abstract API document has ADEL spec in it.

IV. MDHCP

Steve Hanna presented MDHCP update. It is based on DHCP design principles
but is not dependent on it. A server discovery is based on multicast, 
which should cause no problem. Changes in the current draft are made in 
such a way that now it is completely separate from the DHCP 
protocol, has a separate port number. 

However, sharing of an options number space with DHCP might be
dangerous, therefore the DHCP WG approval is needed to avoid
collisions between the two. One of the open issues is which scope(s)
to use for server discovery. There was a discussion also on a
motivation for support of MDHCP servers that provide services for
scopes they're not in, on language issues which are still to be
addressed, on a desire to remove unused fields from the MDHCP header,
on a transition plan from a current practice to a MALLOC architecture,
and on the necessity to support whatever policies might be introduced
in the area.

Steve Hanna stated that the next steps are to resolve open issues and
to go for the last call for the MDHCP. The timeframe for this was
stated as "a few months".

V. MZAP

Dave Thaler described how MZAP (Multicast-scope Zone Announcement
Protocol) fits into the malloc architecture, especially in
distributing scope zone information.

It was noted that possible confusions with textual names should be
resolved by boundary routers. The multicast scope is considered to be
small or big. For small scopes, MASC is not used and AAP uses
scope-relative addresses for communication. For large scopes, MASC is
used and AAP uses a single multicast address for
communication. Recommended is well-known allocation domain scope. With 
regard to this, the MALLOC architecture document needs to be
updated. Marc Handley pointed out that it is not clear what to do with
this, i.e. how to use big and small scopes: contributions are welcome.

VI. Advance Allocation

Dave Thaler presented then the issue of advance allocation as a summary of 
mailing list discussion: motivation for pre-allocation and steps in
pre-allocation. The steps are: pre-allocation with return of (granted
| trying | denied); advertisement with, say,  0.0.0.0 in place of
requested address; allocation (in case of "trying"); possibly
(another) usage until the start time. The maximum usage time of the
addresses is an administrative decision.

Effects on other documents are as follows: abstract API and MDHCP need
to include "trying" result and way to fetch address later; AAP and
MASC need no changes.

Michael Smirnov pointed that shortly before the 42nd IETF a new draft 
(draft-phillips-malloc-util-00.txt) has been submitted with motivation for 
proactive pre-allocation. It was decided to resubmit this draft for a 
discussion on the mailing list.