All things related to multicast

[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*.