Subject: Re: Assert RPF

From: [email-masked] (Billy Ng)
Date: Fri, 4 Sep 1998 22:44:09 -0400

> From [email-masked] Fri Sep  4 21:02:02 1998
> 

Hi Rusty, first thanks for the detailed reply.  I think there is a minor
hole in the last scenario you mentioned.  See below:

> Billy Ng states:
> > 
> > Now what about the encoded-Unicast-Source Address in the Assert Packet.
> > The packet format in the RFC says that it is the source of the multicast
> > datagram.  However, in section 3.5.2 on Receiving Asserts:
> > 
> >    3.5.2 Receiving Asserts
> > 
> >    When an Assert is received the router performs a longest match on the
> >    source and group address in the Assert message, only active entries
> >    -- that have packet forwarding state -- are matched.  The router
> >    checks the first bit of the metric preference (RPT-bit).
> > 
> >       1 If the RPT-bit is set, the router first does a match on
> >         (*,G), or (*,*,RP), entries; if no matching entry is found, it
> >         ignores the Assert.
> > 
> > If there is a more specific entry (SPT entry) for this (S,G) on the receiving
> > router, then we should not ignore it, right?  since the SPT is always preferred 
> > over the RPT.
> > 
> > --Billy
> 
> I think the spec will achieve the desired results.  although i had to
> work through a couple scenarios to convince myself.  be a little less
> than optimal (allowing more dup's on the lan, than if an s,g were
> specifically checked)
> 
> 
> for example
> 
> 	s
> 	|    
> 	R4 /----RP
> 	| / 	|
> 	R1	R2
>         |	|
> 	+--+----+ (LAN)
> 	   |
> 	   R3 -- r
> 
> 
> say:
> 	R1 has (s,g)
> 	R2 has (*,g)
> 
>  1. R2 forwards a dup, R1 sends an assert with rpt=0 and wins, R2
> creates (s,g)rpt=1 with the LAN ommited.  everthing is ok.
> 
>  2. if R1 forwards a dup, R2 creates an assert with rpt=1, R1 ignores
> it.  until R2 forwards a dup, then case 1 above happens.
> 
> 
> now suppose:
> 
> 	R1 has (*,g) and (s,g)
> 	R2 has (*,g)
> 
>  1. R2 forwards a packet onto the LAN.  R1 sends an assert with rpt=0
> and wins the assert.  everything is ok.
> 
>  2. R1 forwards a dup onto the lan, R2 creates an assert with rpt=1.
> R1 finds it's (*,g) entry and:
> 
>   a. the lan is not in the (*, g) oif list for R1, R1 ignores the
> assert, until R2 forwards a dup, then case 1 applies.  everything is
> ok. 
> 
>   b. the lan is in both the (s,g) and (*,g) entries of R1.  in this
> case R1 creates an assert with rpt=1 and the election process for
> (*,g) entries takes place amoung R1 and R2.  in which case either
> could be the winner.  if R1 is the winner everything is ok.  however, 
> if R2 wins the assert for (*,G), once it forwards a s,g dup onto the
> lan, R1 will send an assert with rpt=0 and will win the assert for

Right here.  Since R2 has just won the election, R1 will no longer has
this outgoing interface for this (*,G) entry and its (S,G) entry until
the assert times out from downstream.  In this case, the forwarder is
R2 which should have been less preferred.  Is this correct?

So my question is that if we do not ignore the (S,G) entry in the first
place, then the problem should be solved, unless there is another reason
for ignoring it.

--Billy

> s,g, R2 will create an (s,g)rpt=1 with the lan removed from the oif
> list.  This results in R1 forwarding for s,g and R2 forwarding for all 
> other G.  and everything is ok.
> 
> so i cannot think of any other problematic cases.
> 
> however, it _may_ be noted that if R1 has only (s,g) and does respond
> with an assert with rpt=0, this would force the assert process for
> (s,g) entries earlier than having to wait for R2 to send subsequent
> dups.  this doesn't seem as though it would break anything, although i 
> haven't thought this through enough to determine if it will.
> 
> 
> 
> - rusty
> 
> 
> 
> 
> 
> 
> 
> 
>

---

From: Rusty Eddy <[email-masked]>
Date: Tue, 8 Sep 1998 12:00:34 -0700 (PDT)

Hi Billy,

> R2 which should have been less preferred.  Is this correct?

i don't think i understand the: 'and its (S,G)..' and part
about the downstream assert timer.  it sounds like you are
saying that R1's (s,g) will not have the lan on it's ds?

to follow through on this scenario: after R2 has won the (*,G)
assert (rpt=1).  we will have the following state (L is the lan):

	R1: (*,g)       ds= -L
	    (s,g).spt=1 ds= +L

	R2: (*,g)       ds= +L
	    (s,g).rpt=1 ds= -L

	R3: (*,g) up = R2
	    (s,g) up = R1

as long as some downstream stream neighbor (or a local
receiver where R1 has spt switched) on L continues to cause
the (s,g) state, R1 will maintain L in the ds list. do
you see a problem with the above state?  or were you making a
different point?

> place, then the problem should be solved, unless there is another reason

again, i may very well have misunderstood, but it seems to me
the spec as it is will result in the appropriate state above,
so i still don't think anything is broken.  however, your
suggestion may still be valid and save some dups on the lan.
the question is whether this would break anything.

- rusty