All things related to multicast

["Garry Peirce" <>]

>  On a side note, a growing mobile population will require wireless mcast
support which I've current reservations about (ex. source control).  
>>  Wireless systems will need to support multicast at the ethernet level
since IPv6 requires multicast to work for Neighbor Discovery etc.

Agree, but do so to support either IPv6 or mcast delivery within a Cisco
environment, and users can now source mcast destined traffic across the
WLAN.
Within a Cisco lightweight wireless environment, P2P and ACLs controls are
mcast unaware.
Doing so may then enable other abilities that may not be so desirable
(mDNS/bonjour) to grow which are more difficult to prune once they've gained
user traction.
This is the mcast source control issue I was alluding to before.
In our environment, I feel better v4/v6 mcast source controls are needed
before enabling mcast on wireless.
This is a significant issue as it is holding back wired/wireless service
parity. 

Wondering,  if in lieu of the above, that AMT might serve as a wireless
bandaid until better controls exist.
At the expense of transport efficiency, requiring an additional app (all OS
platform support?) on clients,  and having an added system(s) to maintain,
you gain the ability to provide access
to mcast services while retaining control - certainly worth looking into.



> -----Original Message-----
> From: 
> 
>  [
> ]
>  On Behalf Of Curtis, Bruce
> Sent: Friday, February 25, 2011 3:14 PM
> To: wg-multicast
> Subject: Re: The state of interdomain multicast - ?
> 
> 
> On Feb 24, 2011, at 10:19 AM, Ge Moua wrote:
> 
> > Me and 2 of my other colleagues just had an in-depth conversation about
> these issue you brought up.  There were many smart and devoted people
> who came up with with the working draft to make multicast possible; the
> multicast protocol suite when used for inter-domain routing does have its
> share of complexity but the overall mechanics of how multicast works is
> simple & elegant.
> >
> > The conclusion that we came to:
> > + wider adoption of multicast (IPv4 or IPv6) contingent on how much
> revenue can be generated
> >     * firms like netflix may have financial incentives to do unicast
stream as
> they can potentially charge per stream
> 
>   They do have financial incentives to reduce network costs also.  If they
> encrypted multicast streams they might be able to both save on bandwidth
> and charge individual viewers.
> 
> >     * disconnect between financial incentives & technology efficiency
(in
> the commercial world)
> >     * cache services like akamai / limelight fill niche that would make
> multicast more compelling
> 
>   Yes.
> 
>   Also the companies using p2p to broadcast such as Octoshape show that
> there is interest in alternatives that save money compared to unicast.
> 
> http://www.octoshape.com/?page=showcase/play
> 
> http://www.octoshape.com/?page=services/customers
> 
> 
> > * IPv6 presents options for SSM, but likely hood of AS removing
multicast
> from bogons filters may be low
> > * intra-domain multicast wll be around & prevalent; but for "inter-
> domain" like multicast, many large enterprises (eg., banking & financial
> sectors) get a direct feed to content providers/partners then do
muliticast;
> for IPv4 inter-multicast routing that used the combo of
> MSDP/MBGP/MCAST, this is not a widely adopted model outside of I2
> >
> > I too hope I2/Joint Techs do not remove the mcast working group or their
> sessions; this is one the few practical platforms where R&E folks can
share
> some great ideas re: multicast.
> >
> > --
> > Regards,
> > Ge Moua
> >
> > Network Design Engineer
> > University of Minnesota | OIT - NTS
> > 2218 University Ave SE
> > Minneapolis, MN 55414-3029
> > Email:
> > 
> >  | Office: 612.626.2779
> > --
> >
> >
> > On 2/24/11 9:57 AM, Garry Peirce wrote:
> >> Using the frequency of messages on this list and working SAP entries as
a
> rudimentary gauge, the level of interdomain v4 multicast work/content
> seems low (not to mention v6 which is not yet possible for us).   I
believe
> that mcast has still yet to realize its value and I'm curious in hearing
how
> others view and use inter/intradomain mcast.
> >> Mcast can be R&E differentiating value-add among ourselves and our
> participants.
> >>
> >> To give insight into our use, as a unit of the University System,
> Networkmaine operates Maine's statewide network (K-20, Research,
> Libraries, Public Service).
> >> Within the University System, we currently make internal production use
> of v4 mcast for ITV distance learning (including ~20 K12 sites) and on
> scattered wired subnets as needed for disk imaging.
> >> IPTV of commercial content is a wishful thought, but with cableTV
> services contracted/maintained by other entities , raising interest tends
to
> be an uphill battle.
> >> With the tiny amount of IPTV test content we enable, there's little
> awareness of it.  On a side note, a growing mobile population will require
> wireless mcast support which I've current reservations about (ex. source
> control).   Although not for a lack in trying, mcast peering with MaineREN
> participants is currently non-existent - they see it as desirable but have
had
> no time to devote to it.
> >> What's really missing is content.
> >>
> >> I believe R&Es contain a wealth of potential content ; content that
could
> be shared to wider audiences via mcast.
> >> We've started an (unfunded) grass roots effort to cast live consented
> public events.
> >> The thought was to try and promote multicast within our R&E statenet as
> well as to share such events to wider audiences among it and beyond.
> >> Our recent live events can be seen here , with more on the way.
> >> I'd be happy to share further info/experience about the effort for any
> that may be interested.
> >>
> >> I recently saw a message that I2 JointTech conference is contemplating
> doing away with mcast sessions in lieu of unicast.
> >> I'd be interested in understanding it if someone on the list is aware,
as I
> would think that too bad should that occur.
> >> I wonder if that might be due to shallow interdomain mcast acceptance,
> or that R&E BW growth decreases the need for a more efficient (albeit more
> complex) transport, or perhaps to provide it within an interactive
> environment.  Losing any interdomain mcast content will further decrease
> usage.  Being personally interested in the content,  it's helpful to not
only
> verify the mcast infrastructure but to use as example of how the service
can
> be beneficial.   Believing that part of an R&E network's role is to
> test/develop the network itself, it'd actually be nice to see it via v6
mcast.
> >>
> >> Appreciate any others' thoughts/insights.
> >>
> >>
> >>
> >> <ATT00001..jpg>
> >>
> >>
> 
> ---
> Bruce Curtis                         
> 
> Certified NetAnalyst II                701-231-8527
> North Dakota State University
>

Attachment: Garry Peirce.vcf
Description: Binary data