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

From: Mark Doll <[email-masked]>
Date: Mon, 14 May 2007 22:30:59 +0200

Hi!

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?

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:

When in Accept Preferred state:
Event: Receive Non-preferred BSM from elected BSR
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
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.

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

---

From: Alexander Gall <[email-masked]>
Date: Wed, 23 May 2007 17:15:02 +0200

[ Cc'd Stig ]

Mark,

Sorry for the late response.

> elected BSR (and switch to state P-BSR), but routers in state "Accept

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.

> BSMs if they come from the elected BSM router, to quickly restart the BSR

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

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

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

> 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

---

From: Mark Doll <[email-masked]>
Date: Thu, 24 May 2007 11:19:06 +0200

Hi Alexander!

>            weight as that of the current BSR.

Thanks for your clarification. That makes sense and I think, too, all cases
are covered by the current spec. Nevertheless, I'm not shure, if your proposed
pointer to the exception is really clear enough. Maybe explicitly saying that
Receive Non-Preferred BSM (+) Receive Preferred BSM = Receive BSM? So maybe:

      Receive Non-preferred BSM
           A Bootstrap message other than a preferred Bootstrap message is
           received. That is a message from a BSR with a 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.

Mark.

---

From: Alexander Gall <[email-masked]>
Date: Fri, 25 May 2007 10:18:18 +0200

>            in P-BSR state, then it uses its own weight as that of the current

I'm not sure this is clearer :-/ How about this self-contained
version:

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

--
Alex

---

From: Mark Doll <[email-masked]>
Date: Fri, 25 May 2007 10:50:11 +0200

>           a router is in P-BSR state, then it uses its own weight as

Yes, that's fine.

Thanks again, Mark.