All things related to multicast

[Marshall Eubanks <>]

Michael Luby wrote:

> In the PIM Sparse Mode section:
>
>    Within a PIM Sparse Mode domain, the standard PIM Sparse Mode
>    mechanisms are used to build shared forwarding trees and source
>    specific trees from IPv4 multicast sources to interested receivers.
>    IPv4 multicast sources are registered with the PIM Rendezvous Point
>    (RP).  Interested IPv4 multicast receivers make their group interest
>    known through the Internet Group Management Protocol, and the
>    associated PIM Designated Router (DR) sends PIM Join messages
>    towards the RP to build the appropriate forwarding trees.
>
>    In the ASM model, PIM Sparse Mode Rendezvous Points have to co-
>    operate in order to discover active sources and set up forwarding
>    trees.  MSDP is used to spread the knowledge of active sources
>    within a multicast group.  PIM-SM source-specific joins are used to
>    set up forwarding from sources towards the interested receivers.  No
>    inter-PIM-domain shared forwarding tree is created.
>
> The last part of this first paragraph is specific to ASM, yet this paragraph
> is written as if though it applies to IPv4 multicast in general.  There is
> no RP for SSM, there is no need for MSDP, etc.  The second paragraph is
> good, as it specifies what happens with ASM using MSDP and the RPs, etc.
> However, it seems logical that there should be a third paragraph for SSM
> that parallels this second paragraph for ASM, that says specifically there
> is no need for MSDP and RPs are not used and the forwarding tree is set up
> directly from the source to the receivers using PIM-SM (or PIM-SSM)
> source-specific joins.
>
> In the MSDP section, it should be specifically noted at the top that the
> bulk of this section only applies to ASM, and specifically SSM does not need
> (and should not use) MSDP.  Most of this section is ASM specific, and it
> should be specifically called out which parts apply to ASM and which parts
> apply to SSM.
>
> -----Original Message-----
> From: 
> 
> [mailto:]On
>  Behalf Of Bill Nickless
> Sent: Sunday, April 01, 2001 8:16 PM
> To: 
> ;
>  
> ;
> 
> Subject: IPv4 multicast best current practice I-D
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> I have posted
>
>   http://www-fp.mcs.anl.gov/~nickless/draft-nickless-ipv4-mcast-bcp-00.txt
>
> to the 
> 
>  and to the IETF mboned mailing
> list.  Please read it over and comment.
>
> ===
> Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
> PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     
> 
>

Mike;

I will have comments on the draft soon; but these are my comments on your 
comments.

>From the PIM v2 spec
draft-ietf-pim-sm-v2-new-01.txt
--------------------
o A router MUST NOT forward packets based on (*,G) or (S,G,rpt) state.
  The (*,G) and (S,G,rpt) -related state summarization macros are NULL
  for any SSM address, for the purposes of packet forwarding.

o A router acting as an RP MUST NOT forward any Register-encapsulated
  packet that has an SSM destination address.


The last two rules are present to deal with "legacy" routers unaware of
SSM that may be sending (*,G) and (S,G,rpt) Join/Prunes, or Register
messages for SSM destination addresses.

Additionally:

o A router MAY be configured to advertise itself as a Candidate RP for
  an SSM address.  If so, it SHOULD respond with a Register-Stop message
  to any Register message containing a packet destined for an SSM
  address.
-----------------
I would say that for the foreseeable future, domains will be BOTH ASM and SSM.
I would also say that these domains will thus have to deal both with RP's and 
with
cross-domain traffic that potentially has ASM traffic in the ISM space. I
would therefore recommend that the BCP explicitly include these details on 
what
to do with RP's in the SSM space.

I would also say that the BCP for SSM should be that inter-domain SSM is only 
done
in the 232/8 address range, and that other SSM uses are restricted to the 
administratively
scoped domain 239/8. Otherwise, SSM address discovery will rear its ugly head.

--
                                 Regards
                                 Marshall Eubanks



T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624
Fax     : 703-293-9609
e-mail : 

     


http://www.on-the-i.com http://www.buzzwaves.com