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.