Subject: Re: Assert RPF

From: [email-masked] (Billy Ng)
Date: Fri, 4 Sep 1998 18:04:59 -0400

> From [email-masked] Fri Sep  4 15:22:26 1998
> 
> Hal Sandick states:
> > Billy Ng and I found a slight ambiguity in RFC2362 (PIM-SM) regarding how
> > upstream routers do the RPF check during the Assert process.  Section 2.9
> > describes an upstream router doing a RPF check to the source for a (S,G)
> > entry  or to the RP for a shared tree entry: 
> > 
> > 
> >    "If a router receives a multicast data gram on a multi-access LAN from
> >    a source whose corresponding (S,G) outgoing interface list includes
> >    the interface to that LAN, the packet must be a duplicate.  In this
> >    case a single forwarder must be elected.  Using Assert messages
> >    addressed to `224.0.0.13' (ALL-PIM-ROUTERS group) on the LAN,
> >    upstream routers can resolve which one will act as the forwarder.
> >    Downstream routers listen to the Asserts so they know which one was
> >    elected, and therefore where to send subsequent Joins. Typically this
> >    is the same as the downstream router's RPF (Reverse Path Forwarding)
> >    neighbor; but there are circumstances where this might not be the
> >    case, e.g., when using multiple unicast routing protocols on that
> >    LAN. The RPF neighbor for a particular source (or RP) is the next-hop
> >    router to which packets are forwarded en route to that source (or
> >    RP); and therefore is considered a good path via which to accept
> >    packets from that source."
> > 
> > In section 3.5.1 on sending asserts, only the "source" of the data gram is
> > referred to:
> > 
> >    "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."
> > 
> > We assume that section 2.9 is correct and that section 3.5.1 should be
> > changed to indicate a RPF lookup for the source for a (S,G) entry and a RPF
> > lookup for the RP for a shared tree entry.
> > 
> > Regards,
> > 
> > Hal
> 
> Hal, it looks like you are correct, i've made a note of this in
> 
>  http://www.isi.edu/~eddy/pim/pim-specv2-notes.html
> 
> - rusty
> 

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

---

From: [email-masked]
Date: Fri, 4 Sep 1998 17:49:29 -0700 (PDT)

> router, then we should not ignore it, right?  since the SPT is always preferred 

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
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