Subject: source address in assert packet.

From: "Shekhar, Ravi" <[email-masked]>
Date: Mon, 11 Oct 1999 11:33:09 -0400

> 3.5.1 Sending Asserts
>
>   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:
>
>      1 Do unicast routing table lookup on source address from data
>        packet, and send assert on interface "I" for source address in
>        data packet; include metric preference of routing protocol and
>        metric from routing table lookup.
 ...

> 4.7 Assert Message
 ...
>       Encoded-Unicast-Source Address
>             Source address from multicast datagram that triggered the
>            Assert packet to be sent. The format for this address is
>            given in the Encoded-Unicast-Address in 4.1.

  Text in the draft requires source addresss in the assert packet to be that

  of source address in the data packet which triggered the assert.
  
  But to identify the RP in case of <*, *, RP> assert, isnt it required to 
  have the source address in the assert packet be address of RP?

  Although not necessarily required for identification of <*, G> asserts
(due
  to R bit), is it also desirable to have RP address as the source address
in 
  case of <*, G> asserts? [ If I remember right, there was some discussion 
  regarding this on the mailing list already. Archive is currently
unavailable. 
  Could someone recap? ]

  Thanks.
  - Ravi Shekhar.

---

From: Liming Wei <[email-masked]>
Date: Mon, 11 Oct 1999 12:27:56 -0700 (PDT)

> From: "Shekhar, Ravi" <[email-masked]>
> 

I don't have the archive either. It should be the source address,
because that is the "raw" information about the packets causing such
asserts. Also in case of error, the local box may have a different
idea of who the RP should be. Instead of changing the protocol
actions, we would be better off keeping the source address in the
asserts.

-Liming

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Mon, 11 Oct 1999 12:48:41 -0700

> I don't have the archive either. It should be the source address,

The official archive (from the IETF) site is:
http://www.juniper.net/~pusateri/pim.html
and I guess this one is down.

There is also archive from USC:
http://netweb.usc.edu/pim/mail-archive/
ftp://catarina.usc.edu/pub/pim/mail-archive/

Pavlin

---

From: Liming Wei <[email-masked]>
Date: Mon, 11 Oct 1999 13:31:58 -0700 (PDT)

> From: Pavlin Ivanov Radoslavov <[email-masked]>
> 

Thanks Pavlin.

-Liming

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 11 Oct 1999 17:13:21 -0700

>> ftp://catarina.usc.edu/pub/pim/mail-archive/

Sorry guys. I moved offices recently and my mail gets delivered on
a different machine. I'll see if I can get the html archive
going again. But if not, we may have to rely on the ascii archive.

Tom

---

From: Dave Thaler <[email-masked]>
Date: Tue, 26 Oct 1999 14:30:03 -0700 (PDT)

Sorry to bring this back up, but I think the current "protocol actions"
cause black holes...

> actions, we would be better off keeping the source address in the

For (*,G) state, I believe the metrics included must be the metrics
towards the RP, not the source which triggered the assert, or black
holes result since all routers can think they're the loser for (*,G)
because of different source addresses in different asserts.

Example:
               S1      RP      S2          A has metric 2 for S1
                     /    \                B has metric 4 for S1
                   A        B 
                   |        |              A has metric 5 for S2
                -----------------          B has metric 3 for S2
            (downstream rtrs and hosts)
                       
Situation:
    Both A and B start with the LAN in the oiflist
    Due to queuing delays/drops/whatever,
       A forwards the packet from S2 onto the LAN first,
       whereas B forwards the packet from S1 onto the LAN first.
    B sees the packet from S2 on the LAN from A and sends
       an assert for S2 with metric 3.
    Meanwhile, A sees the packet from S1 on the LAN from B,
       and sends an assert for S1 with metric 2.
    Each receives the other's assert and loses to it.
    Both remove the oif, and a black hole results.

In other situations, using the source metric in a (*,G)
assert can cause the assert winner to change every time
the assert occurs (since a different source address could
be used each time).

The above example is solved by both A and B using the metric
towards the RP.

-Dave