Subject: RE: source address in assert packet.

From: "Shekhar, Ravi" <[email-masked]>
Date: Tue, 26 Oct 1999 16:14:56 -0400

Dave, although this is not mentioned in the draft explicitly, 
but there had been an earlier discussion (by Billy NG/Hal Sandick)
on the mailing list which said that rpf check should be done 
towards RP (eddy's pim notes page has an excerpt from there).

My interpretation was that both RPF check and metrics used are 
for RP (if RPT bit is set), only the source address is the 
address of the source whose data caused assert. 
  In a way it is misleading because metric is not that of source,
but as Liming points out, it has useful info for debugging as
it tells us about the source which forwarded the data. RP address
is not really required as its implied by G (unless G is 224.0.0.0
but then <*, *, RP> asserts are not allowed).

Am I missing something?

Regards. 
- Ravi Shekhar.

> Sorry to bring this back up, but I think the current 
> "protocol actions"
> cause black holes...
> 
> Liming writes:
> > > From: "Shekhar, Ravi" <[email-masked]>
> > >   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? ]
> > 
> > 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.
> 
> 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
>

---

From: Liming Wei <[email-masked]>
Date: Tue, 26 Oct 1999 13:35:31 -0700 (PDT)

> address of the source whose data caused assert. 

Yes, I thought this is what we were talking about :-).

Dave, we are assuming that the metric does not always have to be that
for the source in the assert. The RPT bit in the assert tells that.
I'll check the draft again to make sure this is clear.

-Liming