Re: [pim] BSR update

[Stig Venaas <stig.venaas at uninett.no>]

John Zwiebel wrote:
>   -- 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.

Yes, note that in my example, B is not a C-BSR itself, it's just a 
router sending a BSM because neighbour comes up, so A is the BSR in
that message.

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

Yes, I'm not sure how realistic such scenarios are, but personally I now 
think that a DNF bit is safer and worth the bit of extra complexity.

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

First of all, what you propose with the DNF would behave exactly like 
unicast BSMs do today, so that is good. There has been suggestions
before that unicast BSMs might be forwarded. In some cases it might 
result in quicker convergence, but I believe that there is a risk of 
getting stale data, which worries me. Your proposal would be just as 
good (no better, no worse) as the unicast BSMs today.

I believe this would both simplify code and specification, as well as 
improving security. I can try to list what the differences would be.

I think there are several implementations that never implemented 
handling of unicast BSMs. Supporting this mechanism is simpler.

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

I have some problems understanding why arp can't be performed first, but 
I'm not so interested in discussing that because I think using a 
multicasted BSM with DNF is both simpler and safer than unicasted BSMs. 
I like the idea that BSMs would then always be sent to the same 
destination address, and always multicast.

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

At least I think I have converged :)

>      o <optional> only accept DNF-bit BSMs for <TBD> seconds after 
> discovery of
>         a new PIM neighbor.

Yes, I'm not sure about this one. Regarding unicast BSMs it now says 
that they are accepted until first BSM or a maximum of 150s (I believe). 
Which kind of makes sense. I'm not able to see any problems in removing 
this restriction though. For unicast BSMs I think it's there partly to 
improve security...

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

Doing the forwarding helps in exactly these pathological cases. But in 
those cases there is a risk of getting stale data as well (if a router 
is out of contact with BSR for a short while).

BTW, a router could also have stale data if there is some packet loss on 
path from E-BSR...

Stig

> 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


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