Authors,
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call
comments you may receive.
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).
___________________________________________________________________
Thanks!
--
Eric Gray
Principal Engineer
Ericsson
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
