Subject: RE: imad: Re: mboned: brief IMAD BOF summary

From: "Pashby, Ronald W CTR NSWCDD-B35" <[email-masked]>
Date: Tue, 9 Aug 2005 14:41:19 -0500

Excuse my ignorance. But if this is the problem why don't they use the IPv4 Local Scoped or IPv4 Organization Local Scoped multicast addresses per RFC2365. If the multicast is indeed confined to their own intranet, this would be the ideal solution. 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Beau Williamson
Sent: Tuesday, August 09, 2005 14:35
To: [email-masked]; [email-masked]
Subject: Re: imad: Re: mboned: brief IMAD BOF summary

Guys,

Your still missing the point.  The problem has virtually NOTHING to do with 
the acceptance or deployment of multicast in the Internet.  The abusers of 
the address space are requesting addresses so that they can run an extranet 
directly between themselves and their customers to provide financial data 
service via ASM multicast.  Thus, ISP's in the Internet and their decisions 
have nothing to do with this issue.  Neither do any other technology issues 
wrt SSM support in switches, routers or hosts.

What we have here is the classic case of only having a hammer so everything 
looks like a nail to us.  We are technologist and we are used to trying to 
find technology solutions to problems.  In this case, the problem is not 
technology but policy and end user laziness which results in these requests 
for blocks of addresses from the IANA.

So in summary, there is no special version of IGMP (V3, V2.1, etc) nor any 
other special upgrade or deployment that we can do to fix this 
problem.  Instead, the IANA must "Just Say No" to these requests.

Beau Williamson

At 8/9/2005 10:58 AM, Leonard Giuliano wrote:

>I think we all agree on the deployment benefits of SSM, and they are well
>understood.  I think the point Jeremy is trying to make is that IGMPv3
>isn't the barrier for SSM's slow adoption; rather PIM still is.
>
>IMO, the problem isn't lack of SSM deployment, but lack of mcast
>deployment.  Those ISPs who were going to deploy mcast have done so years
>ago, and few have added it since.  Few if any have deployed SSM-only
>networks.  Those who didn't want to deploy ASM have refused to deploy SSM
>for basically the same reasons.  The benefits of not needing RPs and MSDP
>haven't seemed to sway anyone yet.
>
>Mcast continues to be an all-or-nothing solution, so I believe we need to
>address this issue first.  The last few years have proven that despite all
>of our efforts to the contrary, the entire world simply won't be adding
>native mcast (ASM or SSM) overnight.  Thus, it would seem that transitions
>mechanisms, such as AMT, offer the best hope.
>
>
>-Lenny
>
>On Tue, 9 Aug 2005, Leymann, Nicolai wrote:
>
>-) Hi,
>-)
>-) > I was unable to participate in the discussions thus far, but I am
>-) > assuming the reluctance is that ISPs won't deploy the necessary
>-) > multicast goo in order to support pim-ssm.  Since you have to
>-) > configure
>-) > all the same crap for pim-ssm as you do for pim-sm, with the exception
>-) > of an RP (big deal) I can see why people are hard-pressed to do it.
>-) >
>-) SSM removes some complexity from the network. No need for RPs, no
>-) need for MSDP and it eases addressing. That makes SSM the
>-) preferred solulution for a wide variety of deployment scenarios
>-) (including streaming).
>-)
>-) > IGMPV3 has been in linux for years, a nd I THINK it is in XP as
>-) > well--but I might not be correct on that--so what are we
>-) Yes, it's supported by XP as well.
>-)
>-) > waiting for to
>-) > get IGMPV3 on the desktop?
>-) >
>-) Hopefully not ;)
>-)
>-)   Nic
>-) _______________________________________________________________
>-) user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
>-) web archive:  http://darkwing.uoregon.edu/~llynch/mboned/
>-)
>_______________________________________________________________
>user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
>web archive:  http://darkwing.uoregon.edu/~llynch/mboned/
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

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

---

From: Beau Williamson <[email-masked]>
Date: Tue, 09 Aug 2005 14:58:26 -0500

At 8/9/2005 02:41 PM, Pashby, Ronald W CTR NSWCDD-B35 wrote:
>Excuse my ignorance. But if this is the problem why don't they use the 
>IPv4 Local Scoped or IPv4 Organization Local Scoped multicast addresses 
>per RFC2365. If the multicast is indeed confined to their own intranet, 
>this would be the ideal solution.

No, that's actually a good question.

The reason is that for each customer that they connect their service to, 
the customer has their own allocation/usage of the 239/8 space. Thus, the 
content provider cannot be guaranteed of any address in this space that 
won't conflict with one customer or the other.  (It would be like trying to 
do multiple intranets to several customers and pick an RFC 1918 address 
that wasn't used. Each customer has their own allocation of this private 
address space.)

This is why they are requesting blocks of addresses in what is technically 
the global space from IANA.

Beau Williamson