Subject: mboned: draft-lehtonen-mboned-dynssm-req-00 comments

From: Pekka Savola <[email-masked]>
Date: Sun, 6 Mar 2005 17:33:43 +0200 (EET)

Hi,

A couple of notes I jotted down on the flight.  In general, I think 
this is a rather good problem statement/requirements document.

substantial
-----------

  The solution for discovery
    of new sources during the ongoing session should be standardized for
    several reasons:

==> I think you should add here something like:

   o While Embedded-RP provides the similar functionality as dynamic SSM
     source discovery, Embedded-RP is IPv6-only.

That is, outright, I don't see much difference with Embedded-RP and 
dynamic SSM.. just that dynamic SSM requires a smaller codebase if you 
assume someone would be deploying _only_ PIM-SSM (but everyone already 
implements PIM-SM in any case), and that SSM behaviour wrt "SPT/RPT 
like behaviour" is more deterministic (there has been proposal for 
this for Embedded-RP as well).

Most importantly, if you add dynamic sources to SSM, the security will end
up looking awfully lot like Embedded-RP's so the security can't be a
convincing argument either.. (maybe Register message attacks can be
handled a bit more sanely, but that's probably all).

Btw, are there requirements for the security of the service? E.g., 
there will certainly be an impact on the SSM service model..

editorial
---------

    There are several problems with traditional multicast [6] and it's

==> please don't cite [6] for the problems w/ traditional multicast; it
doesn't try to discuss them.

    SSM requires the application to specify exactly which sources it will
    receive data from.  The source addresses must somehow be learned by
    the receivers out-of-band.  With traditional multicast the multicast
    group to use must be announced out-of-band before the session is to
    take place.  It may be announced using e.g.  SDP over HTTP or SAP.
    For SSM one could also list the addresses of the sources.

==> the second-to-last sentence is a bit confusing (I guess those are for
ASM?), because SAP is not applicable for SSM AFAICS.

    same level of performances than the current ASM architecture is

==> s/performances than/performance as/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/