Subject: Re: more on reclaiming 225/8

From: David Meyer <[email-masked]>
Date: Fri, 6 Jul 2001 15:16:00 -0700

Mark,

>> The point of the allocation was to experiment with whatever address
>> allocation mechanism the IETF MALLOC group decides on.  We definitely
>> seem to be lacking consensus on deploying MASC, so the question is can
>> the MALLOC working group achieve consensus as to an alternative?

As I remember it (and I was asked to intervene with the IANA,
which I gladly did), the assignment  was to experiment with
MASC. More precisely, since we couldn't expect the top level of
the MASC hierarchy to be deployed (or the BRIB for that matter),
we were going to make static assignments and have something like
a host file that we shipped around. 

>> If we have consensus on a replacement for MASC, then it makes sense to
>> me to use 225/8 to experiment with that replacement.  If we don't
>> agree on a replacement, then we should return 225/8 until such time as
>> there's some general agreement.

The issue is whether 225/8 is ours to do with what we want. My
assertion is that is not. The assignment was temporary, and for
the purpose I described above. If we want more addressing, we can
ask IANA for that, but just to use it for whatever we want
implies some sense of ownership, and that is what I'm objecting
to (another case: I didn't agree with the way 232/8 was handled,
for similar reasons). Add to that the a /8 is a huge chunk of
address space.  

>> Can we decide this on the list, or do we need to discuss it in London?

The list certainly has a larger constituency than what we will
find in London. However, what do we need to decide? You need
addressing for this new experiment. That's fine, write a
document, then ask the IANA.

Again, I am not objecting to the experiment, or to the fact that
you need addressing to do it. What I am not comfortable with is
treating 225/8 like we own it and it is ours to do with what we
please. That is not the case. 

Dave
----
Humorous aside: looks like its expired anyway:

http://www.iana.org/assignments/multicast-addresses -->

225.0.0.0-225.255.255.255  MALLOC (temp - renew 1/01)    [Handley]

---

From: Mark Handley <[email-masked]>
Date: Fri, 06 Jul 2001 15:36:51 -0700

>the purpose I described above.

I've included the text of my original request message from Dec 1998
below - the request was actually not MASC-specific, but to experiment
with whatever the MALLOC group decided was the right approach.

>225.0.0.0-225.255.255.255  MALLOC (temp - renew 1/01)    [Handley]

Agreed - that's why we need to provide guidance to IANA as to what to
do with the space.  I'm not arguing we should blindly request for
renewal - I'm just arguing against a rush to a decision after all this
time.

Cheers,
	Mark

----- Forwarded Message -----

From: Mark Handley <[email-masked]>
To: [email-masked]
cc:
Subject: Multicast Address Apace for Dynamic Allocation
--------

Jon,

As I'm sure you're aware, the MALLOC WG has been developing protocols
to allow scalable dynamic allocation of the IPv4 multicast address
space.  We're now starting to approach the point where we will start
experiments with this address allocation architecture, and to this
end, we're going to need an address space to allocate.

The MALLOC architecture is hierarchical, and designed with the
eventual goal of allocating the entire multicast address space (with
the exception of a relatively small set of well-known and
admin-scope-relative groups).  Clearly though, the jury is still out
on whether this goal will be realised.  Thus we should probably start
with a moderate sized space to be dynamically allocated, and expand
this space later when we can show that the allocation architecture is
working effectively.

Currently 224.2.0.0 to 224.2.255.255 is allocated to multimedia
conferencing, and the upper half of this range is allocated
dynamically using SAP.  The MALLOC allocation architecture is not
restricted to multimedia conferencing - it is intended for general
purpose multicast address allocation.  SAP will eventually be replaced
by the MALLOC architecture for address allocation, but for a while
both mechanisms will have to be able to co-exist.  Using a different
space makes this somewhat simpler.

Thus we'd like to request a new and larger space for dynamic
allocation using the MALLOC architecture, preferably 225.0.0.0 to
225.255.255.255.  This would be large enough to perform realistic
experiments and to accomodate current and near-future multicast usage.

The idea would be that in the long term the range can be expanded to
include the rest of the address space up to the base of the
administratively scoped range.  To this end, we'd also like to suggest
that the ranges 226.0.0.0 to 231.255.255.255 and 233.0.0.0 to
238.255.255.255 be marked as "reserved" to discourage people believing
that they can request a large statically allocated range of addresses.
We would also envisage that the current VMTP range (232.0.0.0 to
232.255.255.255) will probably be returned to "reserved" status in due
course, and would eventually be dynamically allocated too.

Please let us know if you need clarification on any of these details.

Thank you,
	Mark Handley (MMUSIC WG chair)
	Deborah Estrin
	Dave Thaler (MALLOC WG chair)
	Steve Hanna (MALLOC WG chair)
	Bill Fenner (IDMR WG chair)
	Dave Meyer (MboneD WG chair)
	Steve Casner (AVT WG chair)

----- End of Forwarded Message -----

---

From: Randy Bush <[email-masked]>
Date: Fri, 06 Jul 2001 15:50:24 -0700

seems to me that it would be more productive to work on dynamic address
protocols, than how to rationalize keeping space from the last experiment.
if y'all had a good experiment, then getting address space for it would be
easy.

randy

---

From: David Meyer <[email-masked]>
Date: Fri, 6 Jul 2001 15:54:51 -0700

Ok, here's how you could help me in the short term. The
assignment is marked temporary. If you could outline for me the
criteria the IANA can use to decide whether to renew it annually
that would be very helpful (after all, if its temporary then the
IANA will need to know how to evaluate how and when the
assignment expires, otherwise it is permanent). 

Thanks,

Dave