[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