All things related to multicast

[David Meyer <>]

        Hugh, we talked about a BCP for filtering SAs in MBONED,
        but the idea was shot down due to the concern about
        coordinating between all the involved WGs.

        Dave


According to Hugh LaMaster:
> 
> 
> I know I'm going to regret raising this issue, but, 
> I will anyway:
> 
> On Fri, 25 Feb 2000, David Meyer wrote:
> 
> > > Filtering MSDP causes black holes -- but since MSDP uses MBGP routes
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> > > to decide the path that SA's will travel, it will respect your MBGP
> > > policy.
> 
> >     From draft-ietf-msdp-spec-05.txt
> > 
> > 10. SA Filtering and Policy
> > 
> >    As the number of (S,G) pairs increases in the Internet, an RP may
> >    want to filter which sources it describes in SA messages. Also,
> >    filtering may be used as a matter of policy which at the same time
> >    can reduce state. Only the RP co-located in the same domain as the
>                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >    source can restrict SA messages. Note, however, that MSDP peers in
> >    transit domains should not filter SA messages or the flood-and-join
> >    model can not guarantee that sources will be known throughout the
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >    Internet (i.e., SA filtering by transit domains can cause undesired
>      ^^^^^^^^
> 
> Pragmatically speaking, there are a lot of sources I *want* 
> to black-hole: SGI objectserver processes, rwhod traffic,
> ServerLocation, microsoft-ds, HP printer discovery, and SunRPC.
> Arguably, these are (among the many) things which should
> *never* be announced outside an AS (or even a subnet
> in many cases, a network in almost all cases). 
> 
> Also, processing the SA's from these sources on 224.0.1.2, 224.0.1.3,
> 224.0.1.22, 224.0.1.24, 224.0.1.35, 224.0.1.60, and 224.0.2.2
> does add a major burden under some conditions, and, forwarding
> the traffic erroneously can lead to weird side effects, and,
> needlessly increases state in the routers (if the goal is that
> 100% of the internet is multicast-enabled, are we going to have
> partially mesh together all these services on every subnet 
> in the world?  the mind boggles).
> 
> My point is, the specs should include a set of multicast addresses 
> or address range for which blackholing is expected, even required,
> and which AS's never forward either SA's or traffic for.
> 
> Unfortunately, the addresses which should have global scope,
> such as mtrace, the standard IETF groups, and so on, have been
> pretty much mixed in with the others, and many of the assignments
> have fallen into disuse and the details forgotten by most of us, 
> so it is difficult to come up with a clean set of ranges which
> should be filtered, or a set of addresses which should not be
> filtered.  
> 
> At the moment, the ad hoc approach seems best, but, the RFC's
> should somehow allow for this filtering, which has to take 
> place anyway.
> 
> 
> Comments welcome.
> 
> 
> --
>  Hugh LaMaster, M/S 233-21,    Email: 
> 
>  NASA Ames Research Center     Or:    
> 
>  Moffett Field, CA 94035-1000  Or:    
> 
>  Phone: 650/604-1056           Disc:  Unofficial, personal *opinion*.
> 
> 
>