Subject: RE: IPv4 multicast best current practice I-D

From: "Michael Luby" <[email-masked]>
Date: Sun, 1 Apr 2001 21:07:20 -0700

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Bill Nickless
Sent: Sunday, April 01, 2001 8:16 PM
To: [email-masked]; [email-masked];
[email-masked]
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 [email-masked] 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     [email-masked]

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 02 Apr 2001 10:44:24 -0400

> PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     [email-masked]

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 : [email-masked]     [email-masked]

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