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.
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.
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.
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 absence 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.
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".
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.
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.