Subject: Re: (s,g) assert info in (*,g) state

From: "Jyotheeswara Rao Kurma" <[email-masked]>
Date: Tue, 10 Jul 2001 11:41:21 +0500

> The KeepAlive Timer is only set when you use (S,G) state to forward
> traffic.  You haven't used (S,G) state to forward any traffic, since
> you don't have any (S,G) forwarding state, so the KeepAlive Timer
> will not be running.

 Suppose say DR at the receiver end wanted to switch-over to SPT, so 
in order to make this macro to TRUE, should it start the KeepAliveTimer
explicitly ? otherwise JoinDesired(S,G) won't be true .( assuming no 
source specific Joins)...

Thanks,
Jyotheesh

---

From: John Zwiebel <[email-masked]>
Date: Tue, 10 Jul 2001 10:17:02 -0700

> source specific Joins)...

Your question is answered by the data forwarding rules on p17.

  if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) {
      oiflist = inherited_olist(S,G)
      if( oiflist != NULL ) {
         restart KeepaliveTimer(S,G)
        }....

There is a "problem" here -- potentially -- if KAT is defined as being
updated only by forwarding of data (as stated on page 12).  

--2cents next paragraph--

There are several instances where the KAT needs to be updated 
(could be updated?) by just seeing data on an interface.  (More 
correctly, where "I" would like to see it defined that way.)  The 
reason is because when one looks at the route (S,G), you want to
know if the source is really sending traffic or not.  Also, if
you implement a "turnaround router", that router will not actually
be forwarding traffic, but will be sending a (S,G) join to 
relay receipt of a (*,G) join for a router that wants to stay on
the shared-tree.  If you allow the KAT to timeout, the entry
is deleted and recreated causing a potential loss of data flow.

One way to tell traffic is flowing is that the (S,G) expire 
time doesn't decrease (assuming at least 1pps).  Whether or 
not you choose to do this is probably vendor specific.

Here's another topology to consider that doesn't explicity
forward traffic and so shouldn't update the KAT according to
the spec, but where it makes sense to me to do so:

          2src&RP
             |
            -+---+----+--
                 |    |
              int#1   |
                DR    rcvr

-rcvr sends a IGMPv2 report for G
-DR sets "local_receiver_included(*,G)" to True
-int#1 is in pim_include(*,G)
-immediate_olist(*,G) includes int#1  
-causes sending of a PIM join toward the RP
-Data packet comes down shared-tree
   At this point I can't trace the specific Macros
   to use but know that this next step has to happen
   for the router to join the SPT, it should be in section 4.4.7
   where it talks about "UpstreamJPState(S,G)" -- although that
   term isn't specifically used here, p17 says this is what 4.4.7 
   is all about.

   "The downstream state machines and IGMP information indicate 
    that the router should join the shortest-path tree for this 
    (S,G)."

   The spec doesn't specifically say "create (S,G) state" but it
   is implied or you can't join the SPT.  It may also be 
   that the Macro above from p17 was suppose to be the one that
   restarts the (S,G) KAT.  Whatever, it has to happen for PIM
   to work.

-DR creates (S,G) on receipt of data which sets the KAT initially
   Again, the spec isn't clear that creation of the (S,G) has to
   also set the KAT (at least I can't find it), but that has to 
   happen.
-Int#1 is in the 'inherited_olist(S,G)' so JoinDesired is true
-int#1 is the iif so data isn't forwarded, but if you don't
    update the KAT here, the (S,G) will timeout and have to be
    recreated.  That still works, since the router 2rp&src _will_
    have been updating the KAT and data will continue to flow
    to rcvr.

I think the authors did a hell-of-a-fine job putting together these
Macros and this spec.  It "would be nice" if there had also
been some english text that explained what was happening.  The parts
that seem to be "left out" are fairly obvious requirements (IMHO).