Subject: RE: mboned: draft-ietf-mboned-ipv4-uni-based-mcast-01.txt

From: "Dave Thaler" <[email-masked]>
Date: Mon, 18 Oct 2004 15:07:02 -0700

The other feedback that was received on this draft is trivial
to act on, but I'd like more comments from other members of
the WG on this now that some time has passed.

Toerless Eckert wrote:
>   I think the draft shows a very logical and well written technical
>   possibility, and i don't want to argue the technical merits, but
>   rather the operational implications:
> 
>   Unlike the current IANA address allocation or hopefully a future
>   extended GLOB address assignment via some registry, this mechanism
>   does not create any documentation as to what application or
>   purpose is associated with a particular group address. I do
>   very much like to have this for addresses intended to be used on
>   a permanent/well-known basis in the global scope.

The application semantics of the range proposed in this draft 
is the same as for GLOP... i.e., global scope, non-permanent.

>   If instead we are talking about non-global scope or non-permanent
>   assignments, then of course documentation isn't all that important,
>   but this draft does not help there. 

See below.

>   It does not cover non global
>   scope addresses, and i think it does not provide much value for
>   non-permanent assignment: If you just want to broadcast across the
>   internet in ASM some TV channels for some period of time, the
current
>   FCFS assignment in 224.2/16 has proven to be quite sufficient:
conflict
>   resolution is not a problem, the only problem is DoS, and that's an
>   ASM problem not an address-range problem and the new method does not
>   change it.

As stated in the introduction, the other problems today, which the draft
does address, are:

o    there is work in progress [AS4B] on expanding the size of an
     AS number to 4 bytes, and GLOP cannot work with such AS's.

o    when an AS covers multiple sites or organizations,
     administration of the multicast address space within an AS
     must be handled by other mechanisms, such as manual
     administrative effort or MADCAP [MADCAP].

o    during debugging, identifying the AS does not immediately
     identify the owning organization, when an AS covers multiple
     organizations.

Back when this draft was first proposed as a WG document, the WG
considered whether there was sufficient value, and in accepting it
as a WG document, I believe it did have consensus at that time that
it was valuable.  I recall that Carsten was one of the people who said
that 256/AS was indeed a problem for him, as they didn't have their own
AS#.  Similarly, Merit's customers (which I was somewhat familiar 
with at the time) have the same problem.  However, as noted above, 
this is NOT the only problem addressed.

I don't know whether any of that class of people are still on this
list, but it would be useful to know if the consensus has changed.

>   But even if we agree on some value of this method for temporary
usage,
>   it is far outweighted in my opinion by the problem that it will
>   be used in an uncontrolled way to allocate addresses on an
effectively
>   much more permanent basis by users:
> 
>   Example:
> 
>     - A small application developer writes a multicast application,
wants
>       to have a well-known multicast address for it, and simply takes
the
>       one address that he gets through the class-C network of his
company.
[...snip...]

All of this example is no different from what can happen with GLOP,
and the draft does not attempt to address this problem.  It is
out-of-scope
for the same reason it was out-of-scope for the GLOP RFCs.

I can refresh the draft based on the other feedback received (from Greg
Shepherd and Dave Meyer), but I don't want to keep spending cycles on
this if no one cares.

-Dave

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/