Minutes reported by S. Casner and S. Hanna.
Agenda Bashing [Thaler]
MADCAP Update [Hanna]
Scope Nesting [Kermode]
AAP Update [Hanna]
MASC Status [Radoslavov]
Static Allocation [Meyer]
MALLOC MIB [Thaler]
Milestone Update [Thaler]
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.
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 AB, 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.
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.
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.
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.
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
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.
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.
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.
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.
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:
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:
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.
We are approaching the end of the existing milestone timeline in April, so we need to update it:
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.
MASC Stable Storage