[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ssm] Re: your mail
On Thu, 17 Jul 2003 17:06:18 +0200 (CEST)
hoerdt@clarinet.u-strasbg.fr wrote:
> Well, it sounds like there is a long road before the SSM internet reall=
y
> happend. But I dont really agree with all these points because they
> mix different prob. together.
>=20
> On Thu, 17 Jul 2003, Toerless Eckert wrote:
>=20
> > 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. Anyh=
ow,
> > the list isn't short.
> >
> > Technologies:
> >
> > - Source redundancy solutions for SSM channels.
>=20
> 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.
>=20
> >
> > - Check wether all transport/session and higher level IETF specificat=
ions
> > that carry group addresses can also carry source addresses (eg:
> > SDP source filter extensions). Finalization of RTCP for SSM solutio=
ns.
>=20
> 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)
>=20
>=20
> >
> > 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)
>=20
> I want SSM, and I want it all over the Internet. In my mind, scoping
> is another SSM "enhancement".
>=20
>=20
> >
> > - A nice application side solution (standard, + freely available
> implementation)
> > to emulate ASM on top of SSM. The final goal for that would be some=
thing
> like:
> > put that emulation into OS kernels so that ASM applications do not =
need
> > to be modified.
>=20
> I agree. But will the typical application/middleware writer wait or no=
t
> 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.
>=20
> >
> > - Finalization of all open drafts into RFCs so that anybody working
> > on actual standards basedd application solutions can start to use S=
SM.
> > 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).
>=20
> Igmpv3 is implemented in the most used operating system in the world.
I am sorry, but this is simply not true. IGMPv3 is implemented in the mos=
t
recent _version_ of the most used operating system. This _version_ has
a deployment in the few per cent range. It will be years before the avail=
ability
of IGMPv3 support in the OS (much less applications) can be assumed.
Please do not throw away what has been acheived :
IGMPv2 support is really ubiquitous in the OS.
IGMPv2 support is really ubiquitous in applications.
PIM support is pretty ubiquitous in routers.
There is a substantial body of deployment experience in the Internet and
with ISP's.
There are a substantial number of enterprise uses of multicast.
This level of support has taken a decade to acheive. To get SSM to the sa=
me
level IMHO will take another decade.
Multicast deployment at present is maybe 100x's as extensive as IPv6. To =
say
that SSM should replace ASM sends the wrong message. To say that SSM will
complement ASM and simplify xSM deployment is a much better message.=20
=20
Regards
Marshall Eubanks
> 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 netw=
ork
> is waiting for the applications, we can wait a long long time before
> something happens.
>=20
>=20
> >
> > 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).
>=20
> 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".
>=20
>=20
> > - IGMPv3 host stacks: MacOS, Set Top Boxes, Solaris
>=20
> 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 t=
he
> 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.
>=20
> > - Any commercial applications beside WIndows Media and IP/TV
> > (what other commercial applications support SSM ?) No EPG softwar=
e
> > in STBs supports SSM,
>=20
> Same as above, it's an application pb. not an network pb.
>=20
> > - 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 route=
rs
> > to enable IGMPv3.
>=20
> The network do not have to wait for user to put new service into it. Th=
e
> pb is that these 40% of users do not know what multicast over IP is.
> Entreprise networks are generally on the edge of Internet.
>=20
> >
> > And this all does not cover transition solutions that may be necessar=
y
> > to move forwards faster than being blocked on any of these problems.
>=20
> OK. So, Is the Internet core backbone SSM enabled ?
>=20
> Hoerdt Micka=EBl
>=20
>=20
>=20
> >
> > Cheers
> > Toerless
> >
>=20
> _______________________________________________
> ssm mailing list
> ssm@ietf.org
> https://www1.ietf.org/mailman/listinfo/ssm
_______________________________________________
ssm mailing list
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm