>I thought the "no land wars in Asia" comment last night with respect to
>multicast was hilarious. Some comments though:
>
>1. It might be shortsighted to take such a narrow view on multicast at the
>moment. Given the ubiquity of IP now and move that forward by X number of
>years along with the resource efficiencies for broadcast-style (and other
>applications) that multicast offers, it seems that Internet multicast
>routing should be a priority.
>
>2. Section 4.3 takes another (slightly less humorous) swipe at multicast.
>This might be the time to get it right ... or else you will have a bunch of
>engineers in 10 years standing around watching gazzillions of duplicate
>SCTP unicast packets of the live MARS landing video feed bring down
>Internet 5.
>
>I understand the focus here is on next generation inter-domain routing
>requirements.
There are really two possible approaches we might take:
- Try and devise a new architecture for unicast and multicast.
- Try to ignore multicast.
If we try to do the latter, then we're essentially assuming we can run
existing multicast routing protocols (or something vaguely similar)
over the new architecture. If we're going to make this assumption,
it's probably worth trying to capture these protocols' assumptions of
what unicast routing provides them.
The thing that particularly comes to mind is that most multicast
routing protocols depend on RPF information for tree formation or
maintenance. If we came up with an architecture where you couldn't
use RPF information, then none of these protocols could work.
Cheers,
Mark
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT