Subject: The Assert Mechanism: Part 2 :)

From: "Mohit Talwar (Exchange)" <[email-masked]>
Date: Tue, 26 Oct 1999 11:36:35 -0700

hi all,   

i think there is a rule missing from section 3.5.1 (Sending Asserts) 
which will prevent the assert mechanism from stopping duplicates
downstream.

consider the following topology...

                            +---+               
                            | A |               
                            +---+               
                              .                  
                              .                  
                              .                  
            +-+-+                           +-+-+
            | B |                           | C |
            +-+-+                           +-+-+            
              |                               |               
----------+---------------------------------------+----------
          |                                       | 
          S                                     +---+
                                                | D |
                                                +-+-+
                                                  | 
                                                  R

A is the RP
B is the DR on the LAN
C is the RPF towards A for D
R is a receiver
S is a source

now consider the following sequence of events...
R joins a group G
D creates (*,G) state and sends the join on the LAN with C as the target
C create (*,G) state and forwards the join upstream towards A
---
S (source) starts sending data
B creates (S,G) state and sends the data packet in a register to A
D receives the data packet on the right incoming interface and forwards it
to R.
C receives the data packet on an interface in its OIL (outgoing 
interface list) and sends an assert.  however the assert is ignored 
by both B and D since none of them have the interface in their matching 
OILs.  hence C would not create an (S,G,RPT) tree entry and delete the 
interface from its OIL.
---
the register is de-encapsulated by A and sent downstream towards C.  
C will eventually forward this data packet on the LAN which again succeeds
the 
incoming interface check at D and is forwarded to R.

R keeps getting dups of each data packet sent by S to G!

i think the solution is to modify section 3.5.1 thus...

"
   The following Assert rules are provided when a multicast packet is
   received on an outgoing multi-access interface "I" of an existing
   active (S,G), (*,G) or (*,*,RP) entry:

   0. if the source of the data packet is a local, directly connected
      the router and the matching entry is (*,G), or (*,*,RP), the 
      router creates a (S,G)RPT-bit entry.  Otherwise, no new entry is 
      created in response to the Assert.  the router should then delete 
      the interface from the entry and restart the entry-timer.
"

basically the router should behave as if it lost the
assert election when the source is directly connected.

thanx,
mohit.

---

From: helmy <[email-masked]>
Date: Tue, 26 Oct 1999 11:47:49 -0700 (PDT)

If I remember correctly, I have studied Register looping in my research
and added a rule that a packet is never forwarded back onto the LAN from
which is originated, i.e., C should never forward the packets onto the LAN
to which S is attached.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 26 Oct 1999 15:19:54 -0700

>> which is originated, i.e., C should never forward the packets onto the LAN

    You don't need to add a rule. B and C, *both* should have created
    (S,G) state when S sent the packet. Then when C gets a packet from the 
    shared tree it never forwards out the RPF interface for S.

Dino

---

From: Bill Fenner <[email-masked]>
Date: Tue, 26 Oct 1999 15:51:45 -0700

>    (S,G) state when S sent the packet.

This is not reflected in the spec.  The spec only mentions the DR creating
state when a locally-connected source starts sending.

  Bill

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 26 Oct 1999 15:54:33 -0700

>> state when a locally-connected source starts sending.

    Definitely spec bug.

Dino

---

From: Liming Wei <[email-masked]>
Date: Tue, 26 Oct 1999 16:50:51 -0700 (PDT)

> From: Bill Fenner <[email-masked]>
> 

It should soon.

-Liming

---

From: Liming Wei <[email-masked]>
Date: Tue, 26 Oct 1999 16:57:37 -0700 (PDT)

> From: Dino Farinacci <[email-masked]>
> 

To make it clear what I meant. The spec should state that (S,G) state
is created if it does not already exist and a data packet is seen from
a directly connected source.

-Liming

---

From: Beau Williamson <[email-masked]>
Date: Fri, 29 Oct 1999 16:09:23 -0700

>a directly connected source.

I don't think it matters if it is a directly connected source or not.  

There are other cases (not necessarily applicable to this section of the spec) where a router can receive data packets from a source for which it has no (S,G) state.  Unless I'm mistaken, the router needs to create state in these cases as well.

Beau