John Scudder has entered the following ballot position for draft-ietf-bfd-unaffiliated-echo-12: No Objection
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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document! It's a little unusual in that it talks about how a system can talk to... itself! Which stretches the usual definition of "protocol". Still, it's useful and I'm glad you've done the work. ## COMMENT ### General, theory of operation I didn't see anywhere the document explains in simple terms that the way the extension functions is for the active side to send a packet with one of its own IP addresses as the destination address, upon receipt of which the other side sends it back to the active side. It seems like the lack of this simple explanation led to confusion for at least one reviewer. I suggest adding something like that to avoid future confusion. The Abstract and Introduction seem like the right places. ### General, choice of DA Related, I wonder if there is some need for the document to talk about how the local system should be careful in its choice of destination address. Specifically, I would imagine that if system S is sending a packet out interface F, the best DA to choose would be the local address of F, and not one of S's other addresses (e.g. a loopback address, a different interface address). That's because the far-end system can be expected to know the address of F, but is less sure of knowing S's other addresses. ### Section 2, couldn't understand Once an Unaffiliated BFD Echo session is created on device A, it starts sending Unaffiliated BFD Echo packets. Unaffiliated BFD Echo packets with zeroed "Your Discriminator" field are demultiplexed to the proper session based on the source IP address or UDP source port, once the remote system loops back the local discriminator, all further received packets are demultiplexed based on the "Your Discriminator" field only, which is conform to the procedure specified in Section 6.3 of [RFC5880]. I find it impossible to understand what the preceding sentence is trying to tell me. If I could understand it I'd suggest a rewrite, but I can't even guess. :-( (Also, "which is conform to" should be something like "in conformance to".) ### Section 2, IP redirect provisioned on device A. The Unaffiliated BFD Echo feature depends on device B performing IP forwarding (actually IP redirect) functionality. While such functionality may normally be expected to As far as I know "IP redirect" isn't a defined thing, although there's a confusing overlap with ICMP redirect. I suggest deleting the parenthetical. ### Section 2, confusion about the definition of "rate" Similar to what's specified in [RFC5880], the Unaffiliated BFD Echo session begins with the periodic, slow transmission of Unaffiliated BFD Echo packets. The slow transmission rate SHOULD be no less than one second per packet, until the session is Up. After the session is Up, the provisioned transmission interval is used. When the Unaffiliated BFD Echo session goes Down, the slow transmission rate is resumed. The "Detect Mult" defined in [RFC5880] MUST be set to a There seems to be some confusion between "interval" and "rate" here. A "rate" is conventionally defined as quantity per unit time, i.e. it's a synonym for frequency. So, "rate SHOULD be no less than one second per packet" doesn't make sense, that's a period, not a frequency. The easiest fix would be "rate SHOULD be no greater than one packet per second". ### Section 5, specified As specified in Section 5 of [RFC5880], BFD Echo packets may be spoofed. Specifically for Unaffiliated BFD Echo, a DoS attacker may "Specified" is an unfortunate verb in this context, perhaps "explained"? ## NITS ### Section 3 NEW TEXT When the Echo function is active with Asynchronous mode, a system SHOULD set 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. While a system operating in Demand mode would not receive BFD Control traffic. The last sentence ("While...") is a sentence fragment. Probably you could fix it by deleting "while", so "A system operating in..." ### Section 4 As specified in Section 2 of this document, some configurations are needed to make the Unaffiliated BFD Echo work, although the configurations won't go beyond the scope of [RFC5880]. At a BFD- The RFC Editor would fix this, but should be something like, "some configuration is needed"... "although the configuration won't go".
