Hi Lorand,
Certainly, my proposal is to find out how urgent is the IPv4-address depletion issue. Maybe it is not urgent and NAT will do. And looking at IPv6: IPv6 provides even more of these funny Multicast addresses :-( You may be fancy about IPv6, not me. (I don't know whether I should be happy or sad about the flow label's destiny so far.) This is RRG, i.e. somehow "research for the better". IMHO there are different actions wrt p2p, p2mp, mp2p, mp2mp and anycast which should be expressed by different protocol types. Yes, some additional information is to be provided: In case of multicast, the sender's IPv4-address, in case of anycast some ANYCAST-destination address (by using a separate protocol type the anycast addres range could be 32 bits long - more than enough). Wrt mp2p I only know MPLS applications - it does not exist in IP. mp2mp isn't reflected nowhere :-( Heiner -----Ursprüngliche Mitteilung----- Von: Loránd Jakab <[email protected]> An: [email protected] Cc: [email protected] Verschickt: Do., 19. Mai. 2011, 18:44 Thema: Re: [rrg] Next topic? 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
