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