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

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:

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

DW: Yes, PS.

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

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.

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

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.

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

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.

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

DW: This seems a style choice.

Many thanks for your thorough review.

-DWard
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf