Subject: Draft minutes for MALLOC @ IETF 45

From: Steve Hanna <[email-masked]>
Date: Fri, 23 Jul 1999 13:12:35 -0400

Here are draft minutes for the MALLOC session at IETF 45. Please look
them over and get any comments back to me by 4 PM Monday, July 26.

Thanks to Bob Quinn for taking very thorough notes!

Thanks,

Steve

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

Minutes of MALLOC Working Group
IETF 45 (Oslo, Norway)
Thursday, July 15, 1999

Minutes reported by R. Quinn and S. Hanna.

Agenda:

Agenda Bashing                 Hanna
Introduction & Document Status Hanna
Architecture Document Update   Thaler
Static IPv4 Allocation         Meyer
Static IPv6 Allocation         Haberman
MASC Update                    Thaler
MADCAP Update                  Hanna
AAP Discussion                 Hanna
MALLOC MIB                     Thaler

I. Introduction and Document Status

Steve Hanna gave an overview of the MALLOC architecture.
Then he provided an update on MALLOC document status:

- Architecture doc: Recently updated and in WG discussion
- MADCAP doc:  In IESG Review (near completion)
- AAP doc: In WG Discussion
- MASC doc: In WG Discussion (recently updated)
- Scope Nesting doc: New revision coming soon
- Abstract API doc: In WG Last Call
- MALLOC MIB doc: In WG Discussion
- Static Allocation: moved out of MALLOC into MBONED

Most documents should be able to go to IESG by August. AAP will
probably be later. MIB will have to wait for AAP.

II. Architecture document update

Dave Thaler described the changes in the latest version of the MALLOC
architecture document (draft-ietf-malloc-arch-02.txt). The latest
draft is more abstract.  It removes focus on specific protocol details
(MADCAP, AAP and MASC) and now references roles, which can also apply
to alternative proposals (like static allocation). A party that
announces addresses available within a domain is now known as a
"prefix coordinator" instead of a "MASC server," for instance.

Also, Dave has proposed that "large" scopes (which contain multiple
allocation domains) now be called "divisible" and "small" scopes
(which have a single allocation domain) now be called "indivisible."
This idea was received with mixed emotions.

Dave proposed a 2 week working group last call for this document
beginning July 23. There was general agreement.

III. IPv4 Static Allocation

Dave Meyer described the current status of the IPv4 multicast address
static
allocation method described in
draft-ietf-mboned-static-allocation-00.txt.

The IANA just assigned the reserved multicast address range 233/8 for
this proposal. These addresses are already being used by many ISPs.

There are many calculators available for converting an AS number into
static multicast address assignments and vice versa. See
http://gigapop.uoregon.edu/glop

Mark Handley asked how the MALLOC architecture would handle an AS (with
a static allocation) that is larger than an allocation domain. It was
agreed that you could use MASC or static configuration to break up the
static allocation across multiple allocation domains. Mark agreed to
help Dave Thaler add this to the Architecture document.

IV. Allocation of Multicast Addresses in IPv6

Brian Haberman described the IPv6 multicast address static allocation
scheme described in draft-haberman-malloc-static-ipv6-alloc-00.txt.

An IPv6 multicast address contains a 16 bit prefix (with flags, scope,
etc.) and a 112 bit group ID. An IPv6 unicast address contains a 64
bit network prefix and a 64 bit interface ID. The proposal is to
statically allocate IPv6 multicast addresses to network prefixes by
putting the unicast network prefix at the top of the group ID. This
will provide 2^48 groups for each scope, prefix pair.

A concern was raised about how often IPv6 unicast network prefixes
might change (due to renumbering). If they change too often, this
could cause problems for this scheme. The answer was that each prefix
has a lifetime and an orderly transition should be done, with several
weeks during which the old prefix is deprecated and the new one
preferred. This should be OK.

One open issue is how best to map IPv6 multicast addresses onto
Ethernet multicast addresses. RFC 2373 to use only the low 32 bits of
the group ID. It would probably be better to include more bits.

Another open issue is which working group this draft should be
in. ipng? malloc? This will be discussed with the ADs.

V. MASC Update

This presentation was prepared by Pavlin Radoslavov. However, Pavlin
could not attend so Dave Thaler actually gave the presentation.

A new MASC draft was posted today. This draft should be ready for
working group Last Call by the end of July and will then be submitted
to the IESG for publication as an Experimental RFC.

This draft includes several bug fixes and other changes in light of
Pavlin's implementation experience and suggestions from others. Here
is a description of some of the most important changes:

Bootup Operation
  When a MASC server comes up, it should establish the TCP connection
  to its parents before its siblings or children. This helps avoid
  the node learning about its own PREFIX_MANAGED from its siblings or
  children.

Leaf vs. Non-Leaf MASC Domains
  Leaf and non-leaf MASC domains must behave differently. Leaf domains
  must advertise all addresses to their own allocation domain.
  Non-leaf domains must save some for themselves and leave others for
  their children.

Clock Skew Work-around
  Clock skew can cause problems with MASC. However, these problems can
  be avoided. First, timestamps are used to resolve claim collisions.
  Clock skew may result in one node's claims winning unfairly. But
  this should be rare and is not a big problem. More problematic is
  the possibility that clock skew may cause claims to be expired
  prematurely. To avoid this problem, all claims should be held for an
  extra 24 hours. And claims with clock skew approaching 24 hours
  should be rejected with an error.

Security Considerations
  When attempting to restore internal state after a reboot,
  information received from internal peers and parents should be
  preferred to information received from siblings or children. This
  prevents siblings or children from providing false state.

  A denial of service attack (too many collisions) by a single node
  can be identified by all its siblings, who can ignore that node's
  claims. A similar attack with multiple origin addresses can be
  prevented by accepting claims only through the parent.

Sample Algorithms Appendix
  Many simulations that have been performed are described.

An open issue was discussed. Currently, siblings with more than one
common parent can multiplex all UPDATEs over a single TCP connection. 
This is too complicated and provides a negligible savings of a few TCP
connections. Pavlin suggests opening a new TCP connection for each
common pairing. There was general agreement that this sounded like a
good idea.

Dave Thaler asked whether separate port numbers would be needed for
these connections. He will send email to Pavlin.

MASC Implementation Status

Pavlin has implemented MASC and performed detailed testing, refining,
and bug fixing of MASC processing code through simulations. He has
also added QUERY/RESPONSE debug messages for debugging. The question
arose as to whether these messages should be added to an appendix of
the MASC spec. After some discussion, it was agreed that either a MASC
MIB should be defined or the messages should be documented.

Pavlin is also working on implementing and testing the MASC-AAP
interface. It would be helpful to him if someone who already has
a MADCAP/AAP implementation could volunteer to do some testing with
him. Nobody came forward.

Deborah Estrin said that Pavlin has lots of experimental and
simulation results. He will publish an Internet Draft on these.

VI. MADCAP Update

Steve Hanna described the current status of MADCAP.
draft-ietf-malloc-madcap-04.txt went to the IESG in March. Since then,
several rounds of comments have been received from the ADs. Draft -05
was published in May and draft -06 should be published very soon.
After that, the spec should go to Proposed Standard status.

The changes in -05 included:
- adding an overview and glossary
- INFORM now MUST include Option Request List
- adding an Error option for NAK

Draft -06 will include minor clarifications. Also, the INFORM message
will be renamed to GETINFO.

VII. AAP Discussion

Steve Hanna led a discussion of the AAP protocol. He started off with
a protocol overview, then a status update, and finally a discussion of
open issues.

AAP is designed to fit into the middle tier in three-tier MALLOC
architecture (intradomain). It will be used by prefix coordinators to
announce addresses available for allocation and by Multicast Address
Allocation Servers (MAAS's) to coordinate and ensure that allocations
do not conflict.

All messages are UDP multicast to scope-relative addresses (in the
Allocation Scope for "large" scopes, in the scope being allocated from
for "small" scopes).

The AAP spec was written by Mark Handley last year. It was based on
SAP (the Session Announcement Protocol). Steve Hanna joined as a
co-author in March, with high hopes to resolve open issues quickly and
move to Last Call by August. However, other things have intervened and
little progress has been made as of yet. The last "working draft" has
been converted to ASCII and published as draft-ietf-malloc-aap-01.txt
in June. Steve is now aiming to for Last Call in December.

The protocol overview has been omitted here. See the protocol
specification for details.

The first open issue was whether to add failover support to AAP. In
this context, failover means the ability for one MAAS to take over
seamlessly if another one fails (able to renew leases issued by the
failed MAAS, etc.). Implementing failover would introduce a lot more
complexity: sending per-lease information to backup servers, detecting
server failure or network partition, backing off to a safe mode, and
resynchronizing to recover.

It was generally agreed that we should wait on this for now and just
get out a simple AAP spec and get some experience with that.
Implementors can use proprietary protocols or other means to address
this for now. And we can develop a standard protocol for it later, if
need be. This is similar to what the dhc working group did with DHCP.

The second open issue was whether to add support for MADCAP Server
Mobility to AAP. We aren't sure how to do this at this point without
introducing lots of complexity (like failover). We agreed to think
about this for a few weeks. If we can't come up with a reasonably
simple solution, we'll punt on it for now.

VIII. MALLOC MIB

Dave Thaler talked about the MALLOC MIB (draft-ietf-malloc-mib-01.txt).
The initial MIB instrumented generic MAAS and objects. The WG
consensus was that protocol-specific objects should be in the same
document, so the MIB was updated in June.

It now contains several different conformance groups that different
entities will implement depending on which protocols they speak:

mallocBasic: all entities
mallocClient: clients
mallocClientScope: clients (optional)
madcapClient: clients that speak MADCAP
mallocServer: MAASs
madcapServer: MAASs that speak MADCAP
aapServer: MAASs that speak AAP
aapKeyServer: AAP key advertisers
aapRangeServer: Prefix coordinators that speak AAP

The MADCAP-specific groups contain various MADCAP config options as
specified in MADCAP spec, as well as counters for each error type and
counters for each packet type.

The AAP-specific groups contain various AAP config options as
specified in the AAP spec, as well as a write-only private key
configuration entry with appropriate precautions, a read-only public
key table, and a trap for when you stop hearing ASA messages.

This draft also includes a few other changes. The scope table has been
split onto a scope table and an allocation range table to support
divisible ("large") scope better. And IPv6 support has been added by
making address objects generic.

The MIB should wait for all the protocol specs to go Proposed
Standard. This means it will need to wait for AAP. However, the
protocol documents don't need to wait for the MIB.

Brian Haberman asked whether this MIB should use the generic object
for IPv4/IPv6 address representation in MIBs that is being developed.
Dave said that if this object is done soon enough, we'll use it.
Otherwise, we will move ahead with the current proposal.