Subject: PIM-SM: Assert-Timer for assert-lost oifs

From: Ardas Cilingiroglu <[email-masked]>
Date: Tue, 23 Feb 1999 16:52:44 -0500 (EST)

I believe, we need to have an Assert-Timer for the oifs that
have lost the Assert on, at least for the following reasons:

 - Let's say (*,G) has lost an assert on an interface where the
   router is the DR and there is a local-receiver for G. In this
   case Assert-winner becomes the last-hop router for G. But, as 
   with the other Assert situations, this Assert should time out 
   and DR should again become the last-hop router. I don't see 
   how this can be done without an Assert-Timer at the oif.

 - Another situation is (*,G) copying its oifs into (S,G) entry.
   Let's say we lost assert on an oif of (S,G), but we still have
   a downstream (*,G) entry pointing to us as RPF. Then there is
   no mechanism in the spec to prevent (*,G) oif being copied into
   the assert-lost oif of (S,G) upon receiving Join for (*,G). If 
   we have used an Assert-Timer at the oif, then we could have 
   prevented this.

   An example of this situation is the following figure:

              (*,G)        
              (S,G)        (S,G)
                X           A
                |           |
           -----+-----------+------
                |           |
                Y           B
              (S,G)        (S,G)
              (*,G)
                
   Assume X and Y have (*,G) and (S,G) entries with X being 
   upstream of Y. Also assume A and B have (S,G) entries with
   A being upstream of B.

   Let's say A and X goes into an assert process for (S,G) and
   X looses. Then X will stop receiving Join for (S,G) for 180
   secs, but it will receive Join for (*,G) every 30 secs. If
   we don't prevent (*,G) oif being copied into (S,G) then we
   will have Assert process repeated every 30 secs.

Another point is that, if we really do need a timer for assert-lost
oifs, we don't have to use a seperate Assert-Timer, but we can reuse
the existing Oif-Timer for that purpose.

thanks,
Ardas

---

From: [email-masked]
Date: Tue, 23 Feb 1999 15:45:18 -0800 (PST)

>    how this can be done without an Assert-Timer at the oif.

this still works, it just causes asserts to be triggered approximately 
every igmp - nreport period.  that is an igmp nreport will cause the
DR to add the oif state, dups eventually make it onto the lan,
triggering an assert, removing the oif, etc.  this may result in an
increased number of asserts on the LAN, but it still works.

>    An example of this situation is the following figure:

true.  although i don't think this is all that bad.  one way to
alleviate this if it really is a problem, would be to increase the join 
period for the downstream routers (and oif timeout of the router
loosing the assert)

- rusty

---

From: [email-masked] (Ardas Cilingiroglu)
Date: Tue, 23 Feb 1999 19:22:45 -0500 (EST)

> period for the downstream routers (and oif timeout of the router

Considering the default values for timers, you end up asserting every
30 secs as opposed to every 180 secs, which might be considered too
frequent. Also, about the solution you proposed, one has to detect the
problem and change the timer periods at run-time, which I think is not
very practical. 

I think same kind of timing mismatch exists between igmp-nreport period and
Assert-Timeout period.

thanks,
Ardas

---

From: [email-masked]
Date: Tue, 23 Feb 1999 16:53:04 -0800 (PST)

> problem and change the timer periods at run-time, which I think is not

i guess this is a judgement call.  as a side note, you wouldn't
have to wait until run-time to adjust timers, you could do it
pre-emptively on a LAN that has potential recievers and multiple
paths to a given RP.

> I think same kind of timing mismatch exists between igmp-nreport period and

yes, exactly.

- rusty

---

From: [email-masked] (Ravi Shekhar)
Date: Tue, 23 Feb 1999 22:36:04 -0500 (EST)

>increased number of asserts on the LAN, but it still works.

        This is implementation dependent. IGMP need not inform PIM-SM about 
    its membership every report interval. It might just inform PIM-SM when 
    a new member comes up or goes away. Besides, one might have provisions 
    of adding static group memberships in IGMP i.e. the groups which do not 
    require periodic reports.
        In short, it would be good if PIM-SM timing out is independent of 
    IGMP timers. 

    Regards.
     - Ravi Shekhar.

---

From: [email-masked]
Date: Tue, 23 Feb 1999 23:30:14 -0800 (PST)

>         In short, it would be good if PIM-SM timing out is independent of 

Ravi,  you are, of course, correct.

- rusty

---

From: Bill Fenner <[email-masked]>
Date: Tue, 23 Feb 1999 23:41:47 PST

In message <[email-masked]>you write:
>IGMP need not inform PIM-SM about its membership every report interval.
>It might just inform PIM-SM when a new member comes up or goes away.

In fact, this is what the IGMP RFC says to do.  ("Notify routing"
actions only occur on state transitions).

  Bill

---

From: [email-masked]
Date: Wed, 24 Feb 1999 01:34:18 -0800 (PST)

> actions only occur on state transitions).

this was a complete oversight on my part, and in fact how gated
works.  this also points out an oversight in the pim-sm gated code,
that is, the function for deleting an oif will not remove the assert
looser's interface from the forwarding cache if it knows a local
reciever exists, the only fixes i can think of involve a timer.

Now think i agree with Ardas's orginal message, in that a (*, G) assert
looser that happens to be the DR with local members, will need some
type of a timer,  otherwise the looser/DR will not automatically know
to put the oif back and start sending periodic joins, once the winner
quits forwarding.

Does anyone think the spec ought to handle or mention this?

- rusty