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
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf