Stig,
These should be considered in the same vein as any other
Last Call comments, you might receive. In particular, you may
want to note that I did not post these on the PIM mailing list.
You may wish to include them - with others - in separate mail
to the mailing list, or you may want me to re-post them to the
PIM mailing list.
I do not usually post them on the working group mailing
list if I am not a subscriber to that list as it often turns
out that people assume that - because I made last call comments
- they can respond to them on the list and I'll see them there.
I struggled with these comments however as it is fairly
clear that they may be thought both substantive and contentious.
If you (authors) choose to discuss these comments on the PIM
list, that's fine with me as long as nobody is expecting me to
respond to them unless I am explicitly copied on them. If you
would prefer me to re-post these to the PIM mailing list, I can
do so ("the authors asked me to repost these Last Call comments
on this list, please explicitly copy me on any responses you'd
like me to address, etcetera, etc.").
Thanks!
--
Eric Gray
Principal Engineer
Ericsson
> -----Original Message-----
> From: Stig Venaas [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 12, 2007 9:56 AM
> To: Eric Gray (LO/EUS)
> Cc: James Lingard; Alexander Gall; Nidhi; Bill Fenner;
> [email protected]
> Subject: Re: Gen-ART LC Review of draft-ietf-pim-sm-bsr-10.txt
> Importance: High
>
> Eric Gray (LO/EUS) wrote:
> > 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).
>
> Thanks for the thorough review.
> >
> > Please resolve these comments along with any other Last Call
> > comments you may receive.
>
> I don't have time to respond properly to this now, but I think
> we need a new revision where we hopefully can address all your
> issues. One of us authors should give you a proper response
> soon.
>
> Stig
>
> >
> >
> > 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
