Subject: MALLOC minutes

From: Dave Thaler <[email-masked]>
Date: Mon, 17 Apr 2000 19:27:18 -0700 (PDT)

Multicast Address Allocation WG (malloc)

Thursday, March 30 at 0900-1130
===============================

CHAIRS: Dave Thaler <[email-masked]>
        Steve Hanna <[email-masked]>

AGENDA:

Agenda Bashing

Introduction and Document Status   Dave Thaler       (5 minutes)

AAP Updates:                       Mark Handley      (30 minutes)
   draft-ietf-malloc-aap-03.txt

MALLOC MIB Update:                 Dave Thaler       (10 minutes)
   draft-ietf-malloc-mib

IPv6 Multicast Address Allocation: Brian Haberman    (5 minutes)
   draft-haberman-malloc-ipv6-prefix-00.txt
   draft-haberman-ipngwg-mcast-arch-00.txt

<Discussion on scoped source-specific groups added to end of agenda>
----------------------------------------------------------------------

Document Status
----------------
Two RFCs were published since the last meeting:
  MADCAP is now RFC 2730 (Proposed Standard)
  Abstract API is now RFC 2771 (Informational)

Three documents were sent to IESG since last meeting:
  Architecure Document (submitted for Informational)
  MADCAP Scope Nesting Option (submitted for Proposed Standard)
  MASC (submitted for Experimental)

Other WG Documents remaining:
   AAP
   MIB (blocked on AAP)

AAP Updates: Mark Handley
draft-ietf-malloc-aap-03.txt
----------------------------

lots of changes in 02
only explanation changes in 03

changes from 02 - 03
  - Scaling Analysis (section 6) added: some errors, needs to be revised again
  - Reccomendation that hosts use MADCAP instead of AAP
    if a MADCAP server is available
  - Added discussion of allocation conflicts
    Beau Williamson asked: include text on how apps should deal with shifting 
       addresses within a session?  E.g. when we have an allocation conflict
    Dave Thaler responded: Not in AAP, this is part of session advertisements, 
       this is something that is explained in the architecture document.
  - Added examples (Appendix A)
  - Noted reserved port number: 2878
  - Removed Appendix D (Unresolved Issues)

recap from 01 - 02
1)
  - Originally AAP assumed that could be large numbers of
    AAP speakers in a domain. e.g. sdr might speak AAP
  - this no longer the intent
  - can now use simpler algorithm for defending addresses
    * use unform random backoff, not exponential random backoff
  - aim is for approx 2-10 AAP speakers in a domain, with
    1000 being the upper bound
2) Security mechanim
  - Use IPSec AH instead of custom authentication
  - Currently only use manual keying with a group-shared key
  - SMuG is working on group-keying mechanisms for later on

What's next
  3/00 Currently in WG last Call
  4/00 Send to IESG, IETF Last Call
  5/000? IESG approves as Proposed Standard

other docs will be discussed in zeroconf or mboned as approriate

MALLOC MIB Update: Dave Thaler
draft-ietf-malloc-mib-02.txt
----------------------------
RFC2465
 - defines IPv6Address type
 - IPv6-specific MIBs can use this
draft-ops-endpoint-mib-07.txt
 - defines protocol-independent InetAddress type
 - should be RFC soon
 - protocol-independent MIBs should use this

Changes to the MALLOC MIB
 - IPv6 support now uses standard InetAddress types
 - Updated MIB Boilerplate text
 - Language names now use Language Tag type defined in Multicast MIB
 - Added Guid type to identify leases
 - Reading key now MUST return empty string (was MAY)
   (Thanks to Lars Viklund for reviewing this MIB)

ToDo
 - Prefix coordinator config
   * Has interval but not ranges to advertise
 - Security
   * currently has old "public key" objects

IPv6 Multicast Address Allocation: Brian Haberman
draft-haberman-ipngwg-mcast-arch-00.txt
---------------------------------------
presented in IPNG WG

Objectives
- - Simplify IPv6 multicast address allocation
- - Aid in debugging IPv6 multicast networks
- - Single-source IPv6 multicast

Architecture change proposal
- - borrow the idea from GLOP, but include the network
    prefix of the allocation domain in the mcast address
- - can do this as only the bottom 32 bits actually get used

  +---------+-----+----------------+----------+
  | prefix  | len | unicast prefix | group id |
  +---------+-----+----------------+----------+
   prefix is the multicast prefix to be reserved for this purpose
   len is length of unicast prefix

Multicast Debugging
- - Who owns the multicast address
- - Who allocated the multicast address

Single-Source Multicast
- - set "unicast prefix" to 0/0

This doc will been adopted as a WG document by the IPNG WG

IPv6 Multicast Allocation Guidelines: Brian Haberman
draft-haberman-malloc-ipv6-prefix-00.txt
----------------------------------------

- - short document that describes guidelines for MAAS's for generating 
    the low 32-bits of multicast addresses so as to avoid layer-2
    clashes.
- - use pseudo-random address, avoiding group IDs reserved by IANA
    for the All-hosts, All-routers, etc groups.
- - should this be a malloc WG doc?

Thaler: must make explicit assumption that allocation
  of unicast implies allocation of multicast prefix as
  well.

There are content provides who would like to use scope
to construct borders around countries etc. Is there
enough richness there to allow these things?

Thaler: out of scope this WG is about allocation
Haberman: new IAB doc on scoped address architecture
Thaler: current IPv6 draft says that scopes must nest,
  can't define "arbitrary" ones unless they nest.
Handley: arbitrary scopes are hard to do beacuse they
  must be convex...you will create black holes

Handley: yes, this should be a malloc WG doc, it should
  probably be "proposed"

239 vs 232 Discussion
----------------------
Q: What addresses should be used for IPv4 source-specific, scoped groups?
A 1) is to take one piece of the 232 range and divide it up for
     scoping things. Arg is don't do this as it makes advertising
     and filtering more difficult.

  2) is to take a piece of each 239 subrange and make it source-specific.
     Arg is 239 is set aside as being scopable but not as source-specific.
     This can expand downwards into 238, though.

  3) take 238 and carve it up just like 239, and distribution is
     the same.  So MZAP announcement for (say) 239.192/16 implies
     that 238.192/16 is a source-specific range with the same
     distribution scope.  This is much closer to the IPv6 proposal
     discussed earlier, where a single bit in the address can identify
     (independent of scope) whether the address is source-specific or not.

Casner: just let certain scopes in 239 be used as SSM
Holbrook: if we make the 232 range dynamic, then routers do
   become the MZAP servers?
Handley/Casner: we need to keep 232 clean.  If we put structure
   in then we will run into allocaiton conflicts at scope
   boundaries.
Handley: we could use MZAP to indicate SS range within 239,
   this would require that ALL routers that could have local hosts
   listen to MZAP in this range.
Thaler: If you're running IGMP then you could have local hosts.
   The argument for 238 is that routers can filter on all of 238.
Casner: my main concern with 238 is fragmentation

email list: [email-masked]

Actions:
1) Roger Kermode to resubmit MADCAP Nesting State Option Draft
   to IESG after incorporating comments from ADs
2) Mark Handley to fix scaling analysis in AAP draft and resubmit
   for WG last call
3) Brian Haberman to generate new document for immediate WG last call
4) Dave Thaler to generate new MIB and resubmit for WG last call

Thanks to Roger Kermode for taking minutes.