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?