Subject: draft MALLOC minutes

From: Steve Hanna <[email-masked]>
Date: Wed, 31 Mar 1999 15:32:57 -0500

Here is a draft of the minutes for the MALLOC meeting at IETF 44. Please
get comments back to the list by Friday morning, since that's the
deadline for submitting minutes to the proceedings.

I apologize for taking so long to get these out. The fault is entirely
mine. Steve Casner got the minutes to me promptly, but I've been very
busy.

Thanks,

Steve

------------

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.