Re: 232-Addresses not only for current SSM model

["Stephen Sprunk" <ssprunk@cisco.com>]

Thus spake "Hummel Heinrich" <Heinrich.Hummel@icn.siemens.de>
> About my  motivations regarding this issue:
> In the past (see Pittsburgh-draft draft-hummel-ssm-00.txt) I
> expressed two major concerns:

Reading your draft (now expired) shows that sections 1 and 2 specify the
SSM delivery model and IGMPv3.  Section 3 rehashes the debate between
MOSPF/DVMRP and PIM.

> #1: to have a global (i.e. not source specific) multicast address G
> #2: to build/extend the delivery tree reversely.
> The 232-Address overcomes concern #1 perfectly. But can it be used
> also by future multicast models which do not use the current JOIN
> message? In case this is assured: great. In case this is assured
> even without the need for subranges of the 232-address space:
> even better.

The SSM delivery model specified by using 232/8 addresses does NOT
require PIM or any other specific mrouting protocol, as you imply it
does above.  If you wish to develop a ring-based or minimal tree
mrouting protocol that provides the SSM delivery model, that is
certainly possible.

> In Minneapolis I learnt that there will be no further SSM session.
> While this is ok with regard to the SSM model, it won't be the end of
> working on multicast. At the same time, I think, no one will ever come
> up with a multicast model which uses a non-source specific
> multicast address G. Do you agree?

The ASM delivery model is not source-specific.

> Am I looking to develop a different protocol ?
> Well, I would like to, though I must admit I am neither THE expert on
> classical multicast nor on the new technologies which should be
> integrated /utilized like Optical networking, path protection, OAM.

The problem with trying to optimize for these specific technologies is
that layer 3 can't see them.

> IMHO: Path protection makes a lot of sense if any path failure
> affected thousands/millions of receivers (--> big multicast
> applications such as internet-TV).

Unicast path protection has the exact same issue; any given link failing
in the Internet may affect millions of users.

> Building a bi-directional ring (or tree of rings) may allow that each
> designated receiver node gets the data twice via two different pathes.
> In case any link breaks, it will receive the data at least once.
> Some costs are involved: double bandwidth, some more links

Any such technology can be implemented below layer 3 if desired to
prevent a link from failing in the first place (from layer 3's
perspective).  Carriers have shown a strong adversity to this approach
in the past, so making it mandatory at a higher layer is unlikely to be
popular.

> These figures show: The ring was not too bad compared with the
> Dijkstra-Shortest path tree (which is  state of the art in all
existing
> multicast models).
> The minimal-sized tree is pretty impressive.

The utilization is impressive yes, but the protocol complexity required
to achieve it is unwieldy, not to mention the additional latency
introduced by minimal trees over shortest-path trees.

> Regards,
> Heinrich

S

     |          |         Stephen Sprunk, K5SSS, CCIE #3723
    :|:        :|:        Network Design Consultant, ANS
   :|||:      :|||:       RCDN2 in Richardson, TX
.:|||||||:..:|||||||:.    Email: ssprunk@cisco.com