Subject: Re: [[email-masked]: I-D ACTION:draft-ietf-pim-v2-dm-02.txt]

From: Bill Fenner <[email-masked]>
Date: Thu, 20 May 1999 13:00:45 -0700

This draft doesn't seem to have answered any of the outstanding PIM-DM
issues that have been brought up over the past several months.

None of the black holes that I pointed out appear to have been
addressed.

There are some open questions about packet processing - 2 that I remember:
- where do you send a graft if you sent your prune
with an upstream neighbour of 0.0.0.0?
- what do you do with a Join that does not appear to
be acting as a prune-override (e.g. your prune-override
timer is not running for the source and group described
in the Join)?

Sections 5.3 and 7.8 still disagree about when to send Graft-ACKs.

Section 5.2.1 is still very vague about what it means by "must not be
sent...in response to each ... packet"; it could be interpreted to
mean "must never be sent".  I continue to think that this should be
reworded.

Several references to "deleting" an interface were changed to say
"prune", however several references remain to "deleting" the interface
so now it's even more confusing than it used to be.

"negative cache entry" is defined in section 5 as an entry with no
outgoing interfaces, and section 5.6 as an entry whose outgoing
interfaces are all pruned.  These definitions should be unified
(and perhaps put in the glossary).

The reference to the PIM-SM spec in section 7 is normative; thus this
document can't progress to a state (e.g. Proposed) before the SM
spec is in that state.  This probably isn't desirable.

  Bill

---

From: Aman Devgan <[email-masked]>
Date: Thu, 20 May 1999 16:37:41 -0400

In section 5.2.1 that explains prune-override, the draft says that,
"Other routers on the LAN will hear the prune message and respond
with a join if they still expect multicast datagrams from the expected
upstream router".  Won't a "graft" instead of a "join" be more acurate?
This will be in line with sections 7.4 and 7.7 .

Aman