Subject: Gen-ART Review of draft-ietf-bfd-base-08

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 1 May 2008 23:41:42 -0400

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

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

---

From: David Ward <[email-masked]>
Date: Wed, 7 May 2008 10:54:21 -0500

Spencer -

Thanks a ton for reading the doc and giving us your feedback. I have  
a few replies inline.

On May 1, 2008, at 10:41 PM, Spencer Dawkins wrote:

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

DW: Yes, PS.

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

DW: In fact, it is flexible enough to run w/o IP (see VCCV's use of  
BFD). Architecturally the answer is yes. Practically the answer is of  
course no. Given the realities of how BFD is currently being used,  
clarifying the sentence would seem to add more confusion than leaving  
it as-is.

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

DW: Although jarring, it is correct. The bootstrapping application  
can be IGPs, manual config, DHCP, etc. The most generic terms seems  
appropriate ... even though I agree that routing protocols are very  
special applications.

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

DW: I'd prefer not to make it a MUST as one could (unfort) have to  
increase the desired Detection Time. It's a tradeoff in deployment.  
More packets/cycles vs potentially longer Dectection Time. Thankfully  
there are adaptive timers.

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

DW: It is nice and generic and covers "not received."

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

DW: We should scan for proper use of 2119 which is really easy to  
miss w/ reading fatigue.

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

DW: We aren't multiplexing in the rx direction ... we are  
demultiplexing.

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

DW: This appears to be a style comment on "is up" vs "has  
transitioned to UP," right?

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

DW: What we are trying to state is that BFD cannot keep an operator  
from making a configuration error. There is a constraint due to  
physics and a requirement that it be adhered to and ... BFD can't  
stop anyone from doing something stupid. "Enforcing the requirement  
to meet the constraint ..." may be clearer language although a nit.

> discriminator be reused immediately? one Detection Time later? mumble)

DW: Reuse is discussed later. And yes ... all sessions.

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

DW: It wouldn't be paid attention to given it is only checked once UP

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

DW: Architectural flexibility and both of us have  decades of  
experience of guessing the wrong defaults and making things  
unnecessarily a MUST

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

DW: Yes, two paras above the example given is:

"In other words, the local system cannot
    wait longer than the new interval between the previous packet
    transmission and the next one.  If this interval has already passed
    since the last transmission (because the new interval is
    significantly shorter), the local system MUST send the next periodic
    BFD Control packet as soon as practicable."

Basically it is stating you could have reduced the interval such that  
it was missed ...

The following "immediately" paragraph describes all non exception  
events (that were dealt with in the preceding paragraphs).

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

DW: This seems a style choice.

Many thanks for your thorough review.

-DWard

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 7 May 2008 13:26:09 -0500

David,

	I agree with Spencer on the point of "system thoughts"
verses "system states."  This may appear to be a style issue,
but it is actually simply a matter of trying to be as precise
as the language allows.  Who knows what a system "thinks"?
But it should be clear if a system is in an appropriate state.

	On the next issue, I don't understand your argument: are
you saying that you believe it is necessary to explicitly say
that "defending against operator error is out of scope"?

	Finally, Spencer's (last?) comment on use of "stronger"
is (again) not a stylistic one, but an attempt to squeeze the
little bit of precision that can be achieved in English.  It
is apparent that you believe you are saying "Using SHA1 is 
believed to have stronger security properties than MD5" (as
indeed is suggested by Spencer), but you are not (exactly).
Change the statement to "drinking milk, as opposed to chewing
rocks, leads to stonger bones" and you will see that what you
have said makes no explicit comparison between SHA1 and MD5 
(or milk and rocks, in my example).  Because the statement is
already in passive voice (whose belief is this?), and is vague
enough as it is, then we should try to fix as much of it as we 
can.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
  --- [SNIP] ---

> to meet the constraint ..." may be clearer language although a nit.
  --- [SNIP] ---

> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art
>

---

From: David Ward <[email-masked]>
Date: Wed, 7 May 2008 13:33:48 -0500

Eric -

> But it should be clear if a system is in an appropriate state.

DW: Sorry, which comment is this in reference to?

> that "defending against operator error is out of scope"?

DW: Given we are talking about laws of physics and we have seen  
implementation and deployment issues, it seemed worthy of not  
removing the statement in this instance.

> enough as it is, then we should try to fix as much of it as we

DW: Finessing this sentence isn't an issue. Rocks for breakfast?

-DWard