[pim] Re: Bootstrap Router Mechanism: Forwarding of non-preferred BSMs

[Alexander Gall <[e-mail]>]

[ Cc'd Stig ]

Mark,

Sorry for the late response.

On Mon, 14 May 2007 22:30:59 +0200, Mark Doll <[e-mail]> said:

> I have questions/comments regarding the forwarding of non-preferred BSMs in
> the Bootstrap Router Mechanism, as specified in draft-ietf-pim-sm-bsr-10.txt.

> First:
> =====
> Why do routers in state "Candidate BSR" forward non-preferred BSMs from the
> elected BSR (and switch to state P-BSR), but routers in state "Accept
> preferred" don't?

They do.  In the description of the event "Receive Preferred BSM" in
section 3.1.4 it is stated that

          A Bootstrap message is also preferred if it is from the
          current BSR with a lower weight than the previous BSM it
          sent ...

for precisely this reason.  However, this is not evident if you just
read the description of the event "Receive Non-preferred BSM".  To
make this clear, I suggest to add a reference to this exception:

      Receive Non-preferred BSM
           A Bootstrap message is received from a BSR that has lower
           weight than the current BSR with the exception detailed
           above. If a router is in P-BSR state, then it uses its own
           weight as that of the current BSR.


> As es result, a C-BSR will see BSMs with a lowered priority from the elected
> BSR only if directly adjacent to it.

> I don't get the point, why to distinguish this special "adjacent C-BSRs" case
> instead of simply ignoring a lowered priority from the elected BSR, time out,
> let the routers in the domain switch to state "Pending BSR" and "Accept Any",
> respectively, and restart the election as it happens in the case of
> non-adjacent C-BSRs. So why not just specifying for routers

> When in C-BSR state:
> Event: Receive Non-preferred BSM
> Action: -> C-BSR state

> (was:
> Event: Receive Non-preferred BSM from Elected BSR
> Action: -> P-BSR state; Forward BSM; Set Bootstrap Timer to BS_Rand_Override
> )

> Second:
> ======
> Why forwarding non-preferred BSMs when in state "Pending BSR"?
> Shortly afterwards, the router itself will send a BSM with a higher priority,
> so forwarding is useless anyway. So why not specifying for routers

> When in P-BSR state:
> Event: Receive Non-preferred BSM
> Action: -> P-BSR state

> (was:
> Event: Receive Non-preferred BSM
> Action: -> P-BSR state; Forward BSM
> )

> Third:
> =====
> As an alternative to first and second above, always forward a non-preferred
> BSMs if they come from the elected BSM router, to quickly restart the BSR
> election:

This is supposed to happen with the present specification (given the
clarification above).

> When in Accept Preferred state:
> Event: Receive Non-preferred BSM from elected BSR

Note that "Receive Non-preferred BSM from elected BSR" is actually
only defined in C-BSR state (because non-preferred is relative to the
local candidate's weight).  With the exception in the definition of a
preferred BSM, this case is already covered.

> Action: -> AP state; Forward BSM; Store RP-Set; Set Bootstrap Timer to
> BS_Timeout; Set SZT to SZ_Timeout

> (was:
> Event: Receive Non-preferred BSM
> Action: -> AP state
> )

> and

> When in P-BSR state:
> Event: Receive Non-preferred BSM from elected BSR or if elected BSR is unknown

By definition, there is no elected BSR in this state.  I believe that
the spec covers all possible events.

> Action: -> P-BSR state; Forward BSM

> (was:
> Event: Receive Non-preferred BSM
> Action: -> P-BSR state; Forward BSM
> )

> I would prefer third.

> Regards, Mark Doll.

> P.S.: BTW, just a nit: In the current draft, it's not explicitly specified,
> that routers in state "Candidate BSR" do not forward non-preferred BSMs from
> other BSRs than the elected BSR. Yes, it's a no-op, so it can be savely
> omitted, but then the other no-op "When in Accept Preferred state, Event:
> Receive Non-preferred BSM, Action: -> AP state", should be omitted, too.

Right.  I'd rather not change that at this late stage, though.

Regards,
Alex


_______________________________________________
pim mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pim