Minutes of MALLOC Working Group IETF 44 (Minneapolis, MN) Tuesday, March 16, 1999 Minutes reported by S. Casner and S. Hanna. Agenda: Agenda Bashing Thaler MADCAP Update Hanna Scope Nesting Kermode AAP Update Hanna MASC Status Radoslavov Static Allocation Meyer MALLOC MIB Thaler Milestone Update Thaler I. MADCAP Update MADCAP was pretty well settled at last IETF, so it has gone to WG last call in January and IETF last call last week. Soon expected to be published as Proposed Standard. Abstract API update: The draft is unchanged since November, but Ross commits to revising the draft to reflect changes in MADCAP by next month. The revised draft is to go to last call after next IETF. II. MADCAP Scope Nesting Option Problem: TTL scoping doesn't work for large scopes. We go to admin scoping to solve this, but then we need to be able to do nesting of scopes to have the same expanding ring effect that TTLs provided. To do nested scopes, need three protocols: MZAP, this proposal, and SADP. MADCAP lists the scopes enclosing a given point, but doesn't provide nesting info. A pair of scopes A and B may have the relationship A<B, B<A, A<>B, or A=B. Listing all the pairwise combinations is too long. The list is sparse because not all scopes will nest, so we could do some sort of list of pairs, a dense matrix, or a sparse matrix (list of lists). To keep things simple, and based on the assumption that the number of scopes is O(10), the proposal is to use a dense binary matrix representation with the diagonal deleted and padded to an even byte boundary per row. The bit string is 1 wherever the scope corresponding to the row element is nested in the scope represented by the column. Consensus was that this should become a working group document headed for Proposed Standard. III. AAP Status AAP is an intradomain address allocation protocol that works via periodic announcements, based on SAP. It is used be MADCAP servers (and others) to communicate within a domain. The original draft was by Mark Handley. Steve Hanna is joining now as a co-author to help move it forward to last call by August. Open issues: - Need IPv6 support (MADCAP has it) - Want to be able to represent allocated addresses as ranges to reduce message size; currently have to list addresses individually, and we expect them to be allocated and used in blocks. - Need signature format; there are some ideas but no strong candidates yet. - Need server mobility, like DHCP failover. MADCAP uses a secret representing allocation ownership to prevent someone else taking action on the allocation. How to communicate these secrets from the server that does the allocation to the backup servers? Use a cryptographic hash of client ID so it can be communicated in the clear. Mark Handley raised the issue that the client identifier may not have cryptographic randomness, so it may be possible to search the client id space to find one that matches the hash. - Use MADCAP message format for AAP? This would allow more shared code. On the other hand, the functions are different, so code savings might not be large. Handley: This might cause confusion. Even though the syntax of the messages would be the same for MADCAP and AAP, the semantics are totally different. Thaler: MADCAP has an extensible options-based format, which is convenient. - Shall we change the name of AAP? The relationship to MADCAP is not obvious, and the server-to-server nature is not obvious. Hanna has not heard a name he likes better yet. Take this to the list for suggestions. Want to resolve in next few weeks. IV. MASC Implementation & Status MASC functions: 1. Associate group ranges with AS's, hierarchically allocated from parents to children. 2. Announce group ranges to MADCAP servers using AAP. To implement a MASC server, MUST implement MASC protocol and part of AAP (the part that handles announcement of addresses). SHOULD also implment MZAP. Overview of the implementation design: three layers - communication upward with parent domain via MASC - my own domain (state mainenance) - communication with child domain via MASC, also AAP to the local domain Working on implementation as a stand-alone server. MASC protocol is done, AAP and MZAP not yet. 30% of 10000 lines is MASC. TODO: MASC QUERY and RESPONSE debug msgs. Why not just use SNMP? It's faster and easier to implement MASC's own messages; could do both. Thaler - More important than faster and easier is that you can get an answer from more remote domains, as mrinfo can do for multicast routers. SNMP is better for looking at nodes in one's own domain. Pavlin says, yes, we do want to have access to other domains, especially for debugging. This access can be turned off when desired. Maybe these messages should be in a separate draft as a feature to use only during debugging stage. Needs to do testing, and implement AAP, MZAP. Stable Storage format MASC will run on BG(M)P routers that in general do not have stable storage. A reboot of one node is not a problem because info can be restored from other nodes so long as you trust your neighbors with your internal state; but if all reboot at once, info is lost. Another solution is to use AAP to store internal state on a MADCAP server that does have a disk. This is more complicated, and can record only part of the information that MASC has (PREFIX_IN_USE and allocated-by-madcap addresses). Handley: This doesn't complicate AAP because it needs this info anyway. Third solution is to run at least one diskful MASC node, maybe in a non-router. But this has a configuration problem: normally MASC peering of the routers is implicit in BG(M)P peering; adding a non-router requires configuration. Can solve this with UDP multicast of MASC OPEN messages from the diskful server; then each MASC router establishes a TCP connecion back to the diskful node. Handley: There is a problem with this because there could be a conflict between what one learns from AAP and from MASC peers. Those need to be consistent. Thinks that MASC should solve this problem, rather than pushing it to AAP. The info is signed from MASC to AAP, and the same info is returned, so it should not get messed up unless one lies to oneself. Not strongly in favor of one solution or other, but we should figure out one way to do it. Having two different implementations may still work, but there is the possibility of confusion about the architecture. Thaler: Issue if aap servers also reboot at same time? May need more discussion on the list. V. Static Allocation in the 226/8 Address Range At MADDOGS meeting in Dallas at end of February, address allocation was discussed among several other topics. Dave has begun to question the assumption that there is not a lot of IPv4 multicast space. When broadcast.com said they needed a lot of addresses, they meant 1000. Yet the space is 256 million. So, there was a proposal from Peter Lothberg to get an experimental allocation of 226/8, using AS number as middle 16 bits and thereby allocating a /24 to each AS. Subsequently, Dave decided the space could be used more efficiently since not al AS's will need the same allocation of space. Lothberg figured this didn't matter because this is a test of the MADCAP and AAP mechanisms, not a real test of allocation. Meyer proposes using a similar philosophy to 225/8, where that is for an experiment with dynamic allocation and 226/8 is an experiment with static allocation. Is there really a near-to-immediate term shortage? Stipulate all the advantages of dynamic assignment; this is not questioned, but it is basicaly optimal packing/aggregation. Handley: Problem of static allocation is fragmentation over time. Suggests using a /8 adjacent to the 232/8 (which was allocated to VMTP and is now used for Express) so that 225/8 can be allowed to grow upward if it is successful, and 239/8 can grow downward if needed. Note this uses all of the mechanism of allocation except MASC (that is, AAP and MADCAP). The proposal is to reserve bit 8 to avoid consuming all of this allocation at once. Let the registries work out allocation of the remaining space; the issues are the same as they have done for unicast addresses. Perhaps because of route scaling problems there won't be a very large number of small groups (use multiple unicasts instead), so maybe we don't need as many addresses as thought. Conclusions: - Want to know if registry is useful as allocation mechanism - Want to enable the entities that need addresses right away - Works with AAP and MADCAP - 226/8 is and experiment along the lines of RFC1797 and RFC2374 - Proposes to ask IANA for allocation - What to do with the document? (Work item of MALLOC or MBONED?) Casner: Need to have a lifetime on those registrations, otherwise it will be too hard to get them back. Handley: Agrees. The allocations should be explicitly timed using the mechanisms of AAP and MADCAP. Thaler: This is important so that we can get all the lower protocols exercised. Munil Shah's implementation of the MADCAP server will require a lifetime to be entered on ranges that are manually configured into the server. Also, on AS numbers versus the registry plan: the motivation for AS idea is no politics. Proposes that the part of space with bit 8 clear should follow Lothberg's original AS plan. This makes it very easy for debugging to see the AS number in the middle. Note that debugging of multicast is hard, so this has some value. Meyer: Yes, this would get it off the ground right away, but provide a backup mechanism through registry to get more if the AS allocation was not sufficient. Handley: The AS mechanism is good because it doesn't start down the slippery slope of manual allocation. Williamson: Why not ask IANA for two /8's? Meyer: No, we don't need that much space. Thaler: Don't want to have to ask IANA for two. We already got 225/8, and we don't want to seem like we don't know what we're doing. Meyer: Doesn't like sharing between AS and registry allocation because of the posibility that AS's may be allocated in the high half. Thaler: Want WG consensus on whether this should be a MALLOC document. Otherwise it might go to mboned, which might seem like competition and conflict between working groups. Meyer: MALLOC is where the allocation experience is. Kermode: Agrees it should be here; needs to be carefully labeled as an experiment. Consensus was that this should become a MALLOC WG doc. Meyer: Will repost with AS idea becoming more a part of it, but with some flexibility. Handley: Experimental status is for protocols; maybe this should be BCP? Several people disagreed. BCP indicates it is a best practice, which this is not. Consensus was for experimental status. VI. MALLOC MIB Report on comments since the January draft. The goal is to be able to configure the multicast address allocation servers, and monitor health and utilization of clients and servers. Two functions: Configuration -- Need to be able to manually configure scopes until routers begin using MZAP: - list of scopes (ranges, lifetimes) - names of scopes Monitoring -- What questions do we want to be able to ask? - how full is a scope - who's using it - who has particular addresses - are requests being met These goals drive the design of the MIB. Open question for the working group is whether there should be one MIB or multiple MIBs: A MAAS server has both MADCAP and AAP interacting with the database; should the MIB deal with configuration functions, MADCAP, and AAP separately? There are some protocol-specific queries one might make, e.g., how many requests of a specific type. Does anyone have opinions on this philosophical question of MIB design? Current design doesn't do protocol specific functions and concentrates on the database and configuration, all one MIB. Review of the MIB design: - A few scalars for configuration - Scope table which tracks address blocks and their states; need to add flags from MZAP messages, and stats on protocol specific messages to know how the MADCAP and AAP protocols are behaving. - Scope name table: scope, language, name Needs change to make "default" boolean be flags to allow expansion for other flags. - Request table: scope, lease id, start/stop times, # addresses, state, who requested. Allows easily answering "who's using up the space?" - Address block table: lease id, first address and number of addresses Allows easily answering "who allocated address x.x.x.x?" Maps back into the request table via lease id. Questions - Are we able to configure everything we need to? Note that implementation specific configuration doesn't belong in MIB. - Are there other diagnostic questions we will want to ask? Kermode: Want to be able to query to find out the scope nesting, i.e., what relationships between scopes. This was noted. Also feels one MIB is right. VII. Charter/Milestones Update We are approaching the end of the existing milestone timeline in April, so we need to update it: Architectural framework update to be moved to Apr 99. The next few milestones are done. Since MIB was later than its original date of Oct 98, its Apr 99 milestone moves to Aug 99. Abstract API changes from Jan to August for going to IESG. ISP's are less sure about top levels of the MALLOC architecture than lower layers, so maybe the architecture doc should talk about top level being experimental. Want architecture doc to go to IESG by August also. AAP also August. Change inter-domain protocol (MASC) to experimental, and take Meyer's proposal to experimental also, in parallel. General agreement with this course of action. MASC MIB: if experimental, may not need to be a WG work item. So, presented list of revised milestones. Several docs to be updated in April. At Oslo, nail down intra- and inter-domain protocols (latter as experimental). August submit all the rest of the documents. Hanna: any of these that are ready sooner will go sooner. No objections, will be sent to ADs.