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

[Tim Chown <[e-mail]>]

Hi,

When I read this discussion, I'm reminded of similar ones between IPv4
and IPv6.   To many people, IPv6 is the future, and inevitable, and working 
on things to keep IPv4 propped up seems time better spent elsewhere.
Yet of course IPv4 is here for a long time.

While SSM may be the better solution in many people's eyes, the reality
is that not all vendors are interested in supporting it, and deployment
obstacles remain.   In the meantime there are sites that would like to
offer global scope multicast content that are having difficulty doing so
due to the existing lack of alternatives to GLOP.

It's all very well to try to block this draft on a point of principle, 
but the reality is that there are issues deploying SSM today, and in getting
globally scoped group addresses for ASM.

I would in fact probably argue that in order to give multicast a foot up
in general, getting initial services running with ASM, until SSM is ready,
could potentially be very useful.

In my own context, UK universities are one such community who would 
benefit from this proposal.   You have several hundred sites for whom 
address space is available from only one ASN.    Dave's proposal puts the
address alolcation and managementin the hands of the end site (just as IPv6
multicast does).

And I would echo Pekka's request to extend the 'experiment' to 3 or 5 years 
initially.

Tim

On Mon, Jan 21, 2008 at 10:20:46PM -0800, Toerless Eckert wrote:
> 
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mboned

-- 
Tim




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