Last Call Review of draft-ietf-bfd-seamless-base-08
review-ietf-bfd-seamless-base-08-opsdir-lc-kuarsingh-2016-05-09-00
| Request | Review of | draft-ietf-bfd-seamless-base |
|---|---|---|
| Requested revision | No specific revision (document currently at 11) | |
| Type | Last Call Review | |
| Team | Ops Directorate (opsdir) | |
| Deadline | 2016-05-03 | |
| Requested | 2016-03-23 | |
| Authors | Carlos Pignataro , David Ward , Nobo Akiya , Manav Bhatia , Santosh Pallagatti | |
| Draft last updated | 2016-05-09 | |
| Completed reviews |
Genart Last Call review of -08
by
Dan Romascanu
(diff)
Genart Telechat review of -09 by Dan Romascanu (diff) Secdir Last Call review of -08 by Shawn M Emery (diff) Opsdir Last Call review of -08 by Victor Kuarsingh (diff) |
|
| Assignment | Reviewer | Victor Kuarsingh |
| State | Completed | |
| Review |
review-ietf-bfd-seamless-base-08-opsdir-lc-kuarsingh-2016-05-09
|
|
| Reviewed revision | 08 (document currently at 11) | |
| Result | Has Issues | |
| Completed | 2016-05-09 |
review-ietf-bfd-seamless-base-08-opsdir-lc-kuarsingh-2016-05-09-00
Dear Authors,
I have reviewed this document as part of the Operational
directorate's ongoing effort to review all IETF documents being
processed by the IESG. These comments were written with the intent
of improving the operational aspects of the IETF drafts. Comments
that are not addressed in last call may be included in AD reviews
during the IESG review. Document editors and WG chairs should treat
these comments just like any other last call comments.
Document Reviewed - Host address availability recommendations
Link to Document -
https://tools.ietf.org/html/draft-ietf-bfd-seamless-base-09
Summary:
The document defines the based protocol specification for Seamless
Bidirectional Forwarding Detection (S-BFD). The S-BFD mechanism is
aimed at providing a simplified way to enable BFD by removing many
of the negotiation aspects that are found in the original protocol
(BFD as defined in RFC5880)
The optimizations provided as part of S-BFD is realized by
shortening the time between when a network node wishes to perform a
continuity test, and the needed protocol actions to accomplish the
test.
General Comments and Feedback:
In general, the document is well written and has already gone
through considerable review. Since this new version of BFD (S-BFD)
will likely operate in mix-mode deployments along with BFD
(RFC5880), the operational aspects, co-existence aspects were
reviewed to ensure that implementations will not intrinsically cause
issues.
The authors did provide consideration co-existence and operational
text. Section 7.1, for example, provides demultiplexing procedures
to ensure packets are evaluatedf correctly. Section 8 provides good
operational considerations for S-BFD.
I do have some review questions I would like the author team to
comment on, to ensure the operational aspects were covered. It's
possible the intended texts addresses these question, however a
response is appreciated for clarity.
Review Questions (operational aspect view)
<< Item 1 >>
Section 4.1 notes that uniqueness of a discriminator "MUST" be
unique within an administrative domain. Would you consider this to
be true even for a anycast service where you may have multiple nodes
which can potentially use the same IP address for a given service?
In such a case, would a common discriminator be potentially used
where the user may desire that from a given initiator, one or more
responder can provide continuity to that service (IP address)? I
may have missed the point, so thought I would ask for operational
clarity. is seems the optional stateless nature of S-BFD would lend
itself to this use case.
<< Item 2 >>
Section 3, notes that using multiple S-BFD discriminators is
"discouraged" until a mapping capability is defined. Given the
potential operational issues here, would this not be better note as
as MUST NOT or SHOULD NOT? This would then help ensure
implementations avoid such options. I would think a subsequent
document (which updates this specification) could then update the
MUST/SHOULD NOT.
<< Item 3 >>
Section 10 notes that spoofed packets can occur on S-BFD echos. In
addition to an echo function potential issue, would this not be
considered a security consideration as well?
Textual Review
Abstract - ok
Introduction
par1 << old text >> ".. and related documents, has
efficiently..."
<< suggested >> ".. and related documents, have
efficiently.."
par2 << old text >> " ..a rather simplified and largely
stateless infrastructure for continuity testing."
<< questions >> would this not more appropriately say
".. a rather simplified and optionally stateless infrastructure.."?
The S-BFD stateless operation seems to be optional. Not a
considered an object, just seems like that's a better reflection of
this point.
par3 << old text >>".. DOWN to UP are virtually
nonexistent" may be better reflected as "... DOWN to UP are greatly
optimized." (or "reduced").
Section 3: Seamless BFD Overview
par2. << old text >> "Once above setup is complete .."
to "One the above setup is complete.."
Section 4.1
par1. << old text >> "One important characteristics.. "
to "One important characteristic.."
Section 4.2
par3. << old text >> ".. values for entities,
listened by SBFDReflector.." Did you mean to say "learned" here?