Subject: RE: more on reclaiming 225/8

From: "Dave Thaler" <[email-masked]>
Date: Fri, 6 Jul 2001 10:48:33 -0700

[moving mboned and iana to bcc list, follow up should be on the malloc list]

Beau is correct.  If the app wants a dynamic address, it should be using an
api/library provided by the platform for allocating dynamic
addresses.

The api (RFC 2771 provides the abstract version) should really be the same regardless of whether the app is asking for an SSM or ASM address, regardless of scope, etc (these can be parameters to the allocation request).  This insulates the app from the allocation protocol/mechanism.

If the semantics are appropriate (app wants ASM at Local Scope or
larger), then the library should use MADCAP to acquire the address.
And of course, SSM addresses should be allocated by the library/daemon such that they're guaranteed to be unique across multiple apps on the machine.  ASM groups of scope smaller than Local Scope (and a dynamic range for this type of groups is only presently reserved in IPv6) should be allocated by the library/daemon via ZMAAP.

We really don't want apps implementing MADCAP (or SAP, or ZMAAP, or SSM address allocation, or whatever else) themselves.  It's too easy for naïve app writers to mess up and/or collide with other apps on the same box.

If your platform of choice does not currently have such an api/library/daemon/whatever, go write one or beat on your platform vendor.

Dave Thaler

> -----Original Message-----
> From: Beau Williamson [mailto:[email-masked]]
> Sent: Thursday, July 05, 2001 2:13 PM
> To: Hugh LaMaster; [email-masked]
> Cc: John Meylor; David Meyer; Hugh LaMaster; Mboned List; Mark Handley;
> [email-masked]; Deborah Estrin; [email-masked]; Bill
> Fenner; [email-masked]; Randy Bush; Zaid Albanna; Kevin Almeroth;
> [email-masked]
> Subject: Re: more on reclaiming 225/8
> 
> Hugh,
> 
> Wouldn't this be better handled by having all applications use MADCAP to
> obtain the group address? After all, this is what that protocol was
> designed to do.  (If I remember correctly.)
> 
> Of course there is a problem if the application is a legacy application
> that doesn't support MADCAP and doesn't bother to request an group
> address.  How would you enforce certain policies concerning group address
> usage?
> 
> I have several customers that are wrestling with these sorts of issues
> (admission control, rate-limiting, address-allocation, etc.) and it
> doesn't appear that there are any standard ways to deal with these
> problems.
> 
> Beau
> At 03:22 PM 7/5/2001, Hugh LaMaster wrote:
> 
> >On Thu, 5 Jul 2001, David Meyer wrote:
> >
> >> >> > that specifically prescribes the correct thing to do
> >> >> > to a consumer product developer.
> >> >>
> >> >> perhaps this could be incorporated into something like Bob, Kevins:
> >> >> <draft-ietf-mboned-mcast-apps-02.txt> in section on address
> management.
> >>
> >> Good idea (as I said, it belongs somewhere, just not in the IANA
> >> guidelines).
> >
> >Sounds good to me also.  In fact, I see that the section on
> >address management actually does have this started:
> >
> >
> >   In almost all cases, application designers should assume that
> >   multicast addresses are to be dynamic.  Very little of the multicast
> >   address space is available for static assignment by IANA [MADDR].
> >   Also, given the host-specific addressing available with SSM, Internet-
> >   wide, static address assignment is expected to be very rare.
> >
> >
> >I think with a little more directness, e.g., drop a few qualifiers:
> >
> >   Application designers should assume that multicast addresses are
> >   to be dynamic.
> >
> >But, from this point on, I'm not sure what should be written.
> >Most of this document is written from the perspective of
> >streaming media servers/clients or the similar videoconferencing,
> >but, the applications that are causing the most trouble with MSDP
> >&etc. are things that don't fit that model - e.g. DriveImage.
> >
> >How *should* a non-interactive non-A/V mostly-local application
> >get its address (presumably in 239.255.x.y) and (port)?
> >Although sdr does work on the 239.x.y.z spaces by using
> >the appropriate multicast address, e.g., for 239.255.x.y,
> >239.255.255.255 for the SAP announcements, it isn't obvious
> >to me that a batch/CLI type application that might be run
> >automatically at a particular time fits the sdr/SAP model.
> >
> >I'm speculating that a query mechanism could be used, e.g., IGMPv3
> >general query, that would instantaneously return groups
> >to be avoided, and that the application could then randomly
> >select address and port, and then advertise via SAP
> >the selected group in 239.255/16.  Is that a bad idea (probably)?
> >
> >
> >--
> > Hugh LaMaster, M/S 233-21,    Email: [email-masked]
> > NASA Ames Research Center     Or:    [email-masked]
> > Moffett Field, CA 94035-1000  Or:    [email-masked]
> > Phone: 650/604-1056           Disc:  Unofficial, personal *opinion*.

---

From: Hugh LaMaster <[email-masked]>
Date: Mon, 9 Jul 2001 11:32:27 -0700 (PDT)

On Fri, 6 Jul 2001, Dave Thaler wrote:

> The api (RFC 2771 provides the abstract version) should really be the 
  same regardless of whether the app is asking for an SSM or ASM address,
  regardless of scope, etc (these can be parameters to the allocation
  request). This insulates the app from the allocation protocol/mechanism.
> And of course, SSM addresses should be allocated by the library/daemon 
  such that they're guaranteed to be unique across multiple apps on the
  machine.  ASM groups of scope smaller than Local Scope (and a dynamic range
  for this type of groups is only presently reserved in IPv6) should be
  allocated by the library/daemon via ZMAAP.
> 
> We really don't want apps implementing MADCAP (or SAP, or ZMAAP, or SSM 
  address allocation, or whatever else) themselves.  It's too easy for naïve
  app writers to mess up and/or collide with other apps on the same box.
> 
> If your platform of choice does not currently have such an 
  api/library/daemon/whatever, go write one or beat on your platform vendor.

I did look around a little bit over the weekend.  I found a little bit
of alpha-release stuff.  Maybe I missed the more fully developed stuff.
Is there a website or repository with code or pointers to code for
the RFC 2771 API conformant libraries and server daemons?  Have any
of the common (ie Mbone) tools (e.g. vic, vat, rat) been ported 
to use these libraries/facilities?  How about COTS software?  Sorry
if these are uninformed questions; I'm very out of date on what has
been happening and would like to get up to speed.

> > address.  How would you enforce certain policies concerning group address

My main concern is, what applications today are *not* legacy applications?