Hi!
This is a nice and short document. In fact it is so short that I wonder why it
isn’t just part of draft-ietf-bfd-seamless-base. Besides indicating specific
addresses/port numbers to use, there is no significant
transport-protocol-specific contribution beyond what is already in the base
document.
Please consider merging this document into draft-ietf-bfd-seamless-base. I
will keep this document in AD Evaluation (and not return it to the WG) at least
until a decision has been made.
Thanks!
Alvaro.
Major:
1. Nowhere in this document (or draft-ietf-bfd-seamless-base) is congestion
mentioned. There is very little in rfc5881 (and nothing in rfc5884) that adds
to what rfc5880 covers, which makes me think that a generic approach might be
better (i.e. in draft-ietf-bfd-seamless-base). Are there new
congestion-related transport-protocol-specific considerations that arise when
using S-BFD? Please include some text indicating any congestion issues — or at
least explaining why there aren’t any new ones.
Minor:
1. Section 4. (S-BFD Control Packet Demultiplexing). The process described
here doesn’t match what is specified in Section 7.1. (Demultiplexing of S-BFD
Control Packet) of draft-ietf-bfd-seamless-base.
2. I think that Section 5.2. (Target vs. Remote Entity (S-BFD
Discriminator)) needs to be clarified.
* “…to perform a continuity test towards a target but to a transit
network node.” I think there might be a “not” left out somewhere, maybe you
meant “…to not perform a continuity test towards a remote entity but to a
transit network node”. ??
* What is the "TTL expiry exception path”? Is that an
implementation-specific construct?
* “…MUST allow received S-BFD control…” This is a change from rfc5880,
so we should mark this document as updating it.
3. Section 6.1. (Details of S-BFD Control Packet Sent by SBFDReflector)
* "Source IP address…MUST be set to a local IP address…” Any address?
Why isn’t this copied from the received packet?
* "TTL field of the IP header SHOULD be set to 255.” From Section 5.2 I
understand why “SHOULD” is used for the Initiator, but why is this not a “MUST”
for the SBFDReflector?
Nits:
1. Missing references
* Introduction: "The reader is expected to be familiar with the IP, MPLS
BFD and S-BFD terminologies and protocol constructs.”
* Security Considerations: "Martian addresses"
2. Section 2. (S-BFD UDP Port)
* s/can be of any/can be any
* "The source port number MAY be unique among all SBFDInitiator sessions
on the system.” I don’t think we need the “MAY” there.
3. Section 5.1. (Details of S-BFD Control Packet Sent by SBFDInitiator)
* s/UDP source port MUST be set to a value that is not 7784/UDP source
port MUST NOT be set to 7784
* "The destination IP address MUST be chosen from…” Please add a
reference to where the blocks came from.
4. Section 5.2. (Target vs. Remote Entity (S-BFD Discriminator)) may be
better off as 5.1.1.
