Document: "Bootstrap Router (BSR) Mechanism for PIM" 
		(draft-ietf-pim-sm-bsr-10.txt)

Reviewer: Eric Gray

Review Date:  March 8, 2007

IETF LC End Date: March 8, 2007

IESG Telechat date: Unknown

Summary: This draft still needs some fine tuning before it will
be ready to publish as a Proposed Standard.

Comments:

The document is generally well written but might have been better
organized.  In particular, in sections describing the BSR State
machines, it would have been easier to follow information in the 
state table if states, events and actions were described first.

I have several comments on the state-machines themselves - in 
particular on the state machine for non-BSR-candidates.
___________________________________________________________________

In the description of state information on page 10, there is no
mention of the state "NoInfo" for non-candidate BSRs.  I know
that this "state" corresponds to an absence of state information
for any non-candidate BSR in a administrative zone about which it
knows nothing, but this may be confusing since later (page 14) in
the document you describe 3 states ("NoInfo", "Accept Any" and
"Accept Preferred").

If the document is not re-oranized, it would be useful to add a
note to explain esentially that the "state" NoInfo litterally
corresponds to a non-existent state-machine with respect to a
non-candidate BSR in a given adminsitrative zone for which it 
has no configured information.
____________________________________________________________________

Part of the issues with the description of the non-candidate BSR
state machine is that it is a casual merging of two different FSM
- one for administrative zones about which information is configured
or the non-scoped zone (in which the "NoInfo" state does not exist),
and another for administratively scoped zones about which the non-
candidate BSR might learn.

It would help if this was explicitly stated prior to providing the
state machine description.
____________________________________________________________________

In events tables for both the "Accept Any" and "Accept Preferred" 
states, the "Receive Preferred BSM" event results in leaving
the non-candidate BSR in the "Accept Preferred" state with the 
Scope-Zone timer set to "SZ_timeout".

With the default setting of 1300 seconds - in combination with the
default setting for BS_Timeout (130 seconds) - it SHOULD never be
the case that an "SZ_Timeout" event will occur while the FSM is in
the "Accept Preferred" state.  But that is not obvious without the
extra step of comparing the timer values.

Also, in the parlance, it relies on fall-through behavior that may
not be guaranteed.

To clarify the state machine, as well as to ensure that the FSM is
able to properly deal with events that might occur independent of
actual timer values used, I would suggest the following changes:

o	In "Accept Any", when receiving a preferred BSM, the FSM
	clears the SZ Timer, resets the bootstrap timer, stores the
	RP-Set and transitions to "Accept Preferred."
o	In "Accept Preferred", no action is taken with respect to
	the SZ Timer, when receiving a preferred BSM (everything
	else stays as it is in the text now).
o	In "Accept Preferred", when the bootstrap timer expires,
	set the scope zone timer to "SZ_timeout", clear the boot-
	strap timer and transition to "Accept Any."

Otherwise, it might be necessary to include the appropriate expiry
events in the tables for these two states.
___________________________________________________________________

The interesting event "Receive Non-preferred BSM from Elected BSR"
- described on page 16 - is not included in any state-machine 
description.  I assume it is not ignored.  Did I miss where the
actions and transitions are explained?

Also, NIT, in the description of this event, "has lower weight 
that the ..." should probably be "has lower weight than the ..."

___________________________________________________________________

I do not understand something about the action "Refresh RP-Set"
as included in FSM descriptions and described on page 18.  What
timer causes the group-to-RP mappings to expire?  Did I miss a
timer somewhere?
___________________________________________________________________

I do not understand something about the action "Remove BSR State"
as included in FSM descriptions and described on page 18.  What
BSR state does this refer to, given that this is an action that
is included in the actions taken in transitioning from "Accept
Preferred" to "Accept Any" (the state itself being part of the
BSR State being removed)?

I suspect this might be the appropriate action for the transition
from "Accept Any" to "NoInfo" (where it currently has "Clear State"
- interestingly enough, not an actions described on page 18, or -
near as I can tell - anywhere else).
___________________________________________________________________