Re: [rrg] Next topic?

Hi Heiner,

On 05/19/11 18:12, heinerhummel@aol.com wrote:
>
> Proposals:
>
> 1) Discussion about alternate multicast instance identification:
>
> Historically, a multicast instance is identified by some unique (?)
> multicast address. Meanwhile there is also ssm, where the multicast
> instance is identified by the sender's unicast address plus some
> multicast-address  from some ssm-specific range. 
>
> Proposal: Use a new multicast-protocol type plus the sender's unicast
> address.
>
> Con: Existing (deployed) multicast services have to be changed.
> Pro: 1 billion IPv4-addresses would be freed for unicast which is
> quite a lot while facing the address depletion issue. 
>
> The discussion should be led by ISP folks. I think, they would know
> best the costs as well as the benefits.

This proposal came up a few times on the North American Network
Operators' Group (NANOG) mailing list, where the ISP folks hang out. I
think the main concern is that "Class D" (and E, the experimental block)
is hardcoded into most router's software, and forcing everyone to
upgrade is just not feasible. Granted, a lot of IPv4 addresses would be
freed this way, but migrating to IPv6 should be a better long term
strategy. The amount of time/energy needed to coordinate a change like
this would be better spent for IPv6 migration.

-Loránd Jakab

>
> 2) State-less multicast for about 99 % of the involved routers by
> means of cascade tree multicast
> Example: By employing a cascade degree =10 about 90 % of the receivers
> wouldn't even become aware of being involved in some multicast
> activity.Assuming 20 hops in average between any two nodes of the
> cascade tree, only a half percent of the involved routers have be
> cascade tree multicast knowledgable.
>
>
> Heiner
>
>
>
>
>
> _______________________________________________
> rrg mailing list
> rrg@irtf.org
> http://www.irtf.org/mailman/listinfo/rrg