Re: SSM / DOS presentation

[Toerless Eckert <eckert@cisco.com>]

On Wed, Feb 21, 2001 at 04:33:27PM -0500, Marshall Eubanks wrote:
> http://www.nanog.org/mtg-0102/eubanks.html
> 
> Complaints, comments, questions, etc., are welcomed as always and should be directed to me.

Excellent presentation, Marhsall.

Some comments:

a) You write that "SSM is a subset of PIM-SM..."
   Albeit we at Cisco are the first that would state that PIM-SSM is the
   ideal solution to provide SSM services, i wouldn't make the above
   statement. PIM-SSM is just one way how to get SSM. SSM in itself is
   a service mode. I like to say that there's IP Multicast which covers
   two delivery modes: ASM (previously called ISM), in which receivers
   will get traffic as soon as they indicate their desire to join a
   group (they may use IGMPv3 source filtering to restritct that traffic
   though), and SSM, in which receiver MUST signal (S,G) membership or
   he doesn't get traffic. SSM is not about however the routers manage
   to forward traffic amongst each other.

   For example, a subset of  IGMPv3-proxy-routing could also deliver 
   SSM service. Which actually would make good sense for low end edge-routers.
   Or one could think about extending MOSPF to support SSM (*yuck* ;-).
   PIM-Dense-Mode would almost fit SSM, except that the architecture draft
   mandates an "explicit-join" model to cash in on DoS prevention.

b) In one place you write: "Interior routersneed to filter ... for (*,G) joins",
   in another place you write "No RP". I think those two statements are a
   bit confusing, because they relate to wether or not the router understands
   PIM-SSM. If it does understand PIM-SSM, then yes, there's no need to configure
   an RP on it, but there's alo no need to "filter (*,G) joins", they are just
   undefined in PIM-SSM and are ignored - like any other undefined message.
   Now on legacy PIM-SM routers, where you want to configure a group range so
   that it will pass through SSM traffic, yes, you may want to filter (*,G)
   joins, but then again, you also need to define an (imaginary) RP, so that
   the group in in sparse-mode. If there is no RP configured, then the group
   would be dense-mode and not forward the explicit (S,G) joins.

   We thought that it would be difficult to upgrade all of the ISPs core
   to a SSM enabled IOS versions, which is why we put much value in the
   facts on how to configure legacy routers, but then came the ramen worm... ;-))

c) The SSM advantage of "No RP" is actually far larger: No difficult choice
    between AutoRP, BSR, Static-RP configuration or Anycast-RP with MSDP,
    no configuring of redundant RPs... 

d) Whistler is called "Windows XP" now ;-)). 

e) As far as the rate-limits of all kind of messages are concerned,
   i don't think rate-limits buy us enough. We need overall state limitation,
   which is for example what our fix in 12.0(15)S does for MSDP.

Cheers
	Toerless