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

Thanks for replying.

Inline.

On Tue, Jan 22, 2008 at 07:57:06AM +0200, Pekka Savola wrote:
> 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.

Drafting RFCs to help users easier repeat mistakes of the past easier does
not seem to be helpfull to me either. If successfull across the internet,
this draft/RFC would proliferate theuse of MSDP and thus cause exactly
what i thought we concluded in the IETF not to be of benefit.

And if not targeted for the internet, as i think some other folks on this
working group agreed to also, then there is no need to delegate this
scheme to global scope, internet routed addresses, right ?
> 
> >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.

Please explain.

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

I disagree. It has been obvious from the adoption of technology in the
indusry, that if given the choice, the path of initial least resistance
is choosen, easilyleading into dead-ends.

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

If a particular application/solution developer (including a financial
service provider) can get hold of globally unique addresses, why again
would the individual user/receiver of such product/services wantor need
to reassign addresses ? I can't follow that logic. These addresses
explicitly do provide for product/service poviders to hard-code
addresses and not ave thier customers worry about those because they
ae globally unique. 

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

Sure. see above about global Internet interdomain ASM/MSDP.

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

Again, the problem is foremost to avoid creating an RFC/IANA assignment
that proliferates and eases a use ofinterdomain PIM-SM/MSDP,and is
draft right now can easily cvause this unless a change in wording
of intended use and semantic of these adresses makes it clear that
they are notmeant to be used across the globalinternet, but at best only
across closed-user-group setups.

Seriously: How can the IETF release as likely standards-track an
addressing method to ease the use of an address space (global scope ASM),
for which the IETF has so far concluded there is no viable scalable
protocol model ???

Cheers
    Toerless

_______________________________________________
MBONED mailing list
MBONED@ietf.org
https://www1.ietf.org/mailman/listinfo/mboned