Subject: RE: [pim] question on pim assert

From: "Ju, Yu" <[email-masked]>
Date: Tue, 26 Mar 2002 18:26:06 -0500

-----Original Message-----
From: John Zwiebel [mailto:[email-masked]]
Sent: Tuesday, March 26, 2002 5:54 PM
To: [email-masked]
Cc: 'Ju, Yu'; 'Mark Handley'; [email-masked]
Subject: Re: [pim] question on pim assert 

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. 

[Ju, Yu] Actually no. I don't want (*,G) assert state to transit upon
receiving (S,G) assert (with RPTbit clear). 

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. 

[Ju, Yu] I agree. But the current draft does allow a  (*,G) assert to affect
(S,G) assert state. That is what the table on page 78 says for (S,G) assert
state machine in the event of receiving assert with RPTbit set. 

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 

        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 

> -----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: John Zwiebel <[email-masked]>
Date: Tue, 26 Mar 2002 18:13:00 -0800

On Tuesday, March 26, 2002, at 03:26 PM, Ju, Yu wrote:
>
> [Ju, Yu] I agree. But the current draft does allow a  (*,G) assert to 
> affect (S,G) assert state. That is what the table on page 78 says for 
> (S,G) assert state machine in the event of receiving assert with RPTbit 
> set. 
>

Yes, it does and it should.

This is the case where the shortest-path is suppose to win over the 
shared-path.

I had said:
    Point: understanding of assert operation is extremely difficult if 
you think
    that (*,G) asserts have any influence on (S,G) state and visa versa.

But I also said:
   If you assume that  (S,G) -always- wins over (*,G) then things become
   much easier to understand.

I was talking about  (S,G) state as one would see it on a router with a
"sh ip mr" command.  A (*,G) assert will not affect the IIF or the Olist
of that (S,G) state.

Sorry for being incomplete.