[pim] Gen-ART LC Review of draft-ietf-pim-sm-bsr-10.txt

[Alexander Gall <gall at switch.ch>]

Eric Gray has reviewed the draft on behalf of the general area review
team (thanks for the thorough review, Eric!).  His comments can be
found at
<http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-pim-sm-bsr-10-gray.txt>.
We agreed to discuss his comments on the list.  Please keep him cc'd,
since he is not subscribed to the list.

We (the authors) believe that we probably need another revision of the
draft to address these issues (some more issues have come up during
the secdir review, more on that in a different message).  I have
included my responses to all issues below.  If any of them turn out to
need more discussion, it would proably be better to start them in
separate threads.  AFAICT, no substantial changes to the specification
are required, but a number of clarifications might be in order.

> 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 agree that this would be more logical.  However, my feeling is that
it would not make a significant difference for the reader.  The way it
is now, one would probably just skip the state diagrams in a first
reading of section 3.1.  I'd like to avoid rearranging this section,
but it would be no problem if there is concesus to do so.

> ___________________________________________________________________

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

I try to address this with the changes below.

> ____________________________________________________________________

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

Fair enough.

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

I propose to modify section 3.1.2 as follows (new text before the
transition diagram, new description of NoInfo state, text about how
the other state machine is derived from the one described):

3.1.2.  Per-Scope-Zone State Machine for Non-Candidate-BSR Routers

The following state machine is used for scope zones which are discovered
by the router from bootstrap messages.  A simplified state machine is
used for scope zones which are explicitely configured on the router and
for the global zone.  The differences are listed at the end of this
section.

[transition diagram]

A router that is not a Candidate-BSR may be in one of three states:

NoInfo
     The router has no information about this scope zone.  When in this
     state, no state information is held and no timers run that refer to
     this scope zone.  Conceptually, the state machine is only
     instantiated when the router receives a scoped BSM for a scope
     about which it has no prior knowledge.  However, because the router
     unconditionally transitions to the AA state immediately, the NoInfo
     state can be considered to be virtual in a certain sense.  For this
     reason, it is omitted from the description in section 2.

Accept Any (AA)
     The router does not know of an active BSR, and will accept the
     first Bootstrap message it sees as giving the new BSR's identity
     and the RP-Set.

Accept Preferred (AP)
     The router knows the identity of the current BSR, and is using the
     RP-Set provided by that BSR.  Only Bootstrap messages from that BSR
     or from a C-BSR with higher weight than the current BSR will be
     accepted.

In addition to the three states, there are two timers:

o The Bootstrap Timer (BST) - used to time out old bootstrap router
  information.

o The Scope-Zone Expiry Timer (SZT) - used to time out the scope zone
  itself if Bootstrap messages specifying this scope zone stop arriving.

The initial state for scope zones about which the router has no
knowledge is "NoInfo".

The state machine used for scopes which have been configured explicitely
on the router and for the global scope, which always exists, differs
from the state machine above as follows.

o    The "NoInfo" state doesn't exist.

o    No SZT is maintained.  Hence, the event "Scope-Zone Expiry Timer
     Expires" does not exist and no actions with regard to this timer
     are executed.

The initial state for this state machine is "Accept Any".

> ____________________________________________________________________

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

The timers must obey the constraint given in section 5:

  Note that SZ_Timeout MUST be larger than BS_Timeout, even if their
  values are changed from the defaults.  We recommend that SZ_Timeout is
  set to 10 times BS_Timeout.

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

I believe that, with the constraint above, the FSM is correct as it
stands.  Also note that even with these modifications, it would still
make sense to keep the constraint.

However, I agree that it is somewhat confusing to use a timer "across
states" in this manner.  I think the changes proposed by Eric do not
alter the FSM (with the exception that a scope zone expires one
BS_Timeout period later than with the current spec, but this should be
irrelevant).  Therefore I propose to apply these changes as a
clarification.

> ___________________________________________________________________

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

The event is handled by the C-BSR state machine.  I have discussed
this with Eric and he agrees that it is a non-issue.

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

Fixed.

> ___________________________________________________________________

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

The relevant timer ("Group-to-RP mapping Expiry Timer" or GET) is
mentioned in the action "Store RP-Set" described in section 3.1.5.  I
think the document doesn't actually describe the event when this timer
fires, in analogy to the CGET in section 3.3.  Maybe this should be
included in section 3.6?

> ___________________________________________________________________

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

The state related to the FSM is kept per scope zone, not per BSR (if I
understand the question correctly).  To make this clear, the text on
page 18 could be modified like this:

     Remove BSR state 
          When the Bootstrap Timer expires, all state
          associated with the current BSR is removed (address,
          priority, BST and last BSM, see section 2).  Note that this
          does not include any group-to-RP mappings.

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

No, "Clear State" refers to the entire state kept for the scope zone,
of which the BSR state is a subset.  I agree that this action should
also be documented for clarity and consistency.  I propose to change
the action for the event "Scope-Zone Expiry Timer Expires" in the
AA-state to

-> NoInfo state
Remove scope zone state

and add the following text to section 3.1.5

     Remove scope zone state
          When the Scope-Zone Expiry Timer expires, all state
          associated with the scope zone is removed (see section 2).

This includes the SZT, so I think we don't need the action "Cancel
timers".

> ___________________________________________________________________

--
Alex



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