Subject: RE: [pim] question on pim assert

From: "Ju, Yu" <[email-masked]>
Date: Tue, 26 Mar 2002 10:53:16 -0500

> -----Original Message-----
> From: John Zwiebel [mailto:[email-masked]]
> Sent: Monday, March 25, 2002 9:07 PM
> To: Ju, Yu
> Cc: 'Mark Handley'; [email-masked]';
> [email-masked]
> Subject: Re: [pim] question on pim assert
>
>
>
> On Monday, March 25, 2002, at 04:46 PM, Ju, Yu wrote:
> > If the first packet from S2 arrives at R2 and is forwarded
> on the LAN,
> > R1
> > will send out (*,G) assert and become the winner. When R2
> receives this
> > inferior assert, it will send assert (*,G) and claim itself as the
> > winner.
> > This assert from R2 will cause R1 to transit to (*,G)
> assert L state.
> >
> > So why don't we allow R1 to transit to (*,G) assert L state
> at the first
> > place when (S,G) assert state transit from NoInfo to W state?
> >
> >
> You said a downstream router sent an (S,G) join to R1.
> R1 should now have (S,G) state.
> It will not send a (*,G) assert, but an (S,G) assert.

Why a (S,G) assert? Note we supposed the packet was from source S2, not S.

> R2 will then lose the (S,G) assert because it will have to transition
> to "win" state for (S,G).  (*,G for that source is no longer
> important).
>
> If you cause R1 to "lose", then -all- sources will no longer
> come down the shared-tree.
>
> The shared-tree is separate and distinct from the source tree and
> if you don't remember that you get confused about what is suppose to
> happen.
>

I understande that part. And my question is related to that. Why the
processing of (*,G) assert state machine when receiving a (*,G) assert
depends on the condition of (S,G) assert state machine? And which S?

My questions come from page 86 of pim-sm-v2-new-05.txt. The defination of
acceptable assert and inferior assert for (*,G) involve
my_assert_metric(S,G,I). I don't know which S it refers to in the
defination.
Also the Transitions from NoInfo State section says "When in NoInfo state,
the following events trigger transitons, but only if the (S,G) assert state
machine is in NoInfo state". Again, which S it refers to? And why is that?

> _______________________________________________
> pim mailing list
> [email-masked]
> http://catarina.usc.edu/mailman/listinfo/pim
> 
_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: "Prashant Jhingran" <[email-masked]>
Date: Wed, 27 Mar 2002 01:05:22 +0530

hi all,

        This discussion seems to get longer n longer...well I believe Ju's
confusion is simpler than what
        Mark is talking about....
What I feel is that, we need not go in the intricacies of Assert macros.they
might lead to greater confusion.:-)

The following lines should be carefully examined..they  give a big clue..

"For example, if both the (S,G) and (*,G) assert state machines where in
the No Info state when an Assert message arrives, and the message causes
the (S,G) state machine to transition to either "W" or "L" state, then
the assert would not be processed by the (*,G) assert state machine."

John Zwiebel tried to give the answer in one shot.
"Basically, a (S,G) assert should always win over a (*,G)
assert -- meaning also over an (S,G,R) assert if one happens
to show up.  (ie, you would not create (S,G,R) state on the losing
router even though what you are effectively doing is pruning the
shared-tree."

I totally agree with John ... but in his next lines he wrote..

"Now that that router (the loser) has a PIM neighbor that
is forwarding on the shortest-path, the losing router should
also switch to forwarding for that source on the SPT.)"

Which I feel should not happen..

Coming to the Ju's first part of the question:
"Why the
processing of (*,G) assert state machine when receiving a (*,G) assert
depends on the condition of (S,G) assert state machine? And which S?"

"S" definitely is the unique source S due to which Assert has happened.

Dependency on (S, G) while processing (*, G) can be explained as follows:

Modifying the scenario which Mark took...
>
>
>                   S
>                  .
>                .
>              .
>    --O --- R1 O (*, G)               O  R2 (S,G) (*, G)---O----
>             |                              |
>             |                              |
>            ====================
>                 |              |
>                 |              |
>                 O R3         O  R4
>
>Suppose R1 is the DR on the LAN and there is local membership for both
(*,G)
>and (S,G).

At R2 the following should happen: -
Since SPT should ideally be better than RPT (Remember Pim is dependent on
unicast protocols for metric stuff), and since both type of entries are
present, (S, G) Down stream should transition to 'W' or 'L' state.. ,rather
blindly winner state.. (The reason for SPT switch over is to avoid delay in
traffic as RP path is pretty long..)
Now the down stream should receive pkt from SPT, i.e. via (S, G) entry.. now
(*, G) state should not be touched coz (*, G) should be forwarding for all
sources for Grp G other than source "S". As a matter of fact (S, G, rpt)
entry should also exist at R2, which will prevent the reception of duplicate
S,G pkts from the RPT.

By doing this the down stream routers will peacefully continue to receive
pkt from all sources linked with group "G" which includes "S" also!!
This I feel is fully in accordance with the draft.(The draft lines which I
have mentioned above)

Now at router R1:

(*, G) exists and it receives SG assert, here no (S, G) entry exists
therefore there is no need to compare metrics for deciding winner/ Looser.
One can directly make the down stream (*, G) state as Looser coz again the
same reasoning comes into picture.
SPT is always better than RPT .
If the peer router has (S, G) entry, as the case is, then router R1 with (*,
G)entry should not fwd the pkt for source "S" on "the" oif.
Now here we can see, since (S, G) state doesn't't exist. transitions were
carried out in (*, G) entry..

This again is very well in accordance with the draft..

The Downstream Routers:

They should track the RPF' Nbrs according to the entries they are having.
Meaning if (S,G)entry is present then RPF' for (S, G) will change and if (*,
G) entry is present then there SHOULD be no transition in the RPF Nbr. since
it needs to send (*, G) joins towards the existing (*, G)winner in order to
get pkt from all the sources linked with "G".
And if both the entries are existing..then also the former case should be
followed..

Remember what is more imp. for the developers is the downstream dependant
routers, coz they should not be devoid of pkt for S,G.
After all the multicast applications will be running on end hosts and they
are our boss.(customer satisfaction, as once told by John) no matter what
happens in the path..they should have regular supply of pkts..

Coming back to the later half of the Ju's question:-
"My questions come from page 86 of pim-sm-v2-new-05.txt. The defination of
acceptable assert and inferior assert for (*,G) involve
my_assert_metric(S,G,I). I don't know which S it refers to in the
defination.

Also the Transitions from No Info State section says "When in NoInfo state,
the following events trigger transitons, but only if the (S,G) assert state
machine is in NoInfo state". Again, which S it refers to? And why is that?"

I feel that the above reasoning holds good here also..

"S" remains the same source due to which Assert has occurred, coz ultimately
source is the deciding factor in assert.

For the highlighted portion, only if (S, G) entry is is not present then (*,
G) states will be manipulated.

Check out the definition of my_assert_metric(S,G,I).. which says
"  assert_metric
  my_assert_metric(S,G,I) {
      if( CouldAssert(S,G,I) == TRUE ) {
          return spt_assert_metric(S,I)
      } else if( CouldAssert(*,G,I) == TRUE ) {
          return rpt_assert_metric(G,I)
      } else {
          return infinite_assert_metric()
      }
  }"
I feel it is self-explanatory. :-)

Well in the last I must say that at least the assert portion of the draft
could have been written in more simpler way!!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Ju, Yu
Sent: Tuesday, March 26, 2002 9:23 PM
To: 'John Zwiebel'; Ju, Yu
Cc: 'Mark Handley'; [email-masked]'; [email-masked]
Subject: RE: [pim] question on pim assert

---

From: Mark Handley <[email-masked]>
Date: Tue, 26 Mar 2002 12:05:20 -0800

>could have been written in more simpler way!!

If you have suggestions, and they don't change the protocol behaviour,
we'd be happy to hear them.  

I believe the current Assert section is not hard to implement
correctly, but unfortunately it is hard to understand the rationale
behind what's there.  In part this is because we didn't manage to
preserve all the rationale from our discussions, and in part it's
because we concentrated primarily on producing a spec that is correct
and possible to correctly implement from or verify against.  Our ToDo
notes perpetually say "add more rationale for Asserts" :-)

Mostly though it's because we failed to find a good simple way of
expressing all the possible Assert interactions. The macros are
complex because the interactions are complex.  We really tried hard to
come up with simple rules.  The simple rules just don't work.
Unfortunately as the macros are complex, it's hard to read them and
intuit what's going on.  

The problem is that when we try to provide high-level intuition about
this part of the spec, we always end up glossing over cases that
matter for correctness.  

So suggestions, and especially contributions of explanatory text would
be most welcome.

Cheers,	
	Mark

---

From: John Zwiebel <[email-masked]>
Date: Tue, 26 Mar 2002 14:53:46 -0800

2cents more and I'm going to drop out of this discussion.

-- Question: if a router with (*,G) state only receives an (S,G) assert, 
what kind
	of data structure, other than creation of an (S,G) -- [or (S,G,R) 
which  isn't
	the same thing] is going to be used to prevent forwarding of data 
on to the
	LAN?  Basically, I'm confused by your suggestion that R1 can somehow
	not forward data for a specific source while maintaining forwarding for
	all other sources on the shared-tree while -not- installing state 
for that source.

-- Question: Ju wants to have R1 transition to (*,G) assert-loser state 
when the
	(S,G) assert is received.  Well, if this happens then R1 will be a 
loser for
	-all- other sources.  Just because one SPT happens to transit this LAN
	does not  mean that any other SPT will.  I may have missed something
	in the discussion, perhaps there was something directly related to this
	specific topology that I missed.  If so, it doesn't matter much to 
me since
	I'm going to insure that the "general" case is implemented.

Some  points I've finally learned after years of thinking we knew what 
we were doing:

Point: The RPT and the SPT are completely separate from each other.  Just
	because they both may cross on a given LAN doesn't mean you need to do
	anything special for them other than make sure that only one 
forwarder is
	chosen.  It makes little sense that data forwarded to that LAN 
should come
	down the shared-tree

Point: If one router on a LAN has an (S,G) with an OIF to that LAN, all 
other routers
	that have an OIF [(*,G) or (S,G)] to that LAN must not forward to 
that LAN -- or
	they must become the (S,G) assert winner.  [NOTE: if the IIF for 
(*,G) is on
	that LAN, then there is no need for (S,G) state, but an 
implementation may
	choose to install that state to track which router is the assert 
winner.  I would
	-iff- there was an assert]

Point: understanding of assert operation is extremely difficult if you 
think that (*,G)
	asserts have any influence on (S,G) state and visa versa.  If you 
assume that
	(S,G) -always- wins over (*,G) then things become much easier to 
understand.

Point:   Even if a router isn't participating in forwarding
	of either the group or the source [ie has no (*,G) or (S,G)] what 
is the harm
	in installing (S,G) state when the assert is seen?  I suppose there 
might be
	a topology where this might create lots of excess state on a router 
that
	isn't being used, but IMHO this would be very rare.  I'm not 
suggesting you
	do it (nor does the PIM spec).

Prashant says that he disagrees with me that a router with (*,G) that 
loses to
an (S,G) assert should install (S,G) and then forward on the SPT.   My 
answer
would be that the (*,G) assert loser must install either (S,G) state or 
(S,G,R) state
to track the fact that it lost an assert.

If you install (S,G,R) what mechanism will you use to maintain that 
state?  Which router is going to be the one responsible for sending the 
RP-bit prune?   How do you avoid
repeating the assert process every 3 minutes as (S,G,R) times out?

If you install (S,G) state, receipt of a (*,G) join will refresh the OIF 
in the (S,G)
so (S,G) state will not go away as long as data is flowing.  And if 
there is no
data, you'll want the state to timeout.

FWIW, an implementation may choose a data structure that can identify 
all the
intricacies of the assert process.  Its difficult for me to imagine 
though.  However,
either way, there shouldn't be any interop problems since what we are 
talking
about is a router that is choosing to remain on the (*,G) tree and 
ignore the
data on the LAN where the assert occurred, or a router that installs 
(S,G) state
and chooses to pick up that data stream from that LAN.  ie, the router in
question is seeing the data on more than one IIF.

Pick one.

BTW, I haven't said lately how much I appreciate the work the authors 
put into
the  new spec.   I think they did an outstanding job.

z

On Tuesday, March 26, 2002, at 11:35 AM, Prashant Jhingran wrote:

> hi all,
>
>         This discussion seems to get longer n longer...well I believe 
> Ju's confusion is simpler than what
> What I feel is that, we need not go in the intricacies of Assert 
> macros.they might lead to greater confusion.:-)
>
> Since SPT should ideally be better than RPT (Remember Pim is dependent 
> on unicast protocols for metric stuff), and since both type of entries 
> are present, (S, G) Down stream should transition to 'W' or 'L' state.. 
> ,rather blindly winner state.. (The reason for SPT switch over is to 
> avoid delay in traffic as RP path is pretty long..)
> Now the down stream should receive pkt from SPT, i.e. via (S, G) 
> entry.. now (*, G) state should not be touched coz (*, G) should be 
> forwarding for all sources for Grp G other than source "S". As a matter 
> of fact (S, G, rpt) entry should also exist at R2, which will prevent 
> the reception of duplicate S,G pkts from the RPT.
>
> By doing this the down stream routers will peacefully continue to 
> receive pkt from all sources linked with group "G" which includes "S" 
> also!!
> This I feel is fully in accordance with the draft.(The draft lines 
> which I have mentioned above)
>
> Now at router R1:
>
> therefore there is no need to compare metrics for deciding winner/ 
> Looser. One can directly make the down stream (*, G) state as Looser 
> coz again the same reasoning comes into picture.
> If the peer router has (S, G) entry, as the case is, then router R1 
> with (*, G)entry should not fwd the pkt for source "S" on "the" oif.
> Now here we can see, since (S, G) state doesn't't exist. transitions 
> were carried out in (*, G) entry..
>
> Meaning if (S,G)entry is present then RPF' for (S, G) will change and 
> if (*, G) entry is present then there SHOULD be no transition in the 
> RPF Nbr. since it needs to send (*, G) joins towards the existing (*, 
> G)winner in order to get pkt from all the sources linked with "G".
> And if both the entries are existing..then also the former case should 
> be followed..
>
> Remember what is more imp. for the developers is the downstream 
> dependant routers, coz they should not be devoid of pkt for S,G.
> After all the multicast applications will be running on end hosts and 
> they are our boss.(customer satisfaction, as once told by John) no 
> matter what happens in the path..they should have regular supply of 
> pkts..
>
>
>
> "S" remains the same source due to which Assert has occurred, coz 
> ultimately source is the deciding factor in assert.
>
> For the highlighted portion, only if (S, G) entry is is not present 
> then (*, G) states will be manipulated.
>
> Well in the last I must say that at least the assert portion of the 
> draft could have been written in more simpler way!!
>