Hi Heiner, On 05/19/11 18:12, [email protected] 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 > [email protected] > http://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
