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]
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 A 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.
Open issues:
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.
MASC functions:
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.
Conclusions:
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:
Questions
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.
III. AAP Status
IV. MASC Implementation & Status
Stable Storage format
V. Static Allocation in the 226/8 Address Range
VI. MALLOC MIB
VII. Charter/Milestones Update
Slides