Re: [MBONED] WGLC for <draft-ietf-mboned-ipv4-uni-based-mcast-04.txt>

[Pekka Savola <[e-mail]>]

On Wed, 12 Dec 2007, Toerless Eckert wrote:
> 1. Use SSM
>
>   When applied to the global internet, it proliferates the choice of ASM multicast
>   that in my understanding has been recognized to be no long term IETF preferred
>   choice (based on the status of MSDP necessary to support it). All the applications
>   for global address space that i have seen would better be served with SSM too
>   anyhow, so i i will claim that i have not seen sufficient justification
>   (requirements) for what the draft claims to provide a solution for.

The proof is in the pudding, they say.  If SSM provides better and 
easier mechanisms to deploy some applications, it's going to be used. 
Preventing those that don't see SSM as an option at this point from 
using this approach does not seem very productive to me.

> 2. Do not allocate global addresses for private scoped address use.
>
>   The overwhelming mayority of addressing AFAIK is requested for content distribution
>   in private peerings, never to be handed to the global Internet. Like all the
>   market data or TV providers that i had the unpleasant experience trying to keep
>   as happy customers while still explaining why i hate the allocation of of more
>   Internet scope ASM addresses ;-)
>
>   I would thus propose to redesignate this draft not for allocation of
>   addresses for the global I, but for an IP multicast version of ULAs like
>   existng for IPv6 in unicast (Unique Local Address, rfc4193), aka: define
>   that this additional ASM address space is an extension of administrative
>   scoped multicast addresses that just are globally unique, but that will not
>   be routed across the bit I.

I don't see this suggestion being productive.

However, I don't see that there is anything stopping from creating yet 
another, similar address space that's meant to be used for the purpose 
you suggest (e.g., under the lower bits of 239/8).  But that should be 
a separate proposal (can you write a draft about it?), not requirement 
to change an existing one.

> 3. Consider hard coding of address issue
>
>   Unless we come up with a better way for lame application developers, we
>   will see these addresses hardcoded into applications purely for ease of service
>   discovery. I would like to avoid that as much as possible, because within
>   the context of this draft that constitutes an extreme abuse (you never own
>   unicast adress space forever, so you can't hardcode anything derived from it
>   into applications).

I don't see these addresses being hardcoded (that much) into 
applications, because the app developers don't know which IP addresses 
they end up being used at (but rather being used by enterprises to 
assign addresses to the apps they use).

In this manner I see this as a potentially decreasing the amount of 
applications that use hard-coded addresses, not the opposite.

The app developer could of course use its own organization's IP prefix 
(if it has a sufficiently large IP assignment and expects it to be 
stable) to deploy the hardcoded application to other domains, but this 
is (AFAICS) just fine.  The same is already available with GLOP 
addresses in any case.

>   In any case, it might be useful to consider an actual IANA policy to
>   specifically assign such to-be-hard-burned addresses, also from this ULA
>   space (as none of these resource discovery mechanisms will or should run
>   across the global internet). One cOuld easily use some subrange of
>   <ULAbyte>.[224...255].X.Y. As we obviously can only assign [1...223]
>   with a unicast allocation derived scheme. And by making an IANA
>   assignment with somemandatory informational RFC to specify what application/protocol
>   is used there we will at least get documentation for such hard coded addresses,
>   and by mean of being ULA, we can relax the architectural constraints

An interesting suggestion, please write it up and let's consider it on 
its own merits.. instead of tying it to the fate of this allocation 
mechanism.

-- 
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