Subject: [pim] Comments on draft-ietf-pim-sm-bsr-03.txt

From: James Lingard <[email-masked]>
Date: Mon, 21 Jun 2004 17:19:59 +0100

Hi,

I have the following comments on the last version of the BSR draft.  I don't
know at what stage of production the next version of the draft is, but I
hope that at least some of my suggestions will be able to make their way
into it.

Since there are rather a lot of comments, I've grouped them into four
categories:

- Major comments
- Other substantial comments
- Editorial comments
- Minor editorial comments (typos, etc.)

If anything is unclear, or if you require any further clarifications, please
let me know.

Thanks,
James.

==========================================================================
Major Comments (in rough order of importance)
==========================================================================

Semantic fragmentation
----------------------

1) The document needs to distinguish more clearly between a single PIM
   control packet of type 4, and the collection of such packets from the
   same BSR with the same Fragment ID.  At the moment, the document calls
   the former both a "Bootstrap message", a "semantic fragment" and a
   "BSMF", while the latter is called a "Bootstrap message".  My comments
   are:

   - Consistent, unambiguous terminology should be used throughout.  I
     suggest "semantic fragment" and "Bootstrap message" respectively for
     the cases above - and I have used this terminology in the rest of
     this mail.

   - The concepts and terminology relating to semantic fragmentation of
     Bootstrap messages should be introduced in section 1 of the document,
     not in section 4, because much of sections 2 and 3 depend on it.

2) It is not clear how semantic fragmentation interacts with the rest of
   the protocol, for example the state machines.  The events in the state
   machines are described in terms of receiving Bootstrap messages.
   However, I assume this actually means semantic fragment (since we can
   never know when we've received a complete Bootstrap message).

3) Using semantic fragmentation to separate Bootstrap messages for
   different admin scopes complicates the description of the protocol
   further.  I suggest simplifying things by mandating that a different
   Fragment Tag be used for any semantic fragments that belong to
   different admin scopes.  Therefore, a single Bootstrap message would
   apply to a single admin scope.

---

Some questions about the mechanics of fragment reassembly.  Please could
you clarify the document to answer these questions.

- How long should a BSMF be held pending receipt of another BSMF necessary
  to complete the group-prefix information in the first BSMF?

- Do we carry out actions in the state machines on receiving a BSMF even
  if we have to wait for matching BSMFs to arrive for some or all
  group-prefixes?

- What should a router do if while waiting for a subsequent BSMF it
  receives another BSMF from the same BSR for the same admin scope with a
  different Fragment Tag?  Discard the old BSMF?

- How does this interact with the storing of Bootstrap messages for
  forwarding to new neighbors?  Do we throw away the stored Bootstrap
  message every time we receive a new one (for the same admin scope) with
  a different Fragment Tag?  This would mess things up if the second
  Fragment Tag is actually an older one arriving out of sequence.

---

The document is inconsistent in its description of the purpose of semantic
fragmentation.  Is its purpose

- to prevent IP fragmentation being done on Bootstrap packets larger than
  the link MTU size (as suggested by section 4.1.1), or

- just to handle Bootstrap messages larger than the maximum IP packet size
  (as suggested at the start of section 4.1).

If the former, then routers that forward Bootstrap messages potentially
need to perform semantic fragmentation of the packets they forward, which
isn't stated anywhere in the draft.

Relationship of BSR with BIDIR-PIM
----------------------------------

Assuming that the relationship of BIDIR-PIM with BSR is within the scope of
the document:

- the draft should be renamed to make it not Sparse Mode specific, and
  references to PIM-SM should be replaced with PIM

- the draft needs a discussion of how the BIDIR bit is to be used in
  C-RP-Adv and Bootstrap messages

- the draft needs to explain how Bootstrap Routers resolve conflicts
  between group ranges advertised for BIDIR and SM in different C-RP-Adv
  messages, and how other routers resolve such conflicts in received
  Bootstrap messages.

Bootstrap messages originated by a new Bootstrap Router
-------------------------------------------------------

This may be due to a misreading on my part, but the draft seems to imply
that when a new Bootstrap Router is first elected, its Bootstrap messages
will have an empty RP-Set (since it will not yet have received any
C-RP-Adv messages).  This would break all routing temporarily until the
new BSR sends another Bootstrap message, as the empty RP-Set would replace
the RP-Set previously in use by the recipients.  Is there intended to be
a mechanism for either

- new Bootstrap Routers to send Bootstrap messages that are non-empty (for
  example, do they send out the same RP-Set that they received from the
  previously elected Bootstrap Router?)

- recipients of a Bootstrap message from a newly elected Bootstrap Router
  to continue to use the RP-Set advertised by the previously elected
  Bootstrap Router?

Administrative scoping and RP election
--------------------------------------

How does administrative scoping interact with RP election?  Some
questions, which don't seem to be clearly answered by the draft.

- Does a C-RP send the same C-RP-Adv messages to each elected BSR?  Or
  does it restrict the contents of the C-RP-Adv message sent to a scope
  zone's BSR to contain only group-ranges contained within (or
  intersecting?) the scoped range?

- When a router does a group-to-RP lookup for a group within a scoped
  range, how exactly does this work?  Is the algorithm in the PIM-SM
  specification applied to the union of all RP information received from
  all elected BSRs?  Or is a longest-prefix match performed on the
  administrative scope zone ranges first, and only those RPs received in
  the Bootstrap message from the longest matching scope zone's BSR used?

Accepting unicast messages at startup
-------------------------------------

The pseudo-code for checking received Bootstrap messages (section 3, page
15) says

   if (Any previous BSM for this scope has been accepted)
   ...

This in strictly unimplementable in its present form, since it would
require the router to store the list of scopes for which it had recevied
a BSM indefinitely, resulting in a memory leak.  There is also the problem
of how this would interact with semantic fragmentation, as the router
needs to accept every fragment of the message, not just the first.

I would suggest a simple timer-based mechanism instead.

Candidate-RP Holdtime
---------------------

Why is the RP Holdtime transmitted in Bootstrap messages?  There doesn't
seem to be any reason for it at all.  In fact, why does the Bootstrap
Router even need to store the RP Holdtime, since it should only be used on
receipt of a C-RP-Adv message to initialize the C-RP Expiry Timer?

If the RP Holdtime field is present purely for backwards compatibility then
the document should explicity say so, to prevent readers from wasting time
trying to work out its intended use.

Timer values
------------

In section 5 (Default Values for Timers), we should be clear about which
timer
durations

- are configurable, with a fixed default

- are configurable, with a default which is based on the current values of
  other timer durations

- are REQUIRED to be determined in terms of other timers.

In particular, there are a couple of inconsistencies between section 5 and
the
rest of the document.

- Section 3 (page 16) says that BS Timeout defaults to "2 times the BS
Period
  plus 10 seconds, which is 130 seconds".  Section 5 (page 29) says that the
  value of BS Timeout is "2 * BSPeriod + 10 seconds".

- Section 3 (page 17) says that SZ Timeout defaults to "ten times the BS
  Timeout, which is 1300 seconds".  Section 5 (page 30) says that the value
  of SZ Timeout is 1300 seconds.

============================================================================
===
Other Substantial Comments (in document order)
============================================================================
===

Section 3, page 11.  The Candidate-BSR state machine is missing the event
'reveive non-preferred BSM from a router that isn't the Elected BSR', when
in the C-BSR state.  Presumably the action is simply to stay in the C-BSR
state (and not forward the message, and not restart the BS Timer).

Section 3, page 13.  In the Non-Candidate-BSR state machine, when is the
SZ Timer restarted?  Presumably this should happen every time the BS timer
is restarted.

Section 3, page 15.  The list of 'BS State-machine Transition Events' is
missing descriptions of several other events.

Section 3, page 17/18.  When forwarding or originating a Bootstrap
message, the source IP address of the message should be the *primary* IP
address on the interface, as used with the PIM Hello protocol.

Section 3, page 18.  The unicasting of Bootstrap messages to new neighbors
should also be done when the neighbor's GenID changes, and should be done
for the Bootstrap messages for each Elected BSR.

Section 3.1, page 19.  Does a Bootstrap Router issue a triggered Bootstrap
message when it receives a C-RP-Adv message with a Holdtime of 0?  This
section implies that this is the case, but this isn't mentioned anywhere
else in the document.

Section 3.2, page 19.  Is all C-RP state deleted on receipt of a new
C-RP-Adv message with the same RP Address?  Or is the old state kept as
well until its Holdtime has expired?  If the former, is there any way for
a C-RP to split C-RP state across multiple C-RP-Adv messages?

Section 3.4, page 21.  I assume the intention of this section is to say
that whenever a new RP-Set is receieved, for each group for which there is
PIM state, if the RP that would be computed using the new RP-Set is
different from the RP that was computed using the old RP-Set, the new RP
should be used by PIM for that group.  However, this isn't what it says.
For example, if the same collection of RPs appear in the new RP-Set but
with different priority values, or if a new RP with a higher priority or a
more specific prefix match is received, the algorithm described in this
section won't tell you to use the new RP.

Section 4.1, page 25.  What BSR Address should be used when originating a
Bootstrap message?  Does it have to be the primary address on a PIM
interface?  I believe it can be any of the router's non-local unicast
addresses, but it's worth saying.

Section 4.1.1, page 26.  Semantic fragmenation is only strictly necessary
for packets over the maximum IP packet size, not the link MTU as stated in
this section, since we could let the IP stack perform IP fragmentation.

Section 4.2, page 28.  Is there an upper limit on the size of a
Candidate-RP-Advertisement message?

==========================================================================
Editorial Comments (in document order)
==========================================================================

Section 2, page 9.  This section is missing various pieces of state that
need to be stored, for example those mentioned in section 3.2.

Section 2, page 9.  Note that 'Per Scope Zone' also includes the global
scope.

Section 2, page 10.  It's confusing to have timers separated from other
state.

Section 3, page 13.  In the 'Receive BSM for unknown Admin Scope' event of
the Non-Candidate-BSR state machine, the phrase 'for unknown Admin Scope'
is redundant, since by definition the admin scope is unknown if we're in
the NoInfo state.  (Compare the PIM-SM draft, where the events don't say,
for example, 'Receive Join(*,G) for unknown G'.)

Section 3, page 15.  The meaning of each of the terms in the pseudo-code
should be explained briefly.

Section 3, page 16.  It seems rather odd to have the algorithm for
'randomized override interval' in the body of the text.  Perhaps this
should be moved to an appendix, or to the timers section (section 5).
Also, an explanation of the rationale behind the algorithm would be
interesting.

Section 3, page 18.  Sending Bootstrap messages by unicast to new
neighbors seems like quite a significant protocol element to be tucked
away at the end of this section and not really mentioned anywhere else.

Section 3.1, page 19.  When we say that 'zero is the highest possible
priority' we should explain that this means in general that lower priority
values mean higher priority.  It's explained clearly on the following
page, but not here.

Section 4, page 23.  Why explicitly specify the size of the Mask Len
field, but not any of the other fields?

Section 4.1, page 25.  In the description of the Group Address field, we
should also state that the Admin Scope bit may _only_ be set in the first
group address field of a semantic fragment.

==========================================================================
Minor Editorial Comments (typos, etc.)
==========================================================================

The following pieces of terminology are used inconsistently throughout the
document, with respect to capitalization, punctuation and abbreviations.
These are listed as (suggested versions | synonyms):

- Bootstrap message; BSM | Bootstrap Message; BSR message; BS message
- C-RP-Advertisement; C-RP-Adv | C-RP advertisement
- RP-Set | RPset; RP Set
- BSR Priority | BSR priority; BSR-priority
- RP Priority | RP priority
- Candidate-RP; C-RP | candidate-RP; Candidate RP; candidate RP
- Holdtime | HoldTime
- PIM Sparse Mode | PIM Sparse-mode
- state machine | state-machine

Simple typos (please let me know if you need more context):

- Section 1.1, page 5,  last para.    s/them/then/
- Section 1.1, page 5,  last para.    s/the/be/
- Section 3,   page 15, pseudo-code.  s/if ( (Any/if (Any/
- Section 3.1, page 19, second para.  s/must/MUST/
- Section 4,   page 21.  s/4  Bootstrap Message/4  Bootstrap/
- Section 4.1, page 25.  s/BSR priority priority/BSR priority/
- Section 4.1, page 25.  s/Unicast BSR Address/BSR Address/
- Section 4.1, page 26.  s/Frag RP-Cnt/Frag RP Cnt/
- Section 6.3, page 32, second para.  s/principle/principal/
- Section 6.3, page 32, third para.   s/BootStrap/Bootstrap/
- Section 6.3, page 32, last para.    s/than/that/

Other simple editorial errors:

- Section 2, page 9/10.  Inconsistent bulleting style.

- Section 3, page 15. "or the router must have no BSR state"
  Should say: "no BSR state for that admin scope"

- Section 3, page 16. "setting the BS timer"
  Should say: "setting the BS timer and SZ timer"

- Section 3.2, page 19.  "If the router is not the elected BSR"
  Should say: "if the router is not the elected BSR for any scope zone"

- Section 4.1, page 25.
  Missing newline between "Type" and "PIM Message Type".

- Section 4.2, page 28.  Should use "Prefix Count" not "Prefix Cnt".

- Section 5, page 29.  "Period between bootstrap messages".
  Should say: "Period between originating bootstrap messages"

- Section 5, page 30.  Table headings messed up.

---
James Lingard
Data Connection Ltd (DCL)
http://www.dataconnection.com/

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim