[ssm] Re: your mail

Toerless Eckert <eckert@cisco.com> Thu, 17 July 2003 15:09 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11040 for <ssm-archive@lists.ietf.org>; Thu, 17 Jul 2003 11:09:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dANQ-0007I7-Sy; Thu, 17 Jul 2003 11:09:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dAMd-0007Bb-Qs for ssm@optimus.ietf.org; Thu, 17 Jul 2003 11:08:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10910 for <ssm@ietf.org>; Thu, 17 Jul 2003 11:08:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dAMb-00074S-00 for ssm@ietf.org; Thu, 17 Jul 2003 11:08:09 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19dAMQ-00072U-00 for ssm@ietf.org; Thu, 17 Jul 2003 11:07:58 -0400
Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6HF4OuD009064; Thu, 17 Jul 2003 08:04:25 -0700 (PDT)
Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id IAA05486; Thu, 17 Jul 2003 08:04:24 -0700 (PDT)
Date: Thu, 17 Jul 2003 08:04:24 -0700
From: Toerless Eckert <eckert@cisco.com>
To: hoerdt@clarinet.u-strasbg.fr
Cc: Toerless Eckert <eckert@cisco.com>, Dino Farinacci <dino@procket.com>, mboned@network-services.uoregon.edu, ssm@ietf.org
Message-ID: <20030717150424.GH23110@cypher.cisco.com>
References: <Pine.LNX.4.56.0307171118550.22244@clarinet.u-strasbg.fr> <200307171407.h6HE7doV015276@dino-pc.procket.com> <20030717142453.GC23110@cypher.cisco.com> <Pine.LNX.4.56.0307171635410.16163@clarinet.u-strasbg.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.56.0307171635410.16163@clarinet.u-strasbg.fr>
User-Agent: Mutt/1.4i
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA10911
Subject: [ssm] Re: your mail
Sender: ssm-admin@ietf.org
Errors-To: ssm-admin@ietf.org
X-BeenThere: ssm@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=unsubscribe>
List-Id: Source-Specific Multicast <ssm.ietf.org>
List-Post: <mailto:ssm@ietf.org>
List-Help: <mailto:ssm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 17, 2003 at 05:06:18PM +0200, hoerdt@clarinet.u-strasbg.fr wrote:
> Well, it sounds like there is a long road before the SSM internet really
> happend. But I dont really agree with all these points because they
> mix different prob. together.

Please be more specific. Sure, it's a laundry list, sure you can get
lots of SSM deployments with just some of these points being tackled,
but if you want to have all applications that could use SSM to actually
be able to use SSM, then you will likely need to tackle all these points.
> 
> On Thu, 17 Jul 2003, Toerless Eckert wrote:
> 
> > On Thu, Jul 17, 2003 at 07:07:39AM -0700, Dino Farinacci wrote:
> > > >> So, What is missing from IPv4 SSM today apart from a deployment effort
> > > >> today ?
> > >
> > >     Nothing.
> >
> > Ok, let's see if you would consider all of the below to be deployment.
> > I would consider most of this to be development, not deployment. Anyhow,
> > the list isn't short.
> >
> > Technologies:
> >
> > - Source redundancy solutions for SSM channels.
> 
> Not really required for SSM deployment, I see it as an SSM "enhancement".
> As a normal user, I do not need to have redundant node at home.
> 
> >
> > - Check wether all transport/session and higher level IETF specifications
> >   that carry group addresses can also carry source addresses (eg:
> >   SDP source filter extensions). Finalization of RTCP for SSM solutions.
> 
> This is an application problem, is really the network waiting for
> application/session protocols to SSM aware ? If MMUSIC is waiting for
> the network to be SSM too , we are in big trouble (see Chicken && egg)
> 
> 
> >
> > Standards:
> >
> > - A good understanding how to do SSM within other than the global
> >   scope (eg: something like an informational recommendation on how
> >   to do SSM within 239/8)
> 
> I want SSM, and I want it all over the Internet. In my mind, scoping
> is another SSM "enhancement".
> 
> 
> >
> > - A nice application side solution (standard, + freely available implementation)
> >   to emulate ASM on top of SSM. The final goal for that would be something like:
> >   put that emulation into OS kernels so that ASM applications do not need
> >   to be modified.
> 
> I agree.  But will the typical application/middleware writer wait or not
> for the SSM to be deployed before writing this emulation part ? Again,
> this is needed, but right now, this is not needed for SSM deployment in
> the network.
> 
> >
> > - Finalization of all open drafts into RFCs so that anybody working
> >   on actual standards basedd application solutions can start to use SSM.
> >   Hint: Standards based application solutions tend to NOT refer to
> >   any technologies unless they are specified in finalized documents,
> >   eg: RFCs (see discussions in DVB or other application organizations -
> >   if that's how it can be called).
> 
> Igmpv3 is implemented in the most used operating system in the world.
> SSM is implemented in the most used IP routers in the world. Again, If
> applications writers are waiting for the network to be SSM and the network
> is waiting for the applications, we can wait a long long time before
> something happens.
> 
> 
> >
> > Development:
> >
> > - Lots of key implementations:
> >   - IGMPv3 support in switches, both basic and full IGMPv3 snooping
> >     (basic is a term i use for per-MAC address filtering, whereas
> >      full IGMPv3 snooping does per (S,G) IP address filtering).
> 
> Right. But is igmpv3 snooping a major deployment obstacle for SSM ? if
> it is really the case, it's and "Multicast Last Mile" Prob. and do not
> prevent the backbone to be "SSM".
> 
> 
> >   - IGMPv3 host stacks: MacOS, Set Top Boxes, Solaris
> 
> I really do not agree again. Are we all waiting  for the magic point of
> deployment and say : "Is everybody ready ? OK tomorrow we will switch the
> Internet and it will be SSM" I think that we need a deployment plan
> exactly as in IPv6, not only concerning the Last mile but concerning
> Internet.
> 
> >   - Any commercial applications beside WIndows Media and IP/TV
> >     (what other commercial applications support SSM ?) No EPG software
> >     in STBs supports SSM,
> 
> Same as above, it's an application pb. not an network pb.
> 
> >   - Implementations of IGMPv3 router side in router vendors
> >     other than C,J,P - does N support it ? How about E and F ? ...
> >
> > Deployment wise (as i define deployment):
> >   - Waiting for more than 40% of users to migrate to OSs supporting
> >     IGMPV3/SSM.
> >   - Persuading enterprise networks to consistently upgrade edge routers
> >     to enable IGMPv3.
> 
> The network do not have to wait for user to put new service into it. The
> pb is that these 40% of users do not know what multicast over IP is.
> Entreprise networks are generally on the edge of Internet.
> 
> >
> > And this all does not cover transition solutions that may be necessary
> > to move forwards faster than being blocked on any of these problems.
> 
> OK. So, Is the Internet core backbone SSM enabled ?
> 
> Hoerdt Mickaƫl
> 
> 
> 
> >
> > Cheers
> > 	Toerless
> >

-- 
Thanks
   Toerless Eckert
   

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