Alia Atlas' Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS and COMMENT)

["Alia Atlas" <[e-mail]>]

Alia Atlas has entered the following ballot position for
draft-ietf-bfd-seamless-base-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

a) In Sec 7.2.3:  "If the SBFDReflector is generating a response S-BFD
control packet for a local entity that is in
      service, then "state" in response BFD control packets MUST be set
to UP."
    So far, it looked like the SBFDReflector only sends BFD control
packets in response to receiving such packets
    from SBFDInitiators.   This paragraph (not just copied) does not
clearly describe the desired behavior.  If the
   monitored local entity is "temporarily out of service", does the
SBFDReflector respond back to the SBFDInitiator
   with 2 BFD control packets - one indicating UP (as a MUST) and then
the next indicating ADMINDOWN?  Is the
   SBFDReflector expected to store a list of active SBFDInitiators and
proactively send BFD control packets indicating
   ADMINDOWN?   Please clarify in non-trivial detail.

b) Appendix A:  The looping problem is nicely defined but the text still
discusses three potential solutions; clearly the
use of the D bit has been chosen.   It would be much nicer to have the
justification in line, but for this discuss - the
unselected alternatives don't belong.

c) Sec 7.2.1: "   S-BFD packet MUST be demultiplexed with lower layer
information
   (e.g., dedicated destination UDP port, associated channel type)."
  Please add a clear reference to [draft-ietf-bfd-seamless-ip] here to
show where to find the dedicated UDP
port for S-BFD; I think this or some other mechanism needs to be a
normative reference, because I don't see
how one could implement S-BFD without this knowledge.    In particular,
since the format
for an S-BFD control packet is exactly the same as for BFD and since only
this demultiplexing
with lower layer information is used to tell the difference between S-BFD
and BFD packets,
this document requires more specifics.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) In the last paragraph of Sec 4.2: "  Even when following the separate
discriminator pool approach,
   collision is still possible between one S-BFD application to another
   S-BFD application, that may be using different values and algorithms
   to derive S-BFD discriminator values.  If the two applications are
   using S-BFD for a same purpose (e.g., network reachability), then the
   colliding S-BFD discriminator value can be shared.  If the two
   applications are using S-BFD for a different purpose, then the
   collision must be addressed.  How such collisions are addressed is
   outside the scope of this document."

  Sec 4.1 talks about the need for the S-BFD Discriminator to be unique
within an Administrative Domain.
  I don't see any details of that addressed here.   What is addressed
here seems to be the case for multiple
  S-BFD discriminators applying to the same node - which is specifically
discouraged at the end of Sec 3.
  Rather than simply describing the issue as "outside the scope of this
document", please either describe it
  as "future work and multiple S-BFD discriminators is discouraged" or
add a reference.

2) In Sec 6.1: "bfd.SessionType:" is defined but the only possible values
are for SBFD.   Is it possible for a BFD
session to still use the same bfd structure?  I don't see a value for
SessionType there; I'd expect to see at least
a value for the original BFD session and possible an undefined or
unspecified value for future proofing.