Re: [MBONED] addrarch: IANA allocations and assignments

[Marshall Eubanks <[e-mail]>]

On Dec 20, 2006, at 6:30 AM, Pekka Savola wrote:

> AD review: IANA allocations and assignments
>
> 1) The draft says that IANA should not make direct multicast address
>    space allocations (big chunks) to operators and even direct
>    assignments (e.g., applications) seem like land-grabbing.
>    Justification for this recommendation did not seem to be suitably
>    well established, and this seems just discussion, given that we
>    presently do not make instructions for IANA (see issue 3).  Issues
>    in particular:
>
>   1.1) What is the IPv4 multicast allocation approach for
>    those networks which will only have 4-byte AS numbers?
>    (Expected to happen in a couple of years.) GLOP is no

Or a couple of weeks, given that these will start appearing  on 1/1/2007

>    longer applicable.
>
>    Possibilities include:
>     - IANA handing out static allocations (again, strongly
>       discouraged in Section 2.3),
>     - IPv4 unicast-prefix -based allocation could be marketed
>       as a potential solution in this space (would we need to revive
>       this or is the option of reviving it in the future if there is
>       interest good enough?),
>     - no approach seems to be needed for this (given SSM and v6  
> methods),
>     - something else?

This to me is connected to eGLOP. If we need a mechanism, then why  
shouldn't it be eGLOP ? I think that makes
a lot more sense than trying to extend GLOP to long ASNs.

I think (given the inquiries I get about multicast address space)  
that any mechanism needs a solution
for people without ASNs (who also, as a practical matter, typically  
will not have PI address space either). eGLOP
would provide that, a prefix based scheme will not.

I have offered to assist anyone who wants an eGLOP space to get one;  
that offer still stands. Normally, I would take a
lack of response as a lack of demand, but I am definitely not sure of  
that in this case, as I actually have reason to
think that there is a demand.

>
>   1.2) No evidence is presented that "land-grabbing" multicast  
> assignments
>    has been a problem.


Indeed.

> It's true that there is still a lot of space
>    in the "AD-HOC Block" (224.0.2.0 - 224.0.255.0).  Internetwork
>    control block is almost full though, and should probably not be
>    expanded too much.
>
>    Is there something we should do here, e.g., make Internetwork
>    control and local network blocks (224.0.1.0/24 and 224.0.0.0/24
>    respectively) more difficult to get, tone down the AD-HOC block
>    language, or what?
>

I think that this language seems OK - what exactly are you proposing ?

One thought I have had would be to make a block of the ad hoc block  
be "local"
and give out (quickly or even automatically) addresses for  
application developers from that block.


>    Note that there is an expired draft that tried to do a bit of this,
>    but it was never finished:
>    http://tools.ietf.org/wg/mboned/draft-ietf-mboned-rfc3171bis/
>

This should probably be revised and pushed through. My recollection  
is that this died from lack
of energy - were there specific issues ? I don't see any in my mail  
archives, which I think are complete...

Regards
Marshall

> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mboned


_______________________________________________
MBONED mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mboned