Subject: [pim] More draft-ietf-pim-sm-v2-new-09.txt comments

From: Pavlin Radoslavov <[email-masked]>
Date: Thu, 01 Apr 2004 16:19:56 -0800

Below I am including few more comments regarding the PIM-SM spec.

First I include few emails to the ML (items 1--3) from other folks
that had raised some issues in the past. Some of those issues are
probably related.

The rest of the items are just editorial stuff.

Pavlin

===================================================================
1) [An old email from "James Huang" <[email-masked]>
   11 Apr 2002]:

After more thoughts on the issue that I raised in my previous
emails, I still believe there is a problem with the (S,G) assert
state-machine.

The problem is as follows:
Suppose initially the state-machine is in the NoInfo state and
AssertTrackingDesired(S,G,I)== TRUE. When it receives a prefered
(S,G) assert message with RPT clear from intf I, it will transition
to the AssertLoser state.
Additionally, if (I == RPF_intf(S)), it will set SPTbit(S,G) to 1.
Now if JoinDesired(S,G) is FALSE, we have created a bad (S,G) state
where SPTbit(S,G) is set to 1 while JoinDesired(S,G) is FALSE.  This
bad state can prevent this router from forwarding future (S,G)
traffic (see sec 4.2 Data Forwarding Rules).

I think the fix is to set SPTbit(S,G) to 1 only if (I == RPF_intf(S)
&& JoinDesired(S,G) == TRUE).

===================================================================
2) [An old email from "James Huang" <[email-masked]>
   17 Apr 2002]:

[Note: this probably is same issue as (1) above]

In the current pim-sm draft, AssertTrackingDesired(S,G,I) includes
the following clause:
	
  (RPF_interface(RP)==I AND JoinDesired(*,G)==TRUE AND SPTbit(S,G)==FALSE)

Can someone tell me why it is necessary for a router with (*,G)
state only to track (S,G) asserts in its RPF_intf(RP(G))?

Consider the following scenario:

			S --------------- RP
			|			|
			|			|
			R1			R2
			|			|
			|			|
		-----------------------------------
			|			|
			|			|
			R3			R4
			^			^
			|			|
			|			|
		igmp(S,G) join	   igmp(*,G) join

Suppose we have the following condition before the (S,G) traffic starts:
At R3, RPF'(S)=R1, JoinDesired(S,G) == TRUE, KLA(S,G) not running,
and SPTbit(S,G) == 0 
At R4, RPF'(RP(G))=R2, JoinDesired(*,G) == TRUE,  and no (S,G) state.

When R1 observes (S,G) traffic forwarded by R2 to the LAN, it will
sends a (S,G) assert with RPT bit clear.  
When R4 receives the (S,G) assert, it will create the (S,G) state
and move its (S,G) assert state-machine for the interface from the
NoInfo state to the AssertLoser state because
AssertTrackingDesired(S,G) is TRUE due to the clause
above. Furthermore, it will set SPTbit(S,G) to 1 because the assert
message is received from RPF_intf(S). 
Now at R4, JoinDesired(S,G) == FALSE (UpstreamJPState(S,G) !=
Joined) while SPTbit(S,G) == 1.
This will create a black-hole and cause R4 to drop all (S,G) traffic
it receives.

===================================================================
3) [A recent email from Christopher Thomas Brown <[email-masked]>
   26 Mar 2004]

I was looking at a situation where an s,g assert is received on the
upstream interface towards the RP and there is downstream *,g state.
I think there is a missing action in Actions A6.

AssertTrackingDesired(S,G,I) would be true in this situation due to
the last OR condition:

RPF_Interface(RP(G) == I) AND JoinDesired(*,G) == TRUE AND
    SPTbit(S,G) == FALSE

So in the NoInfo state this situation would fall under the event:

Received preferred assert with RPT bit clear AND
    AssertTrackingDesired(S,G,I) == TRUE

In the NoInfo state for this event we would perform actions A6.

Actions A6 are the following:
Store assert winner and its metric
Set assert timer
If RPF_Interface(S) == I set SPTbit(S,G) to TRUE.

For this last action it seems like it we would also want to start the
keepalive timer. Without the Keepalive timer running JoinDesired(S,G)
is not TRUE.

For a reminder JoinDesired(S,G) is

immediate_olist(S,G) != NULL OR
    (KeepAliveTimer(S,G) is running AND inherited_olist(S,G) != NULL)

In the situation the immediate_olist(S,G) is NULL so only if the
KeepAliveTimer(S,G) is running will JoinDesired(S,G) be TRUE. It seems
like from the intent of the actions that we are supposed to be on
the SPT.

Am I missing something or should starting the KeepAliveTimer(S,G) be
added to the part of the action for IF RPF_Interface(S) == I?

===================================================================
4) Section 4.6.2 (*,G) Assert Message State Machine

Why the source address in the PIM Assert message is checked
whether it is not zero?
Shouldn't the check be stricter: e.g, whether it is a valid unicast
address?

===================================================================
5) Section 4.3.4:

"The primary IP address of a neighbor is the link-local address that
it uses as the source of its PIM Hello messages. Note that..."

 SPEC: if the IPv6 Hello source address is not a link-local
address, then what should the recepient do?

===================================================================
6) Section 4.12.  Timer Value

The text below is out-of-sync with packet_arrives_on_rp_tunnel():

"However at the RP, the keepalive period must be at least the
 Register_Suppression_Time or the RP may time out the (S,G) state
 before the next Null-Register arrives.  Thus the KAT(S,G) is set to
-max(Keepalive_Period, RP_Keepalive_Period).
+max(Keepalive_Period, RP_Keepalive_Period) when a Register-Stop is
  sent."

 The reason for the inconsistency is because inside
 packet_arrives_on_rp_tunnel() sometimes the timer is
 unconditionally set to Keepalive_Period when a Register-Stop is
 sent.

===================================================================
7) Everywhere

Suggestion:
Change "Upstream Join" to "Upstream-Join" (for timers).
Similarly, change "Upstream Override" to "Upstream-Override" ??

===================================================================
8) Inside Section 4.10.3:
"null register" -> "Null-Register"

===================================================================
9)
In Section 4.10 paragraph "Checksum" replace "the length of the PIM header" 
with "8", because "PIM header" could be ambiguous (e.g., is it 4 or 8).

Also, what about the IPv6 pseudo-header source and destination
address. Are they set to the PIM control message source and
destination address as well?

===================================================================
10) Section 4.6.1 (S,G) Assert Message State Machine

Why part of the "In I Am Assert Loser (L) State" table is listed
first? Shoudn't it be moved a bit down together with the rest of the
"Loser State" table.

===================================================================
11) Maybe replace "See Join(*,*,RP) to MRIB.next_hop(RP)"
    with
    "See Join(*,*,RP) to NBR(RPF_interface(RP), MRIB.next_hop(RP))"

    Similar change needed for
    "See Prune(*,*,RP) to MRIB.next_hop(RP)".

===================================================================
12) Maybe change "MRIB.next_hop(RP) GenID changes" to
   "NBR(RPF_interface(RP), MRIB.next_hop(RP) GenID changes" ??
===================================================================

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim