Subject: [pim] Comments re: draft-ietf-pim-sm-v2-new-04

From: "Anttoni Nurkka " <[email-masked]>
Date: Mon, 4 Feb 2002 15:22:12 +1300

Greetings,

I'm part of the team here at Allied Telesyn Research in NZ wokring on our 
PIM implementation.  I have a few comments and questions regarding the PIM-
SM Protocol Specification.

1- Table of Contents
Comment: No headings for section 4.7.1 and 2.7.2

2- Section 4. Protocol Specification
Comment: A description of Section 4.7 is missing

3- Section 4.4.6.  Sending (*,G) Join/Prune Messages
Comment: Figure 7: the "RPF'(*,G) changes due to an Assert" transition 
indicates an immediate Send Join (*,G).  
This is repeated in the tabular form for said transition.
However, in the textual description, the Join Timer is modified (lowered) 
causing the Send Join (*,G) to occur on Join Timer Expiry.

From our testing, the text describes the correct operation.

4- Section 4.4.7.  Sending (S,G) Join/Prune Messages
Comment: Figure 8 is missing the "RPF'(S,G) changes due to an Assert" 
transition, and it is missing from the tabular form.
The transition is mentioned in the textual description.

5- Section 4.5.1.  (S,G) Assert Message State Machine
Comment: The tabular form of the state machine, for the "In I Am Assert 
Loser (L) State", the transitions for "Receive Inferior" and "Receive 
Acceptable" Assert from Current Winner have the actions swapped.

6- Section 4.5.2.  (*,G) Assert Message State Machine
Question: The bold sentence:
"It is important to note that no transition occurs in the (*,G) state 
machine as a result of receiving an Assert message if the (S,G) assert 
state machine for the relevant S and G is not in the "NoInfo" state."

This has caused me some confusion, so here is how I have interpreted the 
sentence:
"Assert message" = a (*,G) assert (RPT bit set) but with a source 
specified.
"relevant" = with the above interpretation for the assert message, this 
just means the matching (S,G) assert state machine.

Question1: is this the correct interpretation?

If this interpretation is correct, then noting that the (S,G) assert state 
machine has a transition for receiving an (S,G) assert with RPT bit set 
(which is in fact a (*,G) assert), the sentence may be unnecessary.  Or at 
least, may benefit from a re-write to indicate the correct interpretation.

Question2: For an actual (*,G) assert (S=INADDR_ANY, RPT bit set), does 
the state of any (S,G) assert state machine need to be considered?  (This, 
obviously, is where I am confused)

7- Section 6.2.  Non-cryptographic Authentication Mechanisms
Comment: The sentence:
"An implementation SHOULD provide a mechanism to allow a DR to restrict 
the range of source addresses from which it accepts Register-encapsulated 
packets."

I would expect DR to be RP, since it is the RP which receives Register-
encapsulated packets.

I hope these comments and questions are useful, and I look forward to 
getting clarification for my questions in point 6.

Sincerely,

Anttoni

-------------------------------------------------------------
Anttoni Nurkka           27 Nazareth Avenue
Software Engineer        PO Box 8011
Allied Telesyn Research  Christchurch
phone +64 3 339 3000     New Zealand
fax   +64 3 339 3002     email: [email-masked]
                         web: http://www.alliedtelesyn.co.nz/
-------------------------------------------------------------

---

From: John Zwiebel <[email-masked]>
Date: Tue, 05 Feb 2002 11:42:12 -0800

> Question1: is this the correct interpretation?

Yes.  FWIW though, I had to read your 'interpretation'
several times to understand what you were asking.  So,
what's in the spec, although murky, perhaps can't be 
expressed much better than it already is.

2 cents

> obviously, is where I am confused)

No.

Providing that one recognizes that an (S,G) entry and an (S,G,RP-bit)
entry are for 2 different distribution trees suh that when you ask
"any (S,G) assert state..." you are referring only to the source-tree
and you are not confusing it with the shared tree.

-and-

you recognize that a source-tree assert always wins over a shared-tree
assert.

So, if you have a (*,G) with the same olist as the (S,G) and the
same IIF as the (S,G) and you receive a (*,G) assert, you do
not prune off the (S,G) olist, but will see data on that OIF and
send an (S,G) assert.  (Which could mean that -- depending on
what you meant by your question -- that my answer 'should have been'
"Yes".  But the (S,G) assert isn't sent because of the (*,G) assert
so I'll stick with my "No" answer.  )