[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Some comments on the recent discussion on sm-interest@cs.ucl.ac.uk
Folks,
I just subscribed to sm-interest@cs.ucl.ac.uk and I thought I might
summarize what I see happening on the list. One thing I might
say up front that it seems that there is a relatively clear
path to progress on some of the longer term issues. That being
said
(i). There is a growing amount of PIM-SM and MSDP
deployment. This, combined with GLOP assignment
(draft-ietf-mboned-static-allocation-00.txt)
for short term address allocation seems like it should
handle the "small-numbers-of-sources" applications for
the time being (see the number of groups statistic
below). So the question is, what is missing in the
short term? Why not continue to just take that
approach for now?
As an example of current successes, at FIXW (AS10888)
we see:
o 33+ ASs originating MSDP SA-messages into 158 groups
o 2000+ network prefixes in MBGP the table. Note that
since these are shorter prefixes (aggregates) than
we were seeing in the DVMRP MBONE, the size of the
DVMRP routing table isn't directly comparable.
o 5-20 Mbps of unique traffic (i.e. not redundant) on
the Ames MIX at any given time.
o Sources regularly pass streams in excess of 1 Mbps
o 8+ public exchanges support native multicast and
MBGP/MSDP peering
o Several ISPs now provide native Domestic, European,
and Transatlantic multicast using PIM-SM/MBGP/MSDP.
Clearly, a big problem is the current lack of a
workable multicast address assignment scheme.
(ii). Bidirectional trees can be done as a delta to PIM-SM,
for those applications that can make best use of
shared trees.
(iii). Extended addresses for more scalable address
allocation could also be done as a future delta to
PIM-SM and/or BGMP...and as the longer term
replacement for MSDP.
(iv). One of the issues that has come up on this list and
elsewhere is the need to perhaps define a small number
of group types. I guess the discussion needs to be
about whether we understand the differences well
enough at this point to do that or whether fragmenting
the address space is a bad idea. BTW, when we talk
about "group types", I take it to mean thinks like:
o Generic multicast groups
o Bidirectional groups
o Restricted source groups (as originally suggested by
EXPRESS, i.e, the ability for "Disney channel" to
get a group that routing will only allow a certain
source to send on, etc.)
For the most part all of these types of groups can be
supported with currently deployed protocols.
(v). Remaining work
o Finish the work on Bidirectional deltas to make that
a near term option
o Define extended address delta to PIM and any other
existing protocols
o Decide and define what to do about multicast group
types (EXPRESS and others)
o Continue with the current and ongoing security work
o Continue with the currrent and ongoing management
work
Dave