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

From: "Eric Gray \(LO/EUS\)" <[email-masked]>
Date: Thu, 8 Mar 2007 10:26:40 -0600

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-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Eric Gray \(LO/EUS\)" <[email-masked]>
Date: Mon, 12 Mar 2007 14:09:30 -0500

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-masked]] 
> Sent: Monday, March 12, 2007 9:56 AM
> To: Eric Gray (LO/EUS)
> Cc: James Lingard; Alexander Gall; Nidhi; Bill Fenner; 
> [email-masked]
> Subject: Re: Gen-ART LC Review of draft-ietf-pim-sm-bsr-10.txt
> Importance: High
> 
> Eric Gray (LO/EUS) wrote:
> > Authors,
> > 
> Thanks for the thorough review.
> > 
> 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
> 
> > 
> >

---

From: Stig Venaas <[email-masked]>
Date: Mon, 12 Mar 2007 09:55:37 -0400

Stig

---

From: Alexander Gall <[email-masked]>
Date: Tue, 13 Mar 2007 11:20:30 +0100

Hello Eric

> like me to address, etcetera, etc.").

Yes, I think the issues you've raised should be discussed on the
mailing list. I'd be grateful if you could repost them there.

Thanks,

--
Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Mar 2007 15:14:39 +0100

Alex,

You can also post a pointer to
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-pim-sm-bsr-10-gray.txt

All gen-art reviews are posted to that directory.

    Brian

---

From: Alexander Gall <[email-masked]>
Date: Tue, 13 Mar 2007 16:34:02 +0100

Brian,

> All gen-art reviews are posted to that directory.

Thanks, I wasn't aware of that.  

Eric, I will post this pointer to the list and start the discussion
there (copying you only for issues where we'd like to have your
input). 

--
Alex

---

From: Alexander Gall <[email-masked]>
Date: Wed, 14 Mar 2007 13:55:27 +0100

Eric,

> actions and transitions are explained?

This event is referenced in the C-BSR FSM on page 11.  It triggers a
transition from C-BSR state to P-BSR state.

--
Alex

---

From: "Eric Gray \(LO/EUS\)" <[email-masked]>
Date: Wed, 14 Mar 2007 11:27:47 -0500

Alex,

	Thanks, I missed that.  But, now that I see how it is meant
(in what context), I wonder that the same action is not expected
if a C-PSR receives a Non-Preferred BSM from a P-BSR.  Or is it
the case that the P-BSR state is so temporary that a C-BSR would
treat a likely P-BSR as if it is already the elected BSR?

	When I read the event, I was not clear on the context - i.e.
- "non-preferred" with respect to what?  If the "non-preferred" is
with respect to the local C-BSR, then I think it should also be an
argument that the same transistion (C-BSR -> P-BSR) should apply 
in receiving a non-preferred BSM from a current P-BSR.

	This is pretty murky, since we appear to be trying to guess
the transition that should be occuring in a peer.  Does the elected
BSR that sent the non-preferred BSM know that it is no-longer the
elected BSR, or is that transition assumed to take place when it 
receives a reciprocal (assumed symmetric) preferred BSM from the 
local BSR?  Would the same apply if that BSR were still in the 
temporary P-BSR state?

	Possibly these things are clear to people who've followed the
discussion-history, but the answers to these questions don't jump 
out at me...

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> From: Alexander Gall [mailto:[email-masked]] 
> Sent: Wednesday, March 14, 2007 8:55 AM
> To: Eric Gray (LO/EUS)
> Cc: Stig Venaas; James Lingard; Nidhi Bhaskar; Bill Fenner; 
> [email-masked]

---

From: Alexander Gall <[email-masked]>
Date: Thu, 15 Mar 2007 11:57:48 +0100

[ Changed Nidhi's address ]

Eric,

> treat a likely P-BSR as if it is already the elected BSR?

The event can only occur in C-BSR state, because that is the only
state in which the router considers a different router to be the
elected BSR.  When in P-BSR state, it considers itself to be the BSR
with highest weight but only originates a BSM when it transitions to
the E-BSR state.  When a BSM is received, the local router knows that
the originating router considered itself to be the elected BSR.

> with respect to the local C-BSR, then I think it should also be an

Yes, for this event, "non-preferred" is with respect to the local
C-BSR (this is explained in section 3.1.4).

> in receiving a non-preferred BSM from a current P-BSR.

There is no notion of a "current P-BSR" (see above), but I know what
you mean (the router receives a BSM from a router that is not the
currently elected BSR, which can happen, of course).  In that case,
the weight is compared with that of the elected BSR, not the one of
the local C-BSR, which is lower than the latter by definition.  

If the weight is lower, the new BSM is considered to be non-preferred
and is ignored.  This event is omitted from the state table because it
triggers no action.

If the weight is higher, the originator of this BSM becomes the
elected BSR.

In both cases, the local router remains in the C-BSR state.

> local BSR?  

I don't think any assumptions are necessary.  At any point in time,
there is a strict ordering within the set of candidate BSRs according
to their weight.  The state machine must guarantee that the router
with highest weight eventually starts flooding its BSMs, which will
cause all other routers to enter C-BSR state and stay there.  

In this particular case, when the priority of the elected BSR is
lowered in such a manner that a different C-BSR now has higher weight,
that router will start flooding BSMs.  These BSMs will be considered
to be preferred by the former elected BSR which will then transition
to C-BSR and stop sending BSMs.

If you find a scenario, in which the C-BSR with highest weight remains
in the C-BSR state indefinitely, that would be a problem.

> Would the same apply if that BSR were still in the 
> temporary P-BSR state?

> discussion-history, but the answers to these questions don't jump 

Essentially, we convinced ourselves (and the WG), that the state
machine does indeed cover all cases, although not in a formal manner.

This has not been the subject of discussion for a long time.  There
also exist various implementations of this specification which did not
reveal any problems so far.

I hope my explanations above helped to make things clearer.

--
Alex

---

From: "Eric Gray \(LO/EUS\)" <[email-masked]>
Date: Thu, 15 Mar 2007 09:11:26 -0500

Alex,

	Based on your previous response on this specific question, and
- especially - in combination with the additional clarification you've
provided below, I am satisfied that the question I had about receiving 
a non-preferred BSM from the elected (or pending) BSR is a non-issue.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Thursday, March 15, 2007 6:58 AM
> To: Eric Gray (LO/EUS)
> Cc: Stig Venaas; James Lingard; [email-masked]; Bill 
> Fenner; [email-masked]
> Subject: RE: Gen-ART LC Review of draft-ietf-pim-sm-bsr-10.txt
> Importance: High
>