Document: draft-ietf-bfd-base-08
Reviewer: Spencer Dawkins
Review Date: 2008-04-30
IETF LC End Date: 2008-05-07
IESG Telechat date: (if known)

Summary: This document is almost ready for publication as a Proposed Standard.

Comments: I have a small number of review comments that involve 2119 language.

There are a small number of nits reported:

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard

  ** There is 1 instance of too long lines in the document, the longest one
     being 1 character in excess of 72.

  == Missing Reference: 'KEYWORDS' is mentioned on line 48, but not defined

  == Unused Reference: 'KEYWORD' is defined on line 1985, but no explicit
     reference was found in the text

  -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1'

2. Design

   BFD operates on top of any data protocol being forwarded between two

Spencer (clarity): "any data protocol"? I'm not sure what this covers. Later text adds details (network-layer protocols, tunnels, etc), but that text is a LOT later (some as late as "Security Considerations"). Is "any protocol" 
true? (BFD over HTTP? SIP? :-)

   systems.  It is always run in a unicast, point-to-point mode.  BFD
   packets are carried as the payload of whatever encapsulating protocol
   is appropriate for the medium and network.  BFD may be running at
   multiple layers in a system.  The context of the operation of any
   particular BFD session is bound to its encapsulation.

3.1. Addressing and Session Establishment

   A BFD session is established based on the needs of the application

Spencer (clarity): it probably is normal for BFD specifications to call OSPF an application, but it's kind of jarring to me...

   that will be making use of it.  It is up to the application to
   determine the need for BFD, and the addresses to use--there is no
   discovery mechanism in BFD.  For example, an OSPF [OSPF]
   implementation may request a BFD session to be established to a
   neighbor discovered using the OSPF Hello protocol.


3.2. Operating Modes

   Demand mode is useful in situations where the overhead of a periodic
   protocol might prove onerous, such as a system with a very large
   number of BFD sessions.  It is also useful when the Echo function is
   being used symmetrically.  Demand mode has the disadvantage that
   Detection Times are essentially driven by the heuristics of the
   system implementation and are not known to the BFD protocol.  Demand
   mode may not be used when the path round trip time is greater than
   the desired Detection Time.  See section 6.6 for more details.

Spencer (clarity): I know what you're saying here, but would something like "If the path round trip time is greater than the desired Detection time, demand mode cannot detect failures quickly enough, and asynchronous mode must be used" be helpful?

4.1. Generic BFD Control Packet Format

   Your Discriminator

      The discriminator received from the corresponding remote system.
      This field reflects back the received value of My Discriminator,
      or is zero if that value is unknown.

Spencer (clarity): does "unknown" actually happen? Is this more like "if no discriminator has been received yet"?

4.3. Keyed MD5 and Meticulous Keyed MD5 Authentication Section Format

   Reserved

      This byte must be set to zero on transmit, and ignored on receipt.

Spencer (review comment): is this a 2119 MUST? (Note that this text appears several times in the document, while the review comment appears only once
:-)

5. BFD Echo Packet Format

   The payload of a BFD Echo packet is a local matter, since only the
   sending system ever processes the content.  The only requirement is
   that sufficient information is included to demultiplex the received

Spencer (clarity): this sentence is correct as written, but would be clearer to me if it said "... to allow the sender to multiplex the received packet ...".

   packet to the correct BFD session after it is looped back to the
   sender.  The contents are otherwise outside the scope of this
   specification.

6.6. Demand Mode

   Demand mode is requested independently in each direction by virtue of
   a system setting the Demand (D) bit in its BFD Control packets.  The
   Demand bit can only be set if both systems think the session is up.

Spencer (clarity): this doesn't seem quite right to me, because the statement requires that my system knows what the other system thinks. Is it correct to say "a system can only set the Demand bit when a session has transitioned to UP"? It might be preferable to delete the second sentence, because the following text explains this in greater detail, anyway.

   The system receiving the Demand bit ceases the periodic transmission
   of BFD Control packets.  If both systems are operating in Demand
   mode, no periodic BFD Control packets will flow in either direction.

   Note that this mechanism requires that the Detection Time negotiated
   is greater than the round trip time between the two systems, or the
   Poll mechanism will always fail.  Enforcement of this requirement is
   outside the scope of this specification.

Spencer (clarity): you're not describing a requirement, you're describing a constraint. Perhaps "Note that this mechanism will always fail unless the Detection Time negotiated is greater than the round trip time between the two systems", and drop the second sentence?

6.8.1. State Variables

      bfd.LocalDiscr

         The local discriminator for this BFD session, used to uniquely
         identify it.  It MUST be unique across all BFD sessions on this

Spencer (review comment): is this "all active BFD sessions"? (can a discriminator be reused immediately? one Detection Time later? mumble)

         system, and nonzero.  It SHOULD be set to a random (but still
         unique) value to improve security.  The value is otherwise
         outside the scope of this specification.

      bfd.DemandMode

         Set to 1 if the local system wishes to use Demand mode, or 0 if
         not.

Spencer (clarity): is there any text around initialization? (I would have expected "MUST be initialized to zero" if you have to transition to UP before switching to Demand mode)

6.8.3. Timer Manipulation

   When the Echo function is active, a system SHOULD set

Spencer (review comment): any guidance on why a system would violate this SHOULD?

   bfd.RequiredMinRxInterval to a value of not less than one second
   (1,000,000 microseconds.)  This is intended to keep received BFD
   Control traffic at a negligible level, since the actual detection
   function is being performed using BFD Echo packets.

   In any case other than those explicitly called out above, timing
   parameter changes MUST be effected immediately (changing the

Spencer (clarity): is there any difference between "as soon as practical" 
(two paragraphs prior) and "immediately" here?

   transmission rate and/or the Detection Time).

Security Considerations

   Using SHA1 rather than MD5 is believed to have stronger security
   properties.  All comments about MD5 in this section also apply to

Spencer (clarity): "stronger than"? would this be correct if it said "Using
SHA1 is believed to have stronger security properties than MD5"?

   SHA1.