Re: [pim] BSR update

[John Zwiebel <jzwiebel at cisco.com>]

  -- The BSM triggered from B will have the same priority as
	a new one originated from the BSR.  There isn't a
	procedure for downgrading the BSM priority when
	triggering for a new neighbor.

  -- This is a very complex scenario that requires B not have
	an alternate route to the BSR.  One might be able to
	make the case that the network should be configured for
	reliability if the user expects reliability.

  -- I haven't been able to conjure up a scenario where a 'local
	trigger' (ie not forwarded) isn't "good enough" so, although
	I'm not necessarily against forwarding triggered BSMs,
	it isn't clear to me that it buys us anything.

Please let me restate what the problem is and what we need to fix it.

  Problem: can't unicast a BSM because ARP entries might not  
(usually are not)
	be available to send the message.  (NOTE: perhaps if the message was
	unicast "robustness" times, that might be easier than this DNF-bit)

  Solution (that I think we are converging on):
	o multicast the BSM
	o set DNF bit in PIM header for triggered BSM
	o do not do an RPF check on BSM received with DNF bit set
		(It also means "trust me")
 	o <optional> only accept DNF-bit BSMs for <TBD> seconds after  
discovery of
		a new PIM neighbor.

  Trying to heal a broken network appears to be a pathological case  
where the
	network isn't configured for redundancy anyway.  There's no advantage
	to it since other problems will overshadow this fix.

An example of "other problems": what if your RP is changed from PIM- 
SM to Bidir and
  -- the DR on the LAN does not have the best route to the RP so is not
	selected as the DF.
  -- you have a receiver on the LAN sending IGMP host reports.

  ==> You have a DR and a DF with (*,G) forwarding state.  Doh!!

On Apr 10, 2006, at 3:25 PM, Venu Hemige wrote:

> > -----Original Message-----
> > From: Stig Venaas [mailto:stig.venaas at uninett.no]
> > Sent: Monday, April 10, 2006 1:55 PM
> > Cc: John Zwiebel; venu.hemige at alcatel.com; 'Christopher Thomas  
> > Brown';
> > pim at ietf.org
> > Subject: Re: [pim] BSR update
>
> [...]
> > I believe I see one problem now. If we have the following scenario:
> >
> >            _________________ long non-preferred backup path
> >           /                  \
> > BSR -- A -- R1 -- B -- R2 -- C1 -- C2 -- C3
> >
> > With BSR being the only C-BSR (and elected). Assume now that routers
> R1
> > and R2 restart, and are gone for say 1.5 * BS Period. Assume that
> while
> > they are restarting, the BSR changes the RP set and A and C routers
> > learn the new set. B will however still have the old set. When R1 and
> R2
> > comes up, R2 might accept stale BSM from B. Now if R2 forwards this
> > towards C routers and the IGP by then has gone back to prefer tha  
> > main
> > path (not using the backup path), then C routers will accept and use
> the
> > stale data.
>
> No, I would think the C routers will discard the BSM from B since the
> BSM has lower bsr-priority than what they know about (from router  
> BSR).
>
> Also if you are saying the long non-preferred backup path is not used,
> then it means that both R1 and R2 are up. Which means R1 should start
> forwarding the BSM received from BSR since that BSM has a better  
> weight
> than what it learnt from B. And hence R1, B and R2 should soon start
> using BSR as the elected BSR. The RP-SETs on routers BSR, A and C1,  
> C2,
> C3 should all be unaffected.
>
> Forwarding triggered BSMs is a good thing. And I don't think anything
> wrong will happen in the example you pointed out.
>
> Regards,
> -Venu

_______________________________________________
pim mailing list
pim at ietf.org
https://www1.ietf.org/mailman/listinfo/pim