Subject: PIM-DM spec comments

From: Bill Fenner <[email-masked]>
Date: Wed, 15 Dec 1999 21:47:58 -0800

Hi,

Section 5, first paragraph: "RPF lookup in the unicast routing table" doesn't
feel like it includes e.g. a RIB built up from MBGP SAFI 2 & 3 routes, or
as-yet-undefined extensions to OSPF or IS-IS to carry multicast-specific
topology.

Section 5.1, first paragraph: the footnote is a little verbose and probably
doens't need to be a footnote.  How about appending "in that it is not
a per-source attribute but simply an attribute of a router interface" to the
last sentence and deleting the footnote?

Section 5.1, 3rd paragraph: the phrase "both routers must not forward" seems
to me to be open to misinterpretation; does it mean that "neither router
should forward" or "only one router should forward"?

Section 5.2.1, second paragraph; the sentence "Prune information is flushed
periodically" is open to misinterpretation; does it mean that I as an
implementor should create a timer and every time it goes off flush all
prune information that I know about?  I'd rather see it say something about
prune messages carrying timers, and when the timers go off the prune is
forgotten and traffic is forwarded again.

Section 5.2.1, last paragraph: I still think that 3 seconds is ridiculously
long, and that the default prune delay should be on the order of 100ms.
Especially with high-rate sources, 3 seconds is an eternity.

Section 5.3, last paragraph: it's not completely clear that the guy
receiving the message ACK's all (S,G)'s in the message whether or not
he did anything about them.  (i.e. the Graft-Ack is an Ack of the
receipt of the Graft, not an ack of any action performed).  Maybe
changing the third sentence to mention sending the Graft-Ack first,
and then talking about processing each (S,G)?

Section 5.4, 1st paragraph: I'd say "... (DR) election uses the same
procedure as sparse-mode...", since using a procedure makes much more
sense to me than having a procedure.

Section 5.4 is the only place where it talks about the specifics of
sending hello messages and timing out neighbors, so one might think that
Hello messages are only used for DR election and since DR election is
only necessary on multi-access networks, fail to send hello messages on
P2P links.  I'd move the stuff about sending and timing out Hellos to
section 5.1, where you talk about leaf network detection.  (Or at least
give it its own section seperate from DR election).

In section 5.5, the sentence talking about rate-limiting Asserts could
possibly be interpreted to mean that you only send one Assert out any
given interface once a second (as opposed to one Assert per (S,G,Interface)).

In section 5.7, step 1 says to send a prune towards the old incoming
interface.  Prunes are sent to neighbors, not interfaces, so perhaps
it means to send a prune towards the old RPF neighbor.

Section 6: The router has to have a GenID per interface, and must change
an interface's GenID when:
- it transitions from non-leaf to leaf
- multicast is disabled/enabled on the interface
All interface GenIDs must change when the router's state is cleared or
the router is rebooted.
See Ajit Thyagarahan's comments (in IDMR) on the DVMRP GenID.

An issue that is not addressed in the spec at all:

- Sending a prune when you receive traffic on a non-RPF P2P interface.
This is pretty important, to prune redundant links from the broadcast
tree, but I don't see it in the spec.

A general issue:

PIM-DM pruning is very prone to effects (the 3-second LAN prune delay
and timer skew at leaves) that cause pruning to be mostly ineffective
near the root of the tree.  Prune-refresh solves these effects, but we
have a lot less experience with it.  I'm hesitant to push a dense mode
protocol that can have such flooding problems towards proposed standard;
what do people think about making Prune-refresh part of the base PIM-DM
spec?

  Bill

---

From: "Wadhwa, Sanjay" <[email-masked]>
Date: Thu, 16 Dec 1999 11:30:40 -0500

While this thread is active :

Section 5.6 last paragraph says :
"The prune message sent upstream contains a holdtime. It's default
value is [Data-Timeout], except when the Assert timer is also running,
the holdtime in the prune message is set to the smaller value between
the prune holdtime the system uses, and the remaining assert timer value
before it's expiration".

Shouldn't the hold time sent up in the prune be the minimum of
hold times of prunes received on each downstream OIF. And if
assert timer is running on the upstream, then minimum
should be taken between this minimum hold time and assert time
remaining.

Also, while we have scheduled a prune on a LAN interface, due to
prune received from a downstream neighbor, we might receive another
prune from another neighbor on that interface with a lower hold time.
In which case the prune timer for this OIF should be set to minimum
across all prunes recieved from neighbors on this OIF. I don't think
the draft mentions this.

-Sanjay  

> -----Original Message-----
> From: Bill Fenner [mailto:[email-masked]]
> Sent: Thursday, December 16, 1999 12:48 AM
> To: [email-masked]
> Subject: PIM-DM spec comments
> 
> 
> 
> Hi,
>

---

From: "Shekhar, Ravi" <[email-masked]>
Date: Thu, 16 Dec 1999 17:22:57 -0500

> tree, but I don't see it in the spec.

Isnt it specified in  section 5.2.2, last sentence:

    Prunes  may  be  rate-limited  on  point-to-point  interfaces  when  a
    multicast  datagram  is received for a negative cache entry, or if the
    point-to-point  interface  receiving  the  datagram  is  not  the  RPF
    interface toward the source.

I remember having a long thread of discussion on the mailing list 
whether a prune or an assert should take care of this situation.

- Ravi Shekhar.

---

From: Bill Fenner <[email-masked]>
Date: Thu, 16 Dec 1999 15:15:49 -0800

You're right, Ravi, somehow I missed this when the question arose
and I went to check the spec.  I think that because of the way the
sentence starts, I thought it was just about rate-limiting prunes
and not about an integral part of the protocol.  (Especially since
it says "may", implying that it's not needed for proper operation.
As long as you don't mind what might as well be truncated broadcast,
I guess you don't need to implement it)

So, I think the sentence should be redone to talk about non-RPF
P2P interfaces first and rate-limit later, and it should also
say MUST send prunes since these prunes are a necessary part of
the protocol.

  Bill