Unaffiliated Bidirectional Forwarding Detection (BFD) Echo
draft-ietf-bfd-unaffiliated-echo-14
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-12-13
|
14 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2024-12-11
|
14 | (System) | RFC Editor state changed to EDIT |
2024-12-11
|
14 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2024-12-11
|
14 | (System) | Announcement was received by RFC Editor |
2024-12-11
|
14 | (System) | IANA Action state changed to In Progress |
2024-12-11
|
14 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2024-12-11
|
14 | Cindy Morgan | IESG has approved the document |
2024-12-11
|
14 | Cindy Morgan | Closed "Approve" ballot |
2024-12-11
|
14 | Cindy Morgan | Ballot approval text was generated |
2024-12-11
|
14 | (System) | Removed all action holders (IESG state changed) |
2024-12-11
|
14 | Éric Vyncke | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2024-12-11
|
14 | Zaheduzzaman Sarker | [Ballot comment] Thanks for addressing my discuss point. |
2024-12-11
|
14 | Zaheduzzaman Sarker | [Ballot Position Update] Position for Zaheduzzaman Sarker has been changed to No Objection from Discuss |
2024-12-10
|
14 | Xiao Min | New version available: draft-ietf-bfd-unaffiliated-echo-14.txt |
2024-12-10
|
14 | Xiao Min | New version accepted (logged-in submitter: Xiao Min) |
2024-12-10
|
14 | Xiao Min | Uploaded new revision |
2024-12-04
|
13 | (System) | Changed action holders to Éric Vyncke (IESG state changed) |
2024-12-04
|
13 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2024-12-04
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2024-12-04
|
13 | Xiao Min | New version available: draft-ietf-bfd-unaffiliated-echo-13.txt |
2024-12-04
|
13 | Xiao Min | New version accepted (logged-in submitter: Xiao Min) |
2024-12-04
|
13 | Xiao Min | Uploaded new revision |
2024-10-29
|
12 | Roman Danyliw | [Ballot comment] Thank you to Gyan Mishra for the GENART review. Please review this thread as it proposes helpful clarifying language. Thank you for re-chartering … [Ballot comment] Thank you to Gyan Mishra for the GENART review. Please review this thread as it proposes helpful clarifying language. Thank you for re-chartering the WG to address my DISCUSS feedback. |
2024-10-29
|
12 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2024-10-17
|
12 | (System) | Changed action holders to Reshad Rahman, Xiao Min, Weiqiang Cheng, Ruixue Wang, Raj Boddireddy (IESG state changed) |
2024-10-17
|
12 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2024-10-17
|
12 | Zaheduzzaman Sarker | [Ballot discuss] Thanks for working on this specificaition. This is an interesting protocol to enable system to loopback packets to itself. Also thanks for Brian … [Ballot discuss] Thanks for working on this specificaition. This is an interesting protocol to enable system to loopback packets to itself. Also thanks for Brian Trammell for his good TSVART review. That email thread had a very good conversation to understand this specification better. Thanks to Erik, Jeffrey for reaching to resolutions. I am holding a discuss on the relaxation of congestion control statements in the operational considerations. I think it is very important that we explain the reason better on why we are relaxing that requirement on BFD session ( but not session) in this specification. # RFC 5880 says - Note that "congestion" is not only a traffic phenomenon, but also a computational one. It is possible for systems with a large number of BFD sessions and/or very short packet intervals to become CPU-bound. As such, a congestion control algorithm SHOULD be used even across single hops in order to avoid the possibility of catastrophic system collapse, as such failures have been seen repeatedly in other periodic Hello-based protocols. and this specification says All Operational Considerations from [RFC5880] apply, except that the Unaffiliated BFD Echo can only be used across one hop, which result in unnecessity of a congestion control mechanism. It seems like this specification is relaxing the congestion control requirements without really explaining why it is an exception from what is a SHOULD in RFC 5880, even for single hop. Note that RFC 8085 cprovides congestion control guidelines for protocol that uses UDP. I understand that there is a periodicity and configured value to send the BFD Echo packets, still that does not automatically result in unnecessity of a congestion control requirement for UDP traffic, especially when RFC 5880 also says the congestion is not only a traffic phenomenon. I was expecting more explanation of this exception ( this was also brought up by the TSVART review ) and potential operation impacts as RFC 5880 also indicates the effects can be catastrophic. |
2024-10-17
|
12 | Zaheduzzaman Sarker | [Ballot comment] I have further comments below as I believe when addressed that will improve the specification description - # Section 1 : I don't … [Ballot comment] I have further comments below as I believe when addressed that will improve the specification description - # Section 1 : I don't quite get this statement This document updates [RFC5880] by defining a new method of BFD Echo-Only without requiring an implementation to support the full BFD protocol. Does this mean any IP packet forwarder can be Device B in figure 1? or the device B actually needs to implement RFC5880 partially. In the description of Figure 1 , it says Device B does not support BFD. So to me, Device B can be anything that understands IP forwarding, is it? # Section 5 : it is not clear to me if Device B (loop-back device) in figure 1 does not support BFD then how it can provide the authentication as per RFC 8550. I think we should say that for authentication the loop-back device needs to support RFC 5880. |
2024-10-17
|
12 | Zaheduzzaman Sarker | [Ballot Position Update] New position, Discuss, has been recorded for Zaheduzzaman Sarker |
2024-10-16
|
12 | Murray Kucherawy | [Ballot comment] I support Roman's DISCUSS. The SHOULD in Section 2 appears to be re-stating advice from RFC 5880. I suggest not using SHOULD … [Ballot comment] I support Roman's DISCUSS. The SHOULD in Section 2 appears to be re-stating advice from RFC 5880. I suggest not using SHOULD here if that advice is simply being carried forward, since you already refer back to that document whose advice is still in effect. Or if you're actually tweaking that advice here, I suggest being more explicit that that's what's going on. |
2024-10-16
|
12 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2024-10-16
|
12 | John Scudder | [Ballot 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 … [Ballot 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". |
2024-10-16
|
12 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2024-10-16
|
12 | Roman Danyliw | [Ballot discuss] (For the BFD WG chairs and responsible AD) This document does not appear to be in scope of the charter (version -08). The … [Ballot discuss] (For the BFD WG chairs and responsible AD) This document does not appear to be in scope of the charter (version -08). The current charter identifies 7 specific topics (numbers 1, 2a, 2b, 2c, 3, 4, and 5), none of which appear to cover this document. |
2024-10-16
|
12 | Roman Danyliw | [Ballot comment] Thank you to Gyan Mishra for the GENART review. Please review this thread as it proposes helpful clarifying language. |
2024-10-16
|
12 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2024-10-16
|
12 | Deb Cooley | [Ballot comment] Thanks to Stephen Farrell for both of his secdir reviews of this draft. |
2024-10-16
|
12 | Deb Cooley | [Ballot Position Update] New position, No Objection, has been recorded for Deb Cooley |
2024-10-15
|
12 | Warren Kumari | [Ballot comment] Much thanks to Dhruv for the initial OpsDir review (https://datatracker.ietf.org/doc/review-ietf-bfd-unaffiliated-echo-11-opsdir-lc-dhody-2024-10-08/), and then for updating the reviw (https://datatracker.ietf.org/doc/review-ietf-bfd-unaffiliated-echo-12-opsdir-telechat-dhody-2024-10-10/) to explicitly … [Ballot comment] Much thanks to Dhruv for the initial OpsDir review (https://datatracker.ietf.org/doc/review-ietf-bfd-unaffiliated-echo-11-opsdir-lc-dhody-2024-10-08/), and then for updating the reviw (https://datatracker.ietf.org/doc/review-ietf-bfd-unaffiliated-echo-12-opsdir-telechat-dhody-2024-10-10/) to explicitly note that their concerns have been addressed. I'm traveling at the moment, and so have relied heavily on the review. |
2024-10-15
|
12 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2024-10-15
|
12 | Mahesh Jethanandani | [Ballot comment] Section 1, paragraph 2 > BFD [RFC5880] is a low-overhead, short-duration method to detect > faults on the communication … [Ballot comment] Section 1, paragraph 2 > BFD [RFC5880] is a low-overhead, short-duration method to detect > faults on the communication path between adjacent forwarding engines. > The faults can be on interfaces, data links, and even the forwarding > engines. It is a single, unified mechanism to monitor any media and > protocol layers in real time. I do not know if "short-duration" is the right way to describe a "BFD session", even as the document says it is not a "BFD session". Whatever you call the continious sending of packets that are echoed back, which in my mind is a session, it can run with a short interval, but can run for a very long duration. Maybe "short-interval"? Section 1, paragraph 9 > This document updates [RFC5880] by defining a new method of BFD Echo- > Only without requiring an implementation to support the full BFD > protocol. It specifies the use of the Unaffiliated BFD Echo over > IPv4 and IPv6 for a single IP hop. A full description of the updates > to [RFC5880] is provided in Section 3. As noted in Gyan Mishra's review, even as it might be obvious to some, it would help to clarify why Unaffliated BFD Echo cannot be supported over multi-hop BFD. Section 2, paragraph 10 > 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 > value provisioned on device A. When the bfd.SessionState is Up and a > "Detect Mult" number of Unaffiliated BFD Echo packets have not > arrived at device A as they should, the device A "MUST set > bfd.SessionState to Down and bfd.LocalDiag to 2 (Echo Function > Failed)", as specified in Section 6.8.5 of [RFC5880]. In this example, device A is the one implementing the full BFD stack. Thus it is the only one to have a notion of session being up. Can that be made explicit in the text? ------------------------------------------------------------------------------- NIT ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 2, paragraph 6 > iscriminator" field only, which is conform to the procedure specified in Sect > ^^^^^^^ Consider using either the past participle "conformed" or the present participle "conforming" here. |
2024-10-15
|
12 | Mahesh Jethanandani | [Ballot Position Update] New position, No Objection, has been recorded for Mahesh Jethanandani |
2024-10-15
|
12 | Paul Wouters | [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters |
2024-10-15
|
12 | Brian Trammell | Request for Telechat review by TSVART Completed: Not Ready. Reviewer: Brian Trammell. Sent review to list. |
2024-10-15
|
12 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2024-10-14
|
12 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2024-10-14
|
12 | Gyan Mishra | Request for Last Call review by GENART Completed: Not Ready. Reviewer: Gyan Mishra. Sent review to list. Submission of review completed at an earlier date. |
2024-10-14
|
12 | Gyan Mishra | Request for Last Call review by GENART Completed: Not Ready. Reviewer: Gyan Mishra. |
2024-10-14
|
12 | Orie Steele | [Ballot Position Update] New position, No Objection, has been recorded for Orie Steele |
2024-10-14
|
12 | Gunter Van de Velde | [Ballot comment] # Gunter Van de Velde, RTG AD, comments for draft-ietf-bfd-unaffiliated-echo-12.txt # line numbers are derived with the idnits tool https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-12.txt # idnits spits … [Ballot comment] # Gunter Van de Velde, RTG AD, comments for draft-ietf-bfd-unaffiliated-echo-12.txt # line numbers are derived with the idnits tool https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-12.txt # idnits spits a warning about pre-rfc5378 work # i found the document well written and a nice read into this technology. Thank you. # In what follows you will find some detailed observations and some editorial suggestions trying to improve readability while keeping original message. #DETAILED COMMENTS #================= 18 Bidirectional Forwarding Detection (BFD) is a fault detection 19 protocol that can quickly determine a communication failure between 20 two forwarding engines. This document defines a use of the BFD Echo 21 where the local system supports BFD but the adjacent system does not 22 support BFD. BFD Control packet and its processing procedures can be 23 executed over the BFD Echo port where the adjacent system only loops 24 packets back to the local system. 26 This document updates RFC 5880 by defining a new method of BFD Echo- 27 Only without requiring an implementation to support the full BFD 28 protocol. GV> proposed alternative abstract rewrite for readability and high level understanding of the technology proposed: " This document specifies an extension to the Bidirectional Forwarding Detection (BFD) protocol that enables the use of the BFD Echo function without the need for an associated BFD control session. This "Unaffiliated BFD Echo" mechanism allows rapid detection of forwarding path failures in networks where establishing BFD control sessions is impractical or undesirable. By decoupling the Echo function from the control plane, network devices can utilize BFD's fast failure detection capabilities in a simplified manner, enhancing network resiliency and operational efficiency. This document updates RFC 5880 by defining a new Unaffiliated BFD Echo mechanism. " 77 1. Introduction 78 79 To minimize the impact of device/link faults on services and improve 80 network availability, in the single-hop cases a network device needs 81 to be able to quickly detect faults in communication with adjacent 82 devices. Measures can then be taken to promptly rectify the faults 83 to ensure service continuity. 84 85 BFD [RFC5880] is a low-overhead, short-duration method to detect 86 faults on the communication path between adjacent forwarding engines. 87 The faults can be on interfaces, data links, and even the forwarding 88 engines. It is a single, unified mechanism to monitor any media and 89 protocol layers in real time. 90 91 BFD defines the Asynchronous mode and the Demand mode to satisfy 92 various deployment scenarios. It also supports an Echo function that 93 reduces the level of BFD support required in device implementations, 94 as described in Section 3.2 of [RFC5880]. When the Echo function is 95 activated, the local system sends BFD Echo packets and the remote 96 system loops back the received Echo packets through the forwarding 97 path. If several consecutive BFD Echo packets are not received by 98 the local system, then the BFD session is declared to be Down. 99 100 When using BFD Echo function, there are two typical scenarios as 101 below: 102 103 * Full BFD protocol capability with adjunct Echo function. This 104 scenario requires both the local device and the adjacent device to 105 support the full BFD protocol. 106 107 * BFD Echo-Only method without full BFD protocol capability. This 108 scenario requires only the local device to support sending and 109 demultiplexing BFD Control packets. In this scenario, the BFD 110 Control packets are sent over the BFD Echo port, but that the 111 processing procedures for Asynchronous mode are used with the 112 modifications described in this document. Note that this method 113 monitors the connectivity to a system over a specific interface 114 and does not verify the availability of a specific IP address at 115 that system. 116 117 The former scenario is referred to as "Affiliated BFD Echo" in this 118 document, which remains unchanged from [RFC5880]. The latter 119 scenario is referred to as "Unaffiliated BFD Echo", which is 120 specified in this document. 121 122 Section 5 of [RFC5880] indicates that the payload of an affiliated 123 BFD Echo packet is a local matter and hence its contents are outside 124 the scope of that specification. This document, on the other hand, 125 specifies the contents of the Unaffiliated BFD Echo packet and what 126 to do with them. This would appear to contravene Section 5 of 127 [RFC5880]. However, the core behavior in that RFC simply states that 128 the contents of the BFD Echo packets are a local matter, and this 129 document is simply defining "the local matter". Regarding the 130 selection of IP address, the rules stated in Section 4 of [RFC5881] 131 are applicable to the encapsulation of an Unaffiliated BFD Echo 132 packet. 133 134 Section 6.2.2 of [BBF-TR-146] describes one use case of the 135 Unaffiliated BFD Echo. 136 137 This document updates [RFC5880] by defining a new method of BFD Echo- 138 Only without requiring an implementation to support the full BFD 139 protocol. It specifies the use of the Unaffiliated BFD Echo over 140 IPv4 and IPv6 for a single IP hop. A full description of the updates 141 to [RFC5880] is provided in Section 3. GV> proposed rewrite for improved readability: " To minimize the impact of device and link faults on services and to improve network availability in single-hop scenarios, a network device needs the capability to quickly detect communication faults with adjacent devices. Prompt detection allows for timely remedial actions to ensure service continuity. BFD [RFC5880] provides a low-overhead, short-duration method for detecting faults on the communication path between adjacent forwarding engines, which may include interfaces, data links, and the forwarding engines themselves. BFD offers a unified mechanism to monitor any media and protocol layers in real time. BFD defines two primary modes—Asynchronous mode and Demand mode—to accommodate various deployment scenarios. Additionally, it supports an Echo function that reduces the level of BFD support required in device implementations, as described in Section 3.2 of [RFC5880]. When the Echo function is activated, the local system sends BFD Echo packets, and the remote system loops back the received Echo packets through the forwarding path. If several consecutive BFD Echo packets are not received by the local system, the BFD session is declared Down. There are two typical scenarios when using the BFD Echo function: * Full BFD protocol capability with adjunct Echo function (Affiliated BFD Echo): This scenario requires both the local device and the adjacent device to support the full BFD protocol. This operation remains unchanged from [RFC5880]. * BFD Echo-Only method without full BFD protocol capability (Unaffiliated BFD Echo): This scenario requires only the local device to support sending and demultiplexing BFD Control packets. In this case, BFD Control packets are sent over the BFD Echo port, and the processing procedures for Asynchronous mode are used with the modifications specified in this document. Note that this method monitors the connectivity to a system over a specific interface and does not verify the availability of a specific IP address on that system. This document specifies the Unaffiliated BFD Echo scenario. Section 5 of [RFC5880] indicates that the payload of an Affiliated BFD Echo packet is a local matter and, therefore, its contents are outside the scope of that specification. This document, however, specifies the contents of the Unaffiliated BFD Echo packet and the procedures for handling them. While this may appear to contravene Section 5 of [RFC5880], the core behavior in that RFC states that the contents of BFD Echo packets are a local matter; this document is defining that "local matter." Regarding the selection of IP addresses, the rules stated in Section 4 of [RFC5881] are applicable to the encapsulation of an Unaffiliated BFD Echo packet. Section 6.2.2 of [BBF-TR-146] describes a use case for the Unaffiliated BFD Echo. This document updates [RFC5880] by defining a new method of BFD Echo-only operation that does not require an implementation to support the full BFD protocol. It specifies the use of the Unaffiliated BFD Echo over IPv4 and IPv6 for a single IP hop. A full description of the updates to [RFC5880] is provided in Section 3. " 186 engage in a BFD session. The local end as an initiator may regard 187 the Unaffiliated BFD Echo session as a BFD session within its 188 implementation. GV> To me the wording "within its implementation" is not so clear what it exactly means. I suspect that the intent is to say that this session is perceived to be internal contained within its own implementation without any external control plane devices or systems? Can the text be made more descriptive? 190 For unaffiliated echo, an Unaffiliated BFD Echo session is created on 191 device A, and the Unaffiliated BFD Echo session MUST follow the BFD 192 state machine defined in Section 6.2 of [RFC5880], except that the GV> The wording "For unaffiliated echo" reads odd. Would it be correct to say "For the unaffiliated echo procedure" to be more accurate? or was this suggesting something else? 190 For unaffiliated echo, an Unaffiliated BFD Echo session is created on 191 device A, and the Unaffiliated BFD Echo session MUST follow the BFD 192 state machine defined in Section 6.2 of [RFC5880], except that the 193 received state is not extracted from BFD Control packets originated 194 by the remote system, but from packets originated by the local system 195 and looped back from the remote system. Therefore, Unaffiliated BFD 196 Echo does not use the AdminDown state. BFD Control packets are 197 transmitted and received as Unaffiliated BFD Echo packets using 198 destination UDP port 3785, as defined in [RFC5881]. The procedures 199 for BFD Async sessions are executed for the looped BFD Control 200 packets as per [RFC5880], including validation and authentication. GV> From a readability perspective, what about the following editorial suggestion: " For the Unaffiliated Echo procedure, an Unaffiliated BFD Echo session is established on device A. The session MUST adhere to the BFD state machine specified in Section 6.2 of [RFC5880], with the exception that the received state is not derived from BFD Control packets originating from the remote system, but rather from packets that are generated by the local system and looped back from the remote system. Consequently, the AdminDown state is not utilized in Unaffiliated BFD Echo. BFD Control packets are transmitted and received as Unaffiliated BFD Echo packets, using UDP destination port 3785, as defined in [RFC5881]. The standard procedures for BFD Asynchronous sessions are applied to the looped BFD Control packets, including packet validation and authentication, in accordance with [RFC5880]. " 216 Within the Unaffiliated BFD Echo packet, the "Desired Min TX 217 Interval" and "Required Min RX Interval" defined in [RFC5880] MUST be 218 populated with a certain value, which can avoid unset value being a 219 potential vector for disclosure of uninitialized memory. A suggested 220 value is 1 second (1,000,000 microseconds). These values, however, 221 MUST be ignored on receipt. Furthermore, these values MUST NOT be 222 used to calculate the Detection Time. GV> I got thrown off guard when reading the word 'certain' I am not sure it the correct construct to use here. There is no certainty. I suspect that the intent is to say that a specific value must be used. I am not sure why or how the uninitialized memory comes into the picture? Maybe a word to explain this could be added for non-bfd experts? To make the existing paragraph better readable what about the following rewrite: " In the context of an Unaffiliated BFD Echo packet, the "Desired Min TX Interval" and "Required Min RX Interval" fields, as defined in [RFC5880], MUST be populated with a specific value to prevent the potential exposure of uninitialized memory. It is RECOMMENDED that these fields be set to a value of 1 second (1,000,000 microseconds). However, upon receipt, these values MUST be ignored and MUST NOT be used in the calculation of the Detection Time. " 224 The "Required Min Echo RX Interval" defined in [RFC5880] MUST be 225 populated with a certain value, which can avoid unset value being a 226 potential vector for disclosure of uninitialized memory. A suggested 227 value is 0. This value MUST be ignored on receipt. The transmission 228 interval for Unaffiliated BFD Echo packets in the Up state MUST be 229 provisioned on device A. The Unaffiliated BFD Echo feature depends 230 on device B performing IP forwarding (actually IP redirect) 231 functionality. While such functionality may normally be expected to 232 be supported on a router, it may not be enabled on a host by default. 233 The method for provisioning device B to loop back Unaffiliated BFD 234 Echo packets is outside the scope of this document. GV> What about the following rewrite: " The "Required Min Echo RX Interval" field, as defined in [RFC5880], MUST be populated with a specific value to prevent the potential disclosure of uninitialized memory. It is RECOMMENDED that this value be set to 0. However, this value MUST be ignored upon receipt. The transmission interval for Unaffiliated BFD Echo packets when in the Up state MUST be provisioned on device A. The functionality of the Unaffiliated BFD Echo feature is dependent on device B performing IP forwarding (specifically, IP redirect functionality). While this capability is typically expected to be supported on routers, it may not be enabled by default on hosts. The method for provisioning device B to loop back Unaffiliated BFD Echo packets is outside the scope of this document. " 236 Similar to what's specified in [RFC5880], the Unaffiliated BFD Echo 237 session begins with the periodic, slow transmission of Unaffiliated 238 BFD Echo packets. The slow transmission rate SHOULD be no less than 239 one second per packet, until the session is Up. After the session is 240 Up, the provisioned transmission interval is used. When the GV> In the above is described that with slow transmission rate to be no less as one second per packet. Next the text moves to the provisioned transmission interval. I was wondering if it would be useful to inform about the range of the valid transmission intervals with unaffiliated sessions for completeness of the paragraph? 253 * "My Discriminator" MUST be set to the provisioned local 254 discriminator. 255 256 * "Your Discriminator" MUST be set to 0 initially, and then MUST be 257 set to the same as "My Discriminator" looped back. 258 259 * "Desired Min TX Interval" MUST be set to a certain value. A 260 suggested value is 1 second (1,000,000 microseconds). 261 262 * "Required Min RX Interval" MUST be set to a certain value. A 263 suggested value is 1 second (1,000,000 microseconds). 364 265 * "Required Min Echo RX Interval" MUST be set to a certain value. A 266 suggested value is 0. 267 268 * "Detect Mult" MUST be set to the provisioned maximum allowable 269 number of consecutively lost Unaffiliated BFD Echo packets. GV> Proposed readability rewrite: " * My Discriminator: MUST be set to the provisioned local discriminator. * Your Discriminator: MUST initially be set to 0, and then MUST be set to the value of "My Discriminator" looped back from the remote system. * Desired Min TX Interval: MUST be set to a specific value, with a suggested value of 1 second (1,000,000 microseconds). * Required Min RX Interval: MUST be set to a specific value, with a suggested value of 1 second (1,000,000 microseconds). * Required Min Echo RX Interval: MUST be set to a specific value, with a suggested value of 0. * Detect Mult: MUST be set to the provisioned maximum allowable number of consecutively lost Unaffiliated BFD Echo packets. " 273 The Unaffiliated BFD Echo described in this document reuses the BFD 274 Echo function as described in [RFC5880] and [RFC5881], but does not 275 require BFD Asynchronous or Demand mode. When using the Unaffiliated GV> Is the following more accurate? s/require BFD Asynchronous or Demand mode/require BFD Asynchronous or Demand mode on the remote system/ 275 require BFD Asynchronous or Demand mode. When using the Unaffiliated 276 BFD Echo, only the local system has the BFD protocol enabled; the 277 remote system just loops back the received BFD Echo packets as 278 regular data packets. GV> suggested editorial rewrite: " In the Unaffiliated BFD Echo operation, only the local system has the BFD protocol enabled, while the remote system simply loops back the received BFD Echo packets as ordinary data packets, without engaging in the BFD protocol. " |
2024-10-14
|
12 | Gunter Van de Velde | [Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde |
2024-10-12
|
12 | Adrian Farrel | Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Adrian Farrel. Review has been revised by Adrian Farrel. |
2024-10-12
|
12 | Stephen Farrell | Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Stephen Farrell. Sent review to list. |
2024-10-11
|
12 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2024-10-10
|
12 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Stephen Farrell |
2024-10-10
|
12 | Dhruv Dhody | Request for Telechat review by OPSDIR Completed: Ready. Reviewer: Dhruv Dhody. Sent review to list. |
2024-10-10
|
12 | Magnus Westerlund | Request for Telechat review by TSVART is assigned to Brian Trammell |
2024-10-10
|
12 | Carlos Pignataro | Request for Telechat review by OPSDIR is assigned to Dhruv Dhody |
2024-10-10
|
12 | Éric Vyncke | Placed on agenda for telechat - 2024-10-17 |
2024-10-10
|
12 | Éric Vyncke | Ballot has been issued |
2024-10-10
|
12 | Éric Vyncke | [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke |
2024-10-10
|
12 | Éric Vyncke | Created "Approve" ballot |
2024-10-10
|
12 | Éric Vyncke | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2024-10-10
|
12 | Éric Vyncke | Ballot writeup was changed |
2024-10-10
|
12 | (System) | Changed action holders to Éric Vyncke (IESG state changed) |
2024-10-10
|
12 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2024-10-10
|
12 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2024-10-10
|
12 | Xiao Min | New version available: draft-ietf-bfd-unaffiliated-echo-12.txt |
2024-10-10
|
12 | Xiao Min | New version accepted (logged-in submitter: Xiao Min) |
2024-10-10
|
12 | Xiao Min | Uploaded new revision |
2024-10-10
|
11 | Éric Vyncke | A revised I-D is required to address all directorate reviews; authors & reviewers have agreed on the content of the next revision, so, let's submit … A revised I-D is required to address all directorate reviews; authors & reviewers have agreed on the content of the next revision, so, let's submit it. Email sent to the authors and to the BFD mailing list. |
2024-10-10
|
11 | (System) | Changed action holders to Reshad Rahman, Xiao Min, Weiqiang Cheng, Ruixue Wang, Raj Boddireddy (IESG state changed) |
2024-10-10
|
11 | Éric Vyncke | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2024-10-09
|
11 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2024-10-08
|
11 | Dhruv Dhody | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Dhruv Dhody. Sent review to list. |
2024-10-07
|
11 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2024-10-07
|
11 | David Dong | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-bfd-unaffiliated-echo-11, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-bfd-unaffiliated-echo-11, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Sr. Specialist |
2024-10-07
|
11 | Stephen Farrell | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Stephen Farrell. Sent review to list. |
2024-10-05
|
11 | Tim Wicinski | Request for Last Call review by INTDIR Completed: Ready with Nits. Reviewer: Tim Wicinski. Sent review to list. |
2024-09-30
|
11 | Carlos Pignataro | Assignment of request for Last Call review by OPSDIR to Tony Li was withdrawn |
2024-09-30
|
11 | Carlos Pignataro | Request for Last Call review by OPSDIR is assigned to Dhruv Dhody |
2024-09-30
|
11 | Carlos Pignataro | Request for Last Call review by OPSDIR is assigned to Tony Li |
2024-09-27
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Farrell |
2024-09-26
|
11 | Adrian Farrel | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Adrian Farrel. Sent review to list. |
2024-09-26
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Gyan Mishra |
2024-09-25
|
11 | Carlos Jesús Bernardos | Request for Last Call review by INTDIR is assigned to Tim Wicinski |
2024-09-25
|
11 | Daniam Henriques | Request for Last Call review by RTGDIR is assigned to Adrian Farrel |
2024-09-25
|
11 | Éric Vyncke | Requested Last Call review by RTGDIR |
2024-09-25
|
11 | Éric Vyncke | Requested Last Call review by OPSDIR |
2024-09-25
|
11 | Éric Vyncke | Requested Last Call review by INTDIR |
2024-09-25
|
11 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2024-09-25
|
11 | Cindy Morgan | The following Last Call announcement was sent out (ends 2024-10-09): From: The IESG To: IETF-Announce CC: bfd-chairs@ietf.org, draft-ietf-bfd-unaffiliated-echo@ietf.org, evyncke@cisco.com, jhaas@pfrc.org, rtg-bfd@ietf.org … The following Last Call announcement was sent out (ends 2024-10-09): From: The IESG To: IETF-Announce CC: bfd-chairs@ietf.org, draft-ietf-bfd-unaffiliated-echo@ietf.org, evyncke@cisco.com, jhaas@pfrc.org, rtg-bfd@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Unaffiliated BFD Echo) to Proposed Standard The IESG has received a request from the Bidirectional Forwarding Detection WG (bfd) to consider the following document: - 'Unaffiliated BFD Echo' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2024-10-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Bidirectional Forwarding Detection (BFD) is a fault detection protocol that can quickly determine a communication failure between two forwarding engines. This document defines a use of the BFD Echo where the local system supports BFD but the adjacent system does not support BFD. BFD Control packet and its processing procedures can be executed over the BFD Echo port where the adjacent system only loops packets back to the local system. This document updates RFC 5880. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/ No IPR declarations have been submitted directly on this I-D. |
2024-09-25
|
11 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2024-09-25
|
11 | Cindy Morgan | Last call announcement was generated |
2024-09-24
|
11 | Éric Vyncke | Last call was requested |
2024-09-24
|
11 | Éric Vyncke | Ballot approval text was generated |
2024-09-24
|
11 | Éric Vyncke | Ballot writeup was generated |
2024-09-24
|
11 | Éric Vyncke | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2024-09-24
|
11 | Éric Vyncke | Last call announcement was generated |
2024-09-24
|
11 | (System) | Changed action holders to Éric Vyncke (IESG state changed) |
2024-09-24
|
11 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2024-09-24
|
11 | Xiao Min | New version available: draft-ietf-bfd-unaffiliated-echo-11.txt |
2024-09-24
|
11 | Xiao Min | New version accepted (logged-in submitter: Xiao Min) |
2024-09-24
|
11 | Xiao Min | Uploaded new revision |
2024-09-20
|
10 | Éric Vyncke | AD review sent to rtg-bfd@ietf.org and the authors. Dear BFD, dear authors, To lighten John Scudder’s workload, I will be the alternate responsible AD for … AD review sent to rtg-bfd@ietf.org and the authors. Dear BFD, dear authors, To lighten John Scudder’s workload, I will be the alternate responsible AD for draft-ietf-bfd-unaffiliated-echo. As I am an INT AD, please bear with me if I state something wrong about BFD ;-) First of all: thanks to the authors and the WHG for authoring this I-D and to Jeff Haas for being the shepherd. Before proceeding with the publication process, I usually do my AD review before starting the IETF Last Call and *I request either a reply or an action (revised I-D) for all the points below* (some of them are nits); the only goal is to ease the IESG evaluation later. Let’s work together to get this I-D published :-) Regards -éric # Abstract s/ This document proposes a use of the BFD Echo/ This document defines a use of the BFD Echo/ s/but the neighboring system does/but the adjacent system does/ ? (to be consistent with S1) # Generic The section 1 should include some explanations about how packets are looped back to the source. RFC 5881 says ‘no LLA and not the subnet addresses’, so which addresses are used for source and destination ? The addressing probably deserves one section in the document. # Section 1 s/Full BFD protocol capability with affiliated Echo function/Full BFD protocol capability in the local and adjacent systems/ ? As the term ‘affiliated’ is defined in a subsequent paragraph and is not defined in RFC 5880. In `BFD Echo-Only method without full BFD protocol capability` should “in the adjacent system” be added ? Does it make sense to refer to an expired draft, draft-wang-bfd-one-arm-use-case-00 ? Expiration was in 2020... s/This document describes the use/This document specifies the use/ It is a standard track document after all ;-) # Section 2 Suggest using aasvg for nicer picture in rendering About figure 1, unsure whether “interface 1” adds anything, suggest removing (same for the top “Device A” and “Device B”). s/with zeroed "Your Discriminator"/with zeroed "Your Discriminator" field/ s/which is conformed to/which is conform to/ ? As I am not an English speaker, I wonder whether “with a certain value” is really the appropriate wording. The use of SHOULD should come with explanation of what happens if the SHOULD is bypassed (i.e., the previous issue of memory disclosure should be moved here). At the end of this section, the BFD fields are not enclosed in double quotes, they should be for clarity as well as to be consistent with the previous text. # Section 3 Bear with my lack of expertise in BFD, but can this be achieved `Demand mode MUST NOT be active if the session goes Down`? # Section 4 Unsure whether it brings any value, either delete this applicability section or move it as a subsection of the introduction ? # Section 5 As I wrote above, it is unclear for me (and probably many readers) what are the src/dst addresses of the IP packets, i.e., I cannot understand whether uRPF must be disabled or not. => an addressing considerations section is welcome with some examples. About the GSTM, as the technique clearly specifies that the adjacent system does not implement BFD, how can this document require that looping is only done with TTL/HL=255 ? RFC 8704 does not define a strict mode uRPF, so, remove this reference. |
2024-09-20
|
10 | (System) | Changed action holders to Éric Vyncke, Reshad Rahman, Xiao Min, Weiqiang Cheng, Ruixue Wang, Raj Boddireddy (IESG state changed) |
2024-09-20
|
10 | Éric Vyncke | IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested |
2024-09-20
|
10 | Éric Vyncke | Changed action holders to Éric Vyncke (Éric Vyncke acting as alternate AD) |
2024-09-20
|
10 | Éric Vyncke | Shepherding AD changed to Éric Vyncke |
2024-01-17
|
10 | Jeffrey Haas | Prelude: The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap with a similar feature specified in BBF TR-146. A liaison statement was exchanged with BBF with … Prelude: The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap with a similar feature specified in BBF TR-146. A liaison statement was exchanged with BBF with regard to this work: https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/ This internet-draft is largely intended to cover a full IETF specification for the functionality covered by TR-146 and address the minor issues where TR-146 is incompletely specified. : Document History : : 1. Does the working group (WG) consensus represent the strong concurrence of a : few individuals, with others being silent, or did it reach broad agreement? The document has weak but positive Working Group consensus to advance. This is somewhat typical of documents progressing through BFD at this point. That said, the document has had a degree of strong review from the interested parties. : 2. Was there controversy about particular points, or were there decisions where : the consensus was particularly rough? There were several concerns from Greg Mirsky largely regarding the following points: 1. The mechanism specified in the document bypassed the pre-existing BFD Async mechanism which permitted the Echo functionality to be enabled. However, this is exactly the point of this feature. Much of the updates to RFC 5880 are present to permit ths mode. It's important to note that this mechanism is not intended to completely replace the Echo mode for RFC 5880 when used in conjunction with the traditional Async mode. 2. The mechanism specified in the document specified a format for the BFD Echo packets. This would appear to contravene RFC 5880, Section 5. However, the core behavior in the RFC simply states that the contents of the Echo packets are a local matter - and this document is simply defining "the local matter". 3. The normative Security Considerations were not strong enough. Discussion with the authors and Greg eventually has converged with RFC 5082 GTSM procedures being required. This may mean existing implementations of these procedures are non-conformant. However, this does not impact interoperability since the entire point of this feature is a "BFD implementation talking to itself". 4. A further point of discussion is the intended destination and source addresses used by this mechanism. RFC 5881, in particular, provides guidance for the source address selection such that it is not on the same subnet as the destination address in order to prevent unnecessary ICMP/ND redirect messages. However, existing implementations (e.g. Broadcom) use exactly behavior with source and destination addresses being identical. RFC 5881 makes this behavior a SHOULD NOT, so using the same considerations for this mechanism avoids making existing implementations non-conformant. 5. In the discussion over the document's intended status, Greg has noted that the Broadband Forum, in its liaison For Information TR-146 and draft-ietf-bfd-unaffiliated-echo (https://datatracker.ietf.org/liaison/1775/) informed the IETF and BFD WG that: "In our [Broadband Forum's] opinion, no future standardization is required to support TR-146." Greg also expressed an opinion that the document should be Experimental rather than Proposed Standard. As noted in the IETF webpage, "Choosing between Informational and Experimental Status", it is Shepherd's opinion is that Experimental is inappropriate. "The "Experimental" designation typically denotes a specification that is part of some research or development effort". In this case, implementations are commercially available utilizing mechanisms largely similar to those being codified in this Internet-Draft. While the procedures in this draft are purely local (the implementation "talks to itself"), the behavior requires a violation of RFC 5880 with regard to Echo procedures only being available after the Up state has been achieved in Asynchronous mode. It is thus the Chairs' opinion that the text permitting the relaxation of that requirement is appropriate to standardize for this document, and thus an appropriate change of status requiring an update to RFC 5880. : 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If : so, please summarize the areas of conflict in separate email messages to the : responsible Area Director. (It should be in a separate email because this : questionnaire is publicly available.) No. : 4. For protocol documents, are there existing implementations of the contents of : the document? Have a significant number of potential implementers indicated : plans to implement? Are any existing implementations reported somewhere, : either in the document itself (as RFC 7942 recommends) or elsewhere : (where)? There are multiple implementations that claim some deployment of BBF TR-146 implementation behavior. : Additional Reviews : : 5. Do the contents of this document closely interact with technologies in other : IETF working groups or external organizations, and would it therefore benefit : from their review? Have those reviews occurred? If yes, describe which : reviews took place. No additional reviews have been requested. : 6. Describe how the document meets any required formal expert review criteria, : such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. This mechanism currently does not have a YANG module. It may benefit from one at some point in the future that extends the existing RFC 9314 YANG module for BFD. : 7. If the document contains a YANG module, has the final version of the module : been checked with any of the recommended validation tools for syntax and : formatting validation? If there are any resulting errors or warnings, what is : the justification for not fixing them at this time? Does the YANG module : comply with the Network Management Datastore Architecture (NMDA) as specified : in RFC 8342? N/A : 8. Describe reviews and automated checks performed to validate sections of the : final version of the document written in a formal language, such as XML code, : BNF rules, MIB definitions, CBOR's CDDL, etc. N/A : Document Shepherd Checks : : 9. Based on the shepherd's review of the document, is it their opinion that this : document is needed, clearly written, complete, correctly designed, and ready : to be handed off to the responsible Area Director? Yes. : 10. Several IETF Areas have assembled lists of common issues that their : reviewers encounter. For which areas have such issues been identified : and addressed? For which does this still need to happen in subsequent : reviews? N/A : 11. What type of RFC publication is being requested on the IETF stream (Best : Current Practice, Proposed Standard, Internet Standard, : Informational, Experimental or Historic)? Why is this the proper type : of RFC? Do all Datatracker state attributes correctly reflect this intent? Proposed Standard. This mechanism leverages existing BFD procedures in a new profile (BFD Async over the Echo port) and is appropriate for the standards track. The Echo port procedures from the core RFC 5880 intentionally leave the contents of the Echo packets out of scope from that document, and thus not a normative change in this document. However, the ability to use BFD state machinery without the associated Async session is a normative change of behavior, even if solely a local one. : 12. Have reasonable efforts been made to remind all authors of the intellectual : property rights (IPR) disclosure obligations described in BCP 79? To : the best of your knowledge, have all required disclosures been filed? If : not, explain why. If yes, summarize any relevant discussion, including links : to publicly-available messages when applicable. IPR attestations: Weiqiang Cheng: https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZWMtOxUKZZbECUmmtLU9ZtZeGEk/ Ruixue Wang: https://mailarchive.ietf.org/arch/msg/rtg-bfd/K9D3KG7MqAm1yk0WaAIOoh5B_Z8/ Xiao Min: https://mailarchive.ietf.org/arch/msg/rtg-bfd/VQRGASf2GGiv6-J4vp515aY0HYs/ Reshad Rahman: https://mailarchive.ietf.org/arch/msg/rtg-bfd/9dEQm-IZy_48pjtkKKTu7yWOXYI/ Raj Chetan Boddireddy: https://mailarchive.ietf.org/arch/msg/rtg-bfd/esD26TKSjvRFJSm0qbcAJ-7EKvo/ It is also necessary to point out that this mechanism is an IETF instantiation of similar procedures from BBF TR-146. See liaison statement referenced above. : 13. Has each author, editor, and contributor shown their willingness to be : listed as such? If the total number of authors and editors on the front page : is greater than five, please provide a justification. Yes. There are exactly five authors. : 14. Document any remaining I-D nits in this document. Simply running the idnits : tool is not enough; please review the "Content Guidelines" on : authors.ietf.org. (Also note that the current idnits tool generates : some incorrect warnings; a rewrite is underway.) There are no nits noted in version -10. : 15. Should any informative references be normative or vice-versa? See the IESG : Statement on Normative and Informative References. No. : 16. List any normative references that are not freely available to anyone. Did : the community have sufficient access to review any such normative : references? All references, including the Informative BBF TR-146 reference, are publicly available. : 17. Are there any normative downward references (see RFC 3967 and BCP : 97) that are not already listed in the DOWNREF registry? If so, : list them. No. : 18. Are there normative references to documents that are not ready to be : submitted to the IESG for publication or are otherwise in an unclear state? : If so, what is the plan for their completion? No such references. : 19. Will publication of this document change the status of any existing RFCs? If : so, does the Datatracker metadata correctly reflect this and are those RFCs : listed on the title page, in the abstract, and discussed in the : introduction? If not, explain why and point to the part of the document : where the relationship of this document to these other RFCs is discussed. This document does not change the status of other existing RFCs. : 20. Describe the document shepherd's review of the IANA considerations section, : especially with regard to its consistency with the body of the document. : Confirm that all aspects of the document requiring IANA assignments are : associated with the appropriate reservations in IANA registries. Confirm : that any referenced IANA registries have been clearly identified. Confirm : that each newly created IANA registry specifies its initial contents, : allocations procedures, and a reasonable name (see RFC 8126). This document makes no further requests from IANA. : 21. List any new IANA registries that require Designated Expert Review for : future allocations. Are the instructions to the Designated Expert clear? : Please include suggestions of designated experts, if appropriate. N/A |
2024-01-15
|
10 | Jeffrey Haas | Prelude: The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap with a similar feature specified in BBF TR-146. A liaison statement was exchanged with BBF with … Prelude: The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap with a similar feature specified in BBF TR-146. A liaison statement was exchanged with BBF with regard to this work: https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/ This internet-draft is largely intended to cover a full IETF specification for the functionality covered by TR-146 and address the minor issues where TR-146 is incompletely specified. : Document History : : 1. Does the working group (WG) consensus represent the strong concurrence of a : few individuals, with others being silent, or did it reach broad agreement? The document has weak but positive Working Group consensus to advance. This is somewhat typical of documents progressing through BFD at this point. That said, the document has had a degree of strong review from the interested parties. : 2. Was there controversy about particular points, or were there decisions where : the consensus was particularly rough? There were several concerns from Greg Mirsky largely regarding the following points: 1. The mechanism specified in the document bypassed the pre-existing BFD Async mechanism which permitted the Echo functionality to be enabled. However, this is exactly the point of this feature. Much of the updates to RFC 5880 are present to permit ths mode. It's important to note that this mechanism is not intended to completely replace the Echo mode for RFC 5880 when used in conjunction with the traditional Async mode. 2. The mechanism specified in the document specified a format for the BFD Echo packets. This would appear to contravene RFC 5880, Section 5. However, the core behavior in the RFC simply states that the contents of the Echo packets are a local matter - and this document is simply defining "the local matter". 3. The normative Security Considerations were not strong enough. Discussion with the authors and Greg eventually has converged with RFC 5082 GTSM procedures being required. This may mean existing implementations of these procedures are non-conformant. However, this does not impact interoperability since the entire point of this feature is a "BFD implementation talking to itself". 4. A further point of discussion is the intended destination and source addresses used by this mechanism. RFC 5881, in particular, provides guidance for the source address selection such that it is not on the same subnet as the destination address in order to prevent unnecessary ICMP/ND redirect messages. However, existing implementations (e.g. Broadcom) use exactly behavior with source and destination addresses being identical. RFC 5881 makes this behavior a SHOULD NOT, so using the same considerations for this mechanism avoids making existing implementations non-conformant. 5. In discussion over the document's intended status, Greg has expressed an opinion that the document should be Experimental rather than Proposed Standard. As noted in the IETF webpage, "Choosing between Informational and Experimental Status", it is the Shepherd's opinion that Experimental is inappropriate. "The "Experimental" designation typically denotes a specification that is part of some research or development effort". In this case, implementations are commercially available utilizing mechanisms largely similar to those being codified in this Internet-Draft. While the procedures in this draft are purely local (the implementation "talks to itself"), the behavior requires a violation of RFC 5880 with regard to Echo procedures only being available after the Up state has been achieved in Asynchronous mode. It is thus the Chairs' opinion that the text permitting the relaxation of that requirement is appropriate to standardize for this document, and thus an appropriate change of status requiring an update to RFC 5880. : 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If : so, please summarize the areas of conflict in separate email messages to the : responsible Area Director. (It should be in a separate email because this : questionnaire is publicly available.) No. : 4. For protocol documents, are there existing implementations of the contents of : the document? Have a significant number of potential implementers indicated : plans to implement? Are any existing implementations reported somewhere, : either in the document itself (as RFC 7942 recommends) or elsewhere : (where)? There are multiple implementations that claim some deployment of BBF TR-146 implementation behavior. : Additional Reviews : : 5. Do the contents of this document closely interact with technologies in other : IETF working groups or external organizations, and would it therefore benefit : from their review? Have those reviews occurred? If yes, describe which : reviews took place. No additional reviews have been requested. : 6. Describe how the document meets any required formal expert review criteria, : such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. This mechanism currently does not have a YANG module. It may benefit from one at some point in the future that extends the existing RFC 9314 YANG module for BFD. : 7. If the document contains a YANG module, has the final version of the module : been checked with any of the recommended validation tools for syntax and : formatting validation? If there are any resulting errors or warnings, what is : the justification for not fixing them at this time? Does the YANG module : comply with the Network Management Datastore Architecture (NMDA) as specified : in RFC 8342? N/A : 8. Describe reviews and automated checks performed to validate sections of the : final version of the document written in a formal language, such as XML code, : BNF rules, MIB definitions, CBOR's CDDL, etc. N/A : Document Shepherd Checks : : 9. Based on the shepherd's review of the document, is it their opinion that this : document is needed, clearly written, complete, correctly designed, and ready : to be handed off to the responsible Area Director? Yes. : 10. Several IETF Areas have assembled lists of common issues that their : reviewers encounter. For which areas have such issues been identified : and addressed? For which does this still need to happen in subsequent : reviews? N/A : 11. What type of RFC publication is being requested on the IETF stream (Best : Current Practice, Proposed Standard, Internet Standard, : Informational, Experimental or Historic)? Why is this the proper type : of RFC? Do all Datatracker state attributes correctly reflect this intent? Proposed Standard. This mechanism leverages existing BFD procedures in a new profile (BFD Async over the Echo port) and is appropriate for the standards track. The Echo port procedures from the core RFC 5880 intentionally leave the contents of the Echo packets out of scope from that document, and thus not a normative change in this document. However, the ability to use BFD state machinery without the associated Async session is a normative change of behavior, even if solely a local one. : 12. Have reasonable efforts been made to remind all authors of the intellectual : property rights (IPR) disclosure obligations described in BCP 79? To : the best of your knowledge, have all required disclosures been filed? If : not, explain why. If yes, summarize any relevant discussion, including links : to publicly-available messages when applicable. IPR attestations: Weiqiang Cheng: https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZWMtOxUKZZbECUmmtLU9ZtZeGEk/ Ruixue Wang: https://mailarchive.ietf.org/arch/msg/rtg-bfd/K9D3KG7MqAm1yk0WaAIOoh5B_Z8/ Xiao Min: https://mailarchive.ietf.org/arch/msg/rtg-bfd/VQRGASf2GGiv6-J4vp515aY0HYs/ Reshad Rahman: https://mailarchive.ietf.org/arch/msg/rtg-bfd/9dEQm-IZy_48pjtkKKTu7yWOXYI/ Raj Chetan Boddireddy: https://mailarchive.ietf.org/arch/msg/rtg-bfd/esD26TKSjvRFJSm0qbcAJ-7EKvo/ It is also necessary to point out that this mechanism is an IETF instantiation of similar procedures from BBF TR-146. See liaison statement referenced above. : 13. Has each author, editor, and contributor shown their willingness to be : listed as such? If the total number of authors and editors on the front page : is greater than five, please provide a justification. Yes. There are exactly five authors. : 14. Document any remaining I-D nits in this document. Simply running the idnits : tool is not enough; please review the "Content Guidelines" on : authors.ietf.org. (Also note that the current idnits tool generates : some incorrect warnings; a rewrite is underway.) There are no nits noted in version -10. : 15. Should any informative references be normative or vice-versa? See the IESG : Statement on Normative and Informative References. No. : 16. List any normative references that are not freely available to anyone. Did : the community have sufficient access to review any such normative : references? All references, including the Informative BBF TR-146 reference, are publicly available. : 17. Are there any normative downward references (see RFC 3967 and BCP : 97) that are not already listed in the DOWNREF registry? If so, : list them. No. : 18. Are there normative references to documents that are not ready to be : submitted to the IESG for publication or are otherwise in an unclear state? : If so, what is the plan for their completion? No such references. : 19. Will publication of this document change the status of any existing RFCs? If : so, does the Datatracker metadata correctly reflect this and are those RFCs : listed on the title page, in the abstract, and discussed in the : introduction? If not, explain why and point to the part of the document : where the relationship of this document to these other RFCs is discussed. This document does not change the status of other existing RFCs. : 20. Describe the document shepherd's review of the IANA considerations section, : especially with regard to its consistency with the body of the document. : Confirm that all aspects of the document requiring IANA assignments are : associated with the appropriate reservations in IANA registries. Confirm : that any referenced IANA registries have been clearly identified. Confirm : that each newly created IANA registry specifies its initial contents, : allocations procedures, and a reasonable name (see RFC 8126). This document makes no further requests from IANA. : 21. List any new IANA registries that require Designated Expert Review for : future allocations. Are the instructions to the Designated Expert clear? : Please include suggestions of designated experts, if appropriate. N/A |
2024-01-15
|
10 | Jeffrey Haas | Prelude: The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap with a similar feature specified in BBF TR-146. A liaison statement was exchanged with BBF with … Prelude: The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap with a similar feature specified in BBF TR-146. A liaison statement was exchanged with BBF with regard to this work: https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/ This internet-draft is largely intended to cover a full IETF specification for the functionality covered by TR-146 and address the minor issues where TR-146 is incompletely specified. : Document History : : 1. Does the working group (WG) consensus represent the strong concurrence of a : few individuals, with others being silent, or did it reach broad agreement? The document has weak but positive Working Group consensus to advance. This is somewhat typical of documents progressing through BFD at this point. That said, the document has had a degree of strong review from the interested parties. : 2. Was there controversy about particular points, or were there decisions where : the consensus was particularly rough? There were several concerns from Greg Mirsky largely regarding the following points: 1. The mechanism specified in the document bypassed the pre-existing BFD Async mechanism which permitted the Echo functionality to be enabled. However, this is exactly the point of this feature. Much of the updates to RFC 5880 are present to permit ths mode. It's important to note that this mechanism is not intended to completely replace the Echo mode for RFC 5880 when used in conjunction with the traditional Async mode. 2. The mechanism specified in the document specified a format for the BFD Echo packets. This would appear to contravene RFC 5880, Section 5. However, the core behavior in the RFC simply states that the contents of the Echo packets are a local matter - and this document is simply defining "the local matter". 3. The normative Security Considerations were not strong enough. Discussion with the authors and Greg eventually has converged with RFC 5082 GTSM procedures being required. This may mean existing implementations of these procedures are non-conformant. However, this does not impact interoperability since the entire point of this feature is a "BFD implementation talking to itself". 4. A further point of discussion is the intended destination and source addresses used by this mechanism. RFC 5881, in particular, provides guidance for the source address selection such that it is not on the same subnet as the destination address in order to prevent unnecessary ICMP/ND redirect messages. However, existing implementations (e.g. Broadcom) use exactly behavior with source and destination addresses being identical. RFC 5881 makes this behavior a SHOULD NOT, so using the same considerations for this mechanism avoids making existing implementations non-conformant. : 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If : so, please summarize the areas of conflict in separate email messages to the : responsible Area Director. (It should be in a separate email because this : questionnaire is publicly available.) No. : 4. For protocol documents, are there existing implementations of the contents of : the document? Have a significant number of potential implementers indicated : plans to implement? Are any existing implementations reported somewhere, : either in the document itself (as RFC 7942 recommends) or elsewhere : (where)? There are multiple implementations that claim some deployment of BBF TR-146 implementation behavior. : Additional Reviews : : 5. Do the contents of this document closely interact with technologies in other : IETF working groups or external organizations, and would it therefore benefit : from their review? Have those reviews occurred? If yes, describe which : reviews took place. No additional reviews have been requested. : 6. Describe how the document meets any required formal expert review criteria, : such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. This mechanism currently does not have a YANG module. It may benefit from one at some point in the future that extends the existing RFC 9314 YANG module for BFD. : 7. If the document contains a YANG module, has the final version of the module : been checked with any of the recommended validation tools for syntax and : formatting validation? If there are any resulting errors or warnings, what is : the justification for not fixing them at this time? Does the YANG module : comply with the Network Management Datastore Architecture (NMDA) as specified : in RFC 8342? N/A : 8. Describe reviews and automated checks performed to validate sections of the : final version of the document written in a formal language, such as XML code, : BNF rules, MIB definitions, CBOR's CDDL, etc. N/A : Document Shepherd Checks : : 9. Based on the shepherd's review of the document, is it their opinion that this : document is needed, clearly written, complete, correctly designed, and ready : to be handed off to the responsible Area Director? Yes. : 10. Several IETF Areas have assembled lists of common issues that their : reviewers encounter. For which areas have such issues been identified : and addressed? For which does this still need to happen in subsequent : reviews? N/A : 11. What type of RFC publication is being requested on the IETF stream (Best : Current Practice, Proposed Standard, Internet Standard, : Informational, Experimental or Historic)? Why is this the proper type : of RFC? Do all Datatracker state attributes correctly reflect this intent? Proposed Standard. This mechanism leverages existing BFD procedures in a new profile (BFD Async over the Echo port) and is appropriate for the standards track. The Echo port procedures from the core RFC 5880 intentionally leave the contents of the Echo packets out of scope from that document, and thus not a normative change in this document. However, the ability to use BFD state machinery without the associated Async session is a normative change of behavior, even if solely a local one. : 12. Have reasonable efforts been made to remind all authors of the intellectual : property rights (IPR) disclosure obligations described in BCP 79? To : the best of your knowledge, have all required disclosures been filed? If : not, explain why. If yes, summarize any relevant discussion, including links : to publicly-available messages when applicable. IPR attestations: Weiqiang Cheng: https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZWMtOxUKZZbECUmmtLU9ZtZeGEk/ Ruixue Wang: https://mailarchive.ietf.org/arch/msg/rtg-bfd/K9D3KG7MqAm1yk0WaAIOoh5B_Z8/ Xiao Min: https://mailarchive.ietf.org/arch/msg/rtg-bfd/VQRGASf2GGiv6-J4vp515aY0HYs/ Reshad Rahman: https://mailarchive.ietf.org/arch/msg/rtg-bfd/9dEQm-IZy_48pjtkKKTu7yWOXYI/ Raj Chetan Boddireddy: https://mailarchive.ietf.org/arch/msg/rtg-bfd/esD26TKSjvRFJSm0qbcAJ-7EKvo/ It is also necessary to point out that this mechanism is an IETF instantiation of similar procedures from BBF TR-146. See liaison statement referenced above. : 13. Has each author, editor, and contributor shown their willingness to be : listed as such? If the total number of authors and editors on the front page : is greater than five, please provide a justification. Yes. There are exactly five authors. : 14. Document any remaining I-D nits in this document. Simply running the idnits : tool is not enough; please review the "Content Guidelines" on : authors.ietf.org. (Also note that the current idnits tool generates : some incorrect warnings; a rewrite is underway.) There are no nits noted in version -10. : 15. Should any informative references be normative or vice-versa? See the IESG : Statement on Normative and Informative References. No. : 16. List any normative references that are not freely available to anyone. Did : the community have sufficient access to review any such normative : references? All references, including the Informative BBF TR-146 reference, are publicly available. : 17. Are there any normative downward references (see RFC 3967 and BCP : 97) that are not already listed in the DOWNREF registry? If so, : list them. No. : 18. Are there normative references to documents that are not ready to be : submitted to the IESG for publication or are otherwise in an unclear state? : If so, what is the plan for their completion? No such references. : 19. Will publication of this document change the status of any existing RFCs? If : so, does the Datatracker metadata correctly reflect this and are those RFCs : listed on the title page, in the abstract, and discussed in the : introduction? If not, explain why and point to the part of the document : where the relationship of this document to these other RFCs is discussed. This document does not change the status of other existing RFCs. : 20. Describe the document shepherd's review of the IANA considerations section, : especially with regard to its consistency with the body of the document. : Confirm that all aspects of the document requiring IANA assignments are : associated with the appropriate reservations in IANA registries. Confirm : that any referenced IANA registries have been clearly identified. Confirm : that each newly created IANA registry specifies its initial contents, : allocations procedures, and a reasonable name (see RFC 8126). This document makes no further requests from IANA. : 21. List any new IANA registries that require Designated Expert Review for : future allocations. Are the instructions to the Designated Expert clear? : Please include suggestions of designated experts, if appropriate. N/A |
2024-01-15
|
10 | Jeffrey Haas | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2024-01-15
|
10 | Jeffrey Haas | IESG state changed to Publication Requested from I-D Exists |
2024-01-15
|
10 | (System) | Changed action holders to John Scudder (IESG state changed) |
2024-01-15
|
10 | Jeffrey Haas | Responsible AD changed to John Scudder |
2024-01-15
|
10 | Jeffrey Haas | Document is now in IESG state Publication Requested |
2024-01-15
|
10 | Jeffrey Haas | Tags Doc Shepherd Follow-up Underway, Revised I-D Needed - Issue raised by WGLC cleared. |
2024-01-15
|
10 | Jeffrey Haas | Changed consensus to Yes from Unknown |
2024-01-15
|
10 | Jeffrey Haas | Intended Status changed to Proposed Standard from None |
2024-01-15
|
10 | Jeffrey Haas | Prelude: The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap with a similar feature specified in BBF TR-146. A liaison statement was exchanged with BBF with … Prelude: The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap with a similar feature specified in BBF TR-146. A liaison statement was exchanged with BBF with regard to this work: https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/ This internet-draft is largely intended to cover a full IETF specification for the functionality covered by TR-146 and address the minor issues where TR-146 is incompletely specified. : Document History : : 1. Does the working group (WG) consensus represent the strong concurrence of a : few individuals, with others being silent, or did it reach broad agreement? The document has weak but positive Working Group consensus to advance. This is somewhat typical of documents progressing through BFD at this point. That said, the document has had a degree of strong review from the interested parties. : 2. Was there controversy about particular points, or were there decisions where : the consensus was particularly rough? There were several concerns from Greg Mirsky largely regarding the following points: 1. The mechanism specified in the document bypassed the pre-existing BFD Async mechanism which permitted the Echo functionality to be enabled. However, this is exactly the point of this feature. Much of the updates to RFC 5880 are present to permit ths mode. It's important to note that this mechanism is not intended to completely replace the Echo mode for RFC 5880 when used in conjunction with the traditional Async mode. 2. The mechanism specified in the document specified a format for the BFD Echo packets. This would appear to contravene RFC 5880, Section 5. However, the core behavior in the RFC simply states that the contents of the Echo packets are a local matter - and this document is simply defining "the local matter". 3. The normative Security Considerations were not strong enough. Discussion with the authors and Greg eventually has converged with RFC 5082 GTSM procedures being required. This may mean existing implementations of these procedures are non-conformant. However, this does not impact interoperability since the entire point of this feature is a "BFD implementation talking to itself". 4. A further point of discussion is the intended destination and source addresses used by this mechanism. RFC 5881, in particular, provides guidance for the source address selection such that it is not on the same subnet as the destination address in order to prevent unnecessary ICMP/ND redirect messages. However, existing implementations (e.g. Broadcom) use exactly behavior with source and destination addresses being identical. RFC 5881 makes this behavior a SHOULD NOT, so using the same considerations for this mechanism avoids making existing implementations non-conformant. : 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If : so, please summarize the areas of conflict in separate email messages to the : responsible Area Director. (It should be in a separate email because this : questionnaire is publicly available.) No. : 4. For protocol documents, are there existing implementations of the contents of : the document? Have a significant number of potential implementers indicated : plans to implement? Are any existing implementations reported somewhere, : either in the document itself (as RFC 7942 recommends) or elsewhere : (where)? There are multiple implementations that claim some deployment of BBF TR-146 implementation behavior. : Additional Reviews : : 5. Do the contents of this document closely interact with technologies in other : IETF working groups or external organizations, and would it therefore benefit : from their review? Have those reviews occurred? If yes, describe which : reviews took place. No additional reviews have been requested. : 6. Describe how the document meets any required formal expert review criteria, : such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. This mechanism currently does not have a YANG module. It may benefit from one at some point in the future that extends the existing RFC 9314 YANG module for BFD. : 7. If the document contains a YANG module, has the final version of the module : been checked with any of the recommended validation tools for syntax and : formatting validation? If there are any resulting errors or warnings, what is : the justification for not fixing them at this time? Does the YANG module : comply with the Network Management Datastore Architecture (NMDA) as specified : in RFC 8342? N/A : 8. Describe reviews and automated checks performed to validate sections of the : final version of the document written in a formal language, such as XML code, : BNF rules, MIB definitions, CBOR's CDDL, etc. N/A : Document Shepherd Checks : : 9. Based on the shepherd's review of the document, is it their opinion that this : document is needed, clearly written, complete, correctly designed, and ready : to be handed off to the responsible Area Director? Yes. : 10. Several IETF Areas have assembled lists of common issues that their : reviewers encounter. For which areas have such issues been identified : and addressed? For which does this still need to happen in subsequent : reviews? N/A : 11. What type of RFC publication is being requested on the IETF stream (Best : Current Practice, Proposed Standard, Internet Standard, : Informational, Experimental or Historic)? Why is this the proper type : of RFC? Do all Datatracker state attributes correctly reflect this intent? Proposed Standard. This mechanism leverages existing BFD procedures in a new profile (BFD Async over the Echo port) and is appropriate for the standards track. The Echo port procedures from the core RFC 5880 intentionally leave the contents of the Echo packets out of scope from that document, and thus not a normative change in this document. However, the ability to use BFD state machinery without the associated Async session is a normative change of behavior, even if solely a local one. : 12. Have reasonable efforts been made to remind all authors of the intellectual : property rights (IPR) disclosure obligations described in BCP 79? To : the best of your knowledge, have all required disclosures been filed? If : not, explain why. If yes, summarize any relevant discussion, including links : to publicly-available messages when applicable. IPR attestations: Weiqiang Cheng: https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZWMtOxUKZZbECUmmtLU9ZtZeGEk/ Ruixue Wang: https://mailarchive.ietf.org/arch/msg/rtg-bfd/K9D3KG7MqAm1yk0WaAIOoh5B_Z8/ Xiao Min: https://mailarchive.ietf.org/arch/msg/rtg-bfd/VQRGASf2GGiv6-J4vp515aY0HYs/ Reshad Rahman: https://mailarchive.ietf.org/arch/msg/rtg-bfd/9dEQm-IZy_48pjtkKKTu7yWOXYI/ Raj Chetan Boddireddy: https://mailarchive.ietf.org/arch/msg/rtg-bfd/esD26TKSjvRFJSm0qbcAJ-7EKvo/ It is also necessary to point out that this mechanism is an IETF instantiation of similar procedures from BBF TR-146. See liaison statement referenced above. : 13. Has each author, editor, and contributor shown their willingness to be : listed as such? If the total number of authors and editors on the front page : is greater than five, please provide a justification. Yes. There are exactly five authors. : 14. Document any remaining I-D nits in this document. Simply running the idnits : tool is not enough; please review the "Content Guidelines" on : authors.ietf.org. (Also note that the current idnits tool generates : some incorrect warnings; a rewrite is underway.) There are no nits noted in version -10. : 15. Should any informative references be normative or vice-versa? See the IESG : Statement on Normative and Informative References. No. : 16. List any normative references that are not freely available to anyone. Did : the community have sufficient access to review any such normative : references? All references, including the Informative BBF TR-146 reference, are publicly available. : 17. Are there any normative downward references (see RFC 3967 and BCP : 97) that are not already listed in the DOWNREF registry? If so, : list them. No. : 18. Are there normative references to documents that are not ready to be : submitted to the IESG for publication or are otherwise in an unclear state? : If so, what is the plan for their completion? No such references. : 19. Will publication of this document change the status of any existing RFCs? If : so, does the Datatracker metadata correctly reflect this and are those RFCs : listed on the title page, in the abstract, and discussed in the : introduction? If not, explain why and point to the part of the document : where the relationship of this document to these other RFCs is discussed. This document does not change the status of other existing RFCs. : 20. Describe the document shepherd's review of the IANA considerations section, : especially with regard to its consistency with the body of the document. : Confirm that all aspects of the document requiring IANA assignments are : associated with the appropriate reservations in IANA registries. Confirm : that any referenced IANA registries have been clearly identified. Confirm : that each newly created IANA registry specifies its initial contents, : allocations procedures, and a reasonable name (see RFC 8126). This document makes no further requests from IANA. : 21. List any new IANA registries that require Designated Expert Review for : future allocations. Are the instructions to the Designated Expert clear? : Please include suggestions of designated experts, if appropriate. N/A |
2023-09-28
|
10 | Xiao Min | New version available: draft-ietf-bfd-unaffiliated-echo-10.txt |
2023-09-28
|
10 | Xiao Min | New version accepted (logged-in submitter: Xiao Min) |
2023-09-28
|
10 | Xiao Min | Uploaded new revision |
2023-09-26
|
09 | Xiao Min | New version available: draft-ietf-bfd-unaffiliated-echo-09.txt |
2023-09-26
|
09 | Xiao Min | New version accepted (logged-in submitter: Xiao Min) |
2023-09-26
|
09 | Xiao Min | Uploaded new revision |
2023-07-05
|
08 | Xiao Min | New version available: draft-ietf-bfd-unaffiliated-echo-08.txt |
2023-07-05
|
08 | Xiao Min | New version accepted (logged-in submitter: Xiao Min) |
2023-07-05
|
08 | Xiao Min | Uploaded new revision |
2023-04-24
|
07 | Jeffrey Haas | Prelude: The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap with a similar feature specified in BBF TR-146. A liaison statement was exchanged with BBF with … Prelude: The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap with a similar feature specified in BBF TR-146. A liaison statement was exchanged with BBF with regard to this work: https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/ This internet-draft is largely intended to cover a full IETF specification for the functionality covered by TR-146 and address the minor issues where TR-146 is incompletely specified. : Document History : : 1. Does the working group (WG) consensus represent the strong concurrence of a : few individuals, with others being silent, or did it reach broad agreement? The document has weak but positive Working Group consensus to advance. This is somewhat typical of documents progressing through BFD at this point. : 2. Was there controversy about particular points, or were there decisions where : the consensus was particularly rough? There were several concerns from Greg Mirsky largely regarding the following points: 1. The mechanism specified in the document bypassed the pre-existing BFD Async mechanism which permitted the Echo functionality to be enabled. However, this is exactly the point of this feature. Much of the updates to RFC 5880 are present to permit ths mode. It's important to note that this mechanism is not intended to completely replace the Echo mode for RFC 5880 when used in conjunction with the traditional Async mode. 2. The mechanism specified in the document specified a format for the BFD Echo packets. This would appear to contravene RFC 5880, Section 5. However, the core behavior in the RFC simply states that the contents of the Echo packets are a local matter - and this document is simply defining "the local matter". 3. The normative Security Considerations are not strong enough, particularly in the requirement that RFC 5082 GTSM procedures MUST be utilized by the host providing the loopback services. While a great idea in general, this document largely exists to provide an IETF definition of a feature already described in BBF TR-146. Such default limitation of the loopback may not be widely deployed and thus the more restrictive MUST requirements for GTSM would make existing deployments non-conformant. 4. A further point of discussion is the intended destination and source addresses used by this mechanism. RFC 5881, in particular, provides guidance for the source address selection such that it is not on the same subnet as the destination address in order to prevent unnecessary ICMP/ND redirect messages. However, existing implementations (e.g. Broadcom) use exactly behavior with source and destination addresses being identical. RFC 5881 makes this behavior a SHOULD NOT, so using the same considerations for this mechanism avoids making existing implementations non-conformant. : 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If : so, please summarize the areas of conflict in separate email messages to the : responsible Area Director. (It should be in a separate email because this : questionnaire is publicly available.) No. : 4. For protocol documents, are there existing implementations of the contents of : the document? Have a significant number of potential implementers indicated : plans to implement? Are any existing implementations reported somewhere, : either in the document itself (as RFC 7942 recommends) or elsewhere : (where)? There are multiple implementations that claim some deployment of BBF TR-146 implementation behavior. : Additional Reviews : : 5. Do the contents of this document closely interact with technologies in other : IETF working groups or external organizations, and would it therefore benefit : from their review? Have those reviews occurred? If yes, describe which : reviews took place. No additional reviews have been requested. : 6. Describe how the document meets any required formal expert review criteria, : such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. This mechanism currently does not have a YANG module. It may benefit from one at some point in the future that extends the existing RFC 9314 YANG module for BFD. : 7. If the document contains a YANG module, has the final version of the module : been checked with any of the recommended validation tools for syntax and : formatting validation? If there are any resulting errors or warnings, what is : the justification for not fixing them at this time? Does the YANG module : comply with the Network Management Datastore Architecture (NMDA) as specified : in RFC 8342? N/A : 8. Describe reviews and automated checks performed to validate sections of the : final version of the document written in a formal language, such as XML code, : BNF rules, MIB definitions, CBOR's CDDL, etc. N/A : Document Shepherd Checks : : 9. Based on the shepherd's review of the document, is it their opinion that this : document is needed, clearly written, complete, correctly designed, and ready : to be handed off to the responsible Area Director? Yes. : 10. Several IETF Areas have assembled lists of common issues that their : reviewers encounter. For which areas have such issues been identified : and addressed? For which does this still need to happen in subsequent : reviews? N/A : 11. What type of RFC publication is being requested on the IETF stream (Best : Current Practice, Proposed Standard, Internet Standard, : Informational, Experimental or Historic)? Why is this the proper type : of RFC? Do all Datatracker state attributes correctly reflect this intent? Proposed Standard. This mechanism leverages existing BFD procedures in a new profile (BFD Async over the Echo port) and is appropriate for the standards track. The Echo port procedures from the core RFC 5880 intentionally leave the contents of the Echo packets out of scope from that document, and thus not a normative change in this document. However, the ability to use BFD state machinery without the associated Async session is a normative change of behavior, even if solely a local one. : 12. Have reasonable efforts been made to remind all authors of the intellectual : property rights (IPR) disclosure obligations described in BCP 79? To : the best of your knowledge, have all required disclosures been filed? If : not, explain why. If yes, summarize any relevant discussion, including links : to publicly-available messages when applicable. IPR attestations from the authors are currently pending. (10 April, 2023) The document will be progressed to the IESG once the attestations are all accounted for. IPR attestations: Weiqiang Cheng: https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZWMtOxUKZZbECUmmtLU9ZtZeGEk/ Ruixue Wang: https://mailarchive.ietf.org/arch/msg/rtg-bfd/K9D3KG7MqAm1yk0WaAIOoh5B_Z8/ Xiao Min: https://mailarchive.ietf.org/arch/msg/rtg-bfd/VQRGASf2GGiv6-J4vp515aY0HYs/ Reshad Rahman: https://mailarchive.ietf.org/arch/msg/rtg-bfd/9dEQm-IZy_48pjtkKKTu7yWOXYI/ Raj Chetan Boddireddy: https://mailarchive.ietf.org/arch/msg/rtg-bfd/esD26TKSjvRFJSm0qbcAJ-7EKvo/ It is also necessary to point out that this mechanism is an IETF instantiation of similar procedures from BBF TR-146. See liaison statement referenced above. : 13. Has each author, editor, and contributor shown their willingness to be : listed as such? If the total number of authors and editors on the front page : is greater than five, please provide a justification. Yes. There are exactly five authors. : 14. Document any remaining I-D nits in this document. Simply running the idnits : tool is not enough; please review the "Content Guidelines" on : authors.ietf.org. (Also note that the current idnits tool generates : some incorrect warnings; a rewrite is underway.) There are no nits noted in version -07. : 15. Should any informative references be normative or vice-versa? See the IESG : Statement on Normative and Informative References. No. : 16. List any normative references that are not freely available to anyone. Did : the community have sufficient access to review any such normative : references? All references, including the Informative BBF TR-146 reference, are publicly available. : 17. Are there any normative downward references (see RFC 3967 and BCP : 97) that are not already listed in the DOWNREF registry? If so, : list them. No. : 18. Are there normative references to documents that are not ready to be : submitted to the IESG for publication or are otherwise in an unclear state? : If so, what is the plan for their completion? No such references. : 19. Will publication of this document change the status of any existing RFCs? If : so, does the Datatracker metadata correctly reflect this and are those RFCs : listed on the title page, in the abstract, and discussed in the : introduction? If not, explain why and point to the part of the document : where the relationship of this document to these other RFCs is discussed. This document does not change the status of other existing RFCs. : 20. Describe the document shepherd's review of the IANA considerations section, : especially with regard to its consistency with the body of the document. : Confirm that all aspects of the document requiring IANA assignments are : associated with the appropriate reservations in IANA registries. Confirm : that any referenced IANA registries have been clearly identified. Confirm : that each newly created IANA registry specifies its initial contents, : allocations procedures, and a reasonable name (see RFC 8126). This document makes no further requests from IANA. : 21. List any new IANA registries that require Designated Expert Review for : future allocations. Are the instructions to the Designated Expert clear? : Please include suggestions of designated experts, if appropriate. N/A |
2023-04-23
|
07 | Xiao Min | New version available: draft-ietf-bfd-unaffiliated-echo-07.txt |
2023-04-23
|
07 | Xiao Min | New version accepted (logged-in submitter: Xiao Min) |
2023-04-23
|
07 | Xiao Min | Uploaded new revision |
2023-04-11
|
06 | Jeffrey Haas | Prelude: The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap with a similar feature specified in BBF TR-146. A liaison statement was exchanged with BBF with … Prelude: The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap with a similar feature specified in BBF TR-146. A liaison statement was exchanged with BBF with regard to this work: https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/ This internet-draft is largely intended to cover a full IETF specification for the functionality covered by TR-146 and address the minor issues where TR-146 is incompletely specified. : Document History : : 1. Does the working group (WG) consensus represent the strong concurrence of a : few individuals, with others being silent, or did it reach broad agreement? The document has weak but positive Working Group consensus to advance. This is somewhat typical of documents progressing through BFD at this point. : 2. Was there controversy about particular points, or were there decisions where : the consensus was particularly rough? There were several concerns from Greg Mirsky largely regarding the following points: 1. The mechanism specified in the document bypassed the pre-existing BFD Async mechanism which permitted the Echo functionality to be enabled. However, this is exactly the point of this feature. Much of the updates to RFC 5880 are present to permit ths mode. It's important to note that this mechanism is not intended to completely replace the Echo mode for RFC 5880 when used in conjunction with the traditional Async mode. 2. The mechanism specified in the document specified a format for the BFD Echo packets. This would appear to contravene RFC 5880, Section 5. However, the core behavior in the RFC simply states that the contents of the Echo packets are a local matter - and this document is simply defining "the local matter". 3. The normative Security Considerations are not strong enough, particularly in the requirement that RFC 5082 GTSM procedures MUST be utilized by the host providing the loopback services. While a great idea in general, this document largely exists to provide an IETF definition of a feature already described in BBF TR-146. Such default limitation of the loopback may not be widely deployed and thus the more restrictive MUST requirements for GTSM would make existing deployments non-conformant. 4. A further point of discussion is the intended destination and source addresses used by this mechanism. RFC 5881, in particular, provides guidance for the source address selection such that it is not on the same subnet as the destination address in order to prevent unnecessary ICMP/ND redirect messages. However, existing implementations (e.g. Broadcom) use exactly behavior with source and destination addresses being identical. RFC 5881 makes this behavior a SHOULD NOT, so using the same considerations for this mechanism avoids making existing implementations non-conformant. : 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If : so, please summarize the areas of conflict in separate email messages to the : responsible Area Director. (It should be in a separate email because this : questionnaire is publicly available.) No. : 4. For protocol documents, are there existing implementations of the contents of : the document? Have a significant number of potential implementers indicated : plans to implement? Are any existing implementations reported somewhere, : either in the document itself (as RFC 7942 recommends) or elsewhere : (where)? There are multiple implementations that claim some deployment of BBF TR-146 implementation behavior. : Additional Reviews : : 5. Do the contents of this document closely interact with technologies in other : IETF working groups or external organizations, and would it therefore benefit : from their review? Have those reviews occurred? If yes, describe which : reviews took place. No additional reviews have been requested. : 6. Describe how the document meets any required formal expert review criteria, : such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. This mechanism currently does not have a YANG module. It may benefit from one at some point in the future that extends the existing RFC 9314 YANG module for BFD. : 7. If the document contains a YANG module, has the final version of the module : been checked with any of the recommended validation tools for syntax and : formatting validation? If there are any resulting errors or warnings, what is : the justification for not fixing them at this time? Does the YANG module : comply with the Network Management Datastore Architecture (NMDA) as specified : in RFC 8342? N/A : 8. Describe reviews and automated checks performed to validate sections of the : final version of the document written in a formal language, such as XML code, : BNF rules, MIB definitions, CBOR's CDDL, etc. N/A : Document Shepherd Checks : : 9. Based on the shepherd's review of the document, is it their opinion that this : document is needed, clearly written, complete, correctly designed, and ready : to be handed off to the responsible Area Director? The document is integrating comments raised during Working Group Last Call and should be ready for progression afterwards. : 10. Several IETF Areas have assembled lists of common issues that their : reviewers encounter. For which areas have such issues been identified : and addressed? For which does this still need to happen in subsequent : reviews? N/A : 11. What type of RFC publication is being requested on the IETF stream (Best : Current Practice, Proposed Standard, Internet Standard, : Informational, Experimental or Historic)? Why is this the proper type : of RFC? Do all Datatracker state attributes correctly reflect this intent? Proposed Standard. This mechanism leverages existing BFD procedures in a new profile (BFD Async over the Echo port) and is appropriate for the standards track. : 12. Have reasonable efforts been made to remind all authors of the intellectual : property rights (IPR) disclosure obligations described in BCP 79? To : the best of your knowledge, have all required disclosures been filed? If : not, explain why. If yes, summarize any relevant discussion, including links : to publicly-available messages when applicable. IPR attestations from the authors are currently pending. (10 April, 2023) The document will be progressed to the IESG once the attestations are all accounted for. IPR attestations: Weiqiang Cheng: https://mailarchive.ietf.org/arch/msg/rtg-bfd/ZWMtOxUKZZbECUmmtLU9ZtZeGEk/ Ruixue Wang: https://mailarchive.ietf.org/arch/msg/rtg-bfd/K9D3KG7MqAm1yk0WaAIOoh5B_Z8/ Xiao Min: https://mailarchive.ietf.org/arch/msg/rtg-bfd/VQRGASf2GGiv6-J4vp515aY0HYs/ Reshad Rahman: https://mailarchive.ietf.org/arch/msg/rtg-bfd/9dEQm-IZy_48pjtkKKTu7yWOXYI/ Raj Chetan Boddireddy: It is also necessary to point out that this mechanism is an IETF instantiation of similar procedures from BBF TR-146. See liaison statement referenced above. : 13. Has each author, editor, and contributor shown their willingness to be : listed as such? If the total number of authors and editors on the front page : is greater than five, please provide a justification. Yes. There are exactly five authors. : 14. Document any remaining I-D nits in this document. Simply running the idnits : tool is not enough; please review the "Content Guidelines" on : authors.ietf.org. (Also note that the current idnits tool generates : some incorrect warnings; a rewrite is underway.) There are no nits noted in version -06. : 15. Should any informative references be normative or vice-versa? See the IESG : Statement on Normative and Informative References. No. : 16. List any normative references that are not freely available to anyone. Did : the community have sufficient access to review any such normative : references? All references, including the Informative BBF TR-146 reference, are publicly available. : 17. Are there any normative downward references (see RFC 3967 and BCP : 97) that are not already listed in the DOWNREF registry? If so, : list them. No. : 18. Are there normative references to documents that are not ready to be : submitted to the IESG for publication or are otherwise in an unclear state? : If so, what is the plan for their completion? No such references. : 19. Will publication of this document change the status of any existing RFCs? If : so, does the Datatracker metadata correctly reflect this and are those RFCs : listed on the title page, in the abstract, and discussed in the : introduction? If not, explain why and point to the part of the document : where the relationship of this document to these other RFCs is discussed. This document does not change the status of other existing RFCs. : 20. Describe the document shepherd's review of the IANA considerations section, : especially with regard to its consistency with the body of the document. : Confirm that all aspects of the document requiring IANA assignments are : associated with the appropriate reservations in IANA registries. Confirm : that any referenced IANA registries have been clearly identified. Confirm : that each newly created IANA registry specifies its initial contents, : allocations procedures, and a reasonable name (see RFC 8126). This document makes no further requests from IANA. : 21. List any new IANA registries that require Designated Expert Review for : future allocations. Are the instructions to the Designated Expert clear? : Please include suggestions of designated experts, if appropriate. N/A |
2023-04-10
|
06 | Jeffrey Haas | Prelude: The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap with a similar feature specified in BBF TR-146. A liaison statement was exchanged with BBF with … Prelude: The mechanism described in draft-ietf-bfd-unaffiliated has significant overlap with a similar feature specified in BBF TR-146. A liaison statement was exchanged with BBF with regard to this work: https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/ This internet-draft is largely intended to cover a full IETF specification for the functionality covered by TR-146 and address the minor issues where TR-146 is incompletely specified. : Document History : : 1. Does the working group (WG) consensus represent the strong concurrence of a : few individuals, with others being silent, or did it reach broad agreement? The document has weak but positive Working Group consensus to advance. This is somewhat typical of documents progressing through BFD at this point. : 2. Was there controversy about particular points, or were there decisions where : the consensus was particularly rough? There were several concerns from Greg Mirsky largely regarding the following points: 1. The mechanism specified in the document bypassed the pre-existing BFD Async mechanism which permitted the Echo functionality to be enabled. However, this is exactly the point of this feature. Much of the updates to RFC 5880 are present to permit ths mode. It's important to note that this mechanism is not intended to completely replace the Echo mode for RFC 5880 when used in conjunction with the traditional Async mode. 2. The mechanism specified in the document specified a format for the BFD Echo packets. This would appear to contravene RFC 5880, Section 5. However, the core behavior in the RFC simply states that the contents of the Echo packets are a local matter - and this document is simply defining "the local matter". 3. The normative Security Considerations are not strong enough, particularly in the requirement that RFC 5082 GTSM procedures MUST be utilized by the host providing the loopback services. While a great idea in general, this document largely exists to provide an IETF definition of a feature already described in BBF TR-146. Such default limitation of the loopback may not be widely deployed and thus the more restrictive MUST requirements for GTSM would make existing deployments non-conformant. 4. A further point of discussion is the intended destination and source addresses used by this mechanism. RFC 5881, in particular, provides guidance for the source address selection such that it is not on the same subnet as the destination address in order to prevent unnecessary ICMP/ND redirect messages. However, existing implementations (e.g. Broadcom) use exactly behavior with source and destination addresses being identical. RFC 5881 makes this behavior a SHOULD NOT, so using the same considerations for this mechanism avoids making existing implementations non-conformant. : 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If : so, please summarize the areas of conflict in separate email messages to the : responsible Area Director. (It should be in a separate email because this : questionnaire is publicly available.) No. : 4. For protocol documents, are there existing implementations of the contents of : the document? Have a significant number of potential implementers indicated : plans to implement? Are any existing implementations reported somewhere, : either in the document itself (as RFC 7942 recommends) or elsewhere : (where)? There are multiple implementations that claim some deployment of BBF TR-146 implementation behavior. : Additional Reviews : : 5. Do the contents of this document closely interact with technologies in other : IETF working groups or external organizations, and would it therefore benefit : from their review? Have those reviews occurred? If yes, describe which : reviews took place. No additional reviews have been requested. : 6. Describe how the document meets any required formal expert review criteria, : such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. This mechanism currently does not have a YANG module. It may benefit from one at some point in the future that extends the existing RFC 9314 YANG module for BFD. : 7. If the document contains a YANG module, has the final version of the module : been checked with any of the recommended validation tools for syntax and : formatting validation? If there are any resulting errors or warnings, what is : the justification for not fixing them at this time? Does the YANG module : comply with the Network Management Datastore Architecture (NMDA) as specified : in RFC 8342? N/A : 8. Describe reviews and automated checks performed to validate sections of the : final version of the document written in a formal language, such as XML code, : BNF rules, MIB definitions, CBOR's CDDL, etc. N/A : Document Shepherd Checks : : 9. Based on the shepherd's review of the document, is it their opinion that this : document is needed, clearly written, complete, correctly designed, and ready : to be handed off to the responsible Area Director? The document is integrating comments raised during Working Group Last Call and should be ready for progression afterwards. : 10. Several IETF Areas have assembled lists of common issues that their : reviewers encounter. For which areas have such issues been identified : and addressed? For which does this still need to happen in subsequent : reviews? N/A : 11. What type of RFC publication is being requested on the IETF stream (Best : Current Practice, Proposed Standard, Internet Standard, : Informational, Experimental or Historic)? Why is this the proper type : of RFC? Do all Datatracker state attributes correctly reflect this intent? Proposed Standard. This mechanism leverages existing BFD procedures in a new profile (BFD Async over the Echo port) and is appropriate for the standards track. : 12. Have reasonable efforts been made to remind all authors of the intellectual : property rights (IPR) disclosure obligations described in BCP 79? To : the best of your knowledge, have all required disclosures been filed? If : not, explain why. If yes, summarize any relevant discussion, including links : to publicly-available messages when applicable. IPR attestations from the authors are currently pending. (10 April, 2023) The document will be progressed to the IESG once the attestations are all accounted for. It is also necessary to point out that this mechanism is an IETF instantiation of similar procedures from BBF TR-146. See liaison statement referenced above. : 13. Has each author, editor, and contributor shown their willingness to be : listed as such? If the total number of authors and editors on the front page : is greater than five, please provide a justification. Yes. There are exactly five authors. : 14. Document any remaining I-D nits in this document. Simply running the idnits : tool is not enough; please review the "Content Guidelines" on : authors.ietf.org. (Also note that the current idnits tool generates : some incorrect warnings; a rewrite is underway.) There are no nits noted in version -06. : 15. Should any informative references be normative or vice-versa? See the IESG : Statement on Normative and Informative References. No. : 16. List any normative references that are not freely available to anyone. Did : the community have sufficient access to review any such normative : references? All references, including the Informative BBF TR-146 reference, are publicly available. : 17. Are there any normative downward references (see RFC 3967 and BCP : 97) that are not already listed in the DOWNREF registry? If so, : list them. No. : 18. Are there normative references to documents that are not ready to be : submitted to the IESG for publication or are otherwise in an unclear state? : If so, what is the plan for their completion? No such references. : 19. Will publication of this document change the status of any existing RFCs? If : so, does the Datatracker metadata correctly reflect this and are those RFCs : listed on the title page, in the abstract, and discussed in the : introduction? If not, explain why and point to the part of the document : where the relationship of this document to these other RFCs is discussed. This document does not change the status of other existing RFCs. : 20. Describe the document shepherd's review of the IANA considerations section, : especially with regard to its consistency with the body of the document. : Confirm that all aspects of the document requiring IANA assignments are : associated with the appropriate reservations in IANA registries. Confirm : that any referenced IANA registries have been clearly identified. Confirm : that each newly created IANA registry specifies its initial contents, : allocations procedures, and a reasonable name (see RFC 8126). This document makes no further requests from IANA. : 21. List any new IANA registries that require Designated Expert Review for : future allocations. Are the instructions to the Designated Expert clear? : Please include suggestions of designated experts, if appropriate. N/A |
2023-04-10
|
06 | Jeffrey Haas | The document will move forward, but must address lingering issues raised during WGLC. |
2023-04-10
|
06 | Jeffrey Haas | Tags Revised I-D Needed - Issue raised by WGLC, Doc Shepherd Follow-up Underway set. |
2023-04-10
|
06 | Jeffrey Haas | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2023-04-10
|
06 | Jeffrey Haas | Notification list changed to jhaas@pfrc.org because the document shepherd was set |
2023-04-10
|
06 | Jeffrey Haas | Document shepherd changed to Jeffrey Haas |
2023-03-25
|
06 | Xiao Min | New version available: draft-ietf-bfd-unaffiliated-echo-06.txt |
2023-03-25
|
06 | Xiao Min | New version accepted (logged-in submitter: Xiao Min) |
2023-03-25
|
06 | Xiao Min | Uploaded new revision |
2023-03-21
|
05 | Jeffrey Haas | IETF WG state changed to In WG Last Call from WG Document |
2023-02-02
|
05 | (System) | Document has expired |
2022-08-01
|
05 | Xiao Min | New version available: draft-ietf-bfd-unaffiliated-echo-05.txt |
2022-08-01
|
05 | Xiao Min | New version accepted (logged-in submitter: Xiao Min) |
2022-08-01
|
05 | Xiao Min | Uploaded new revision |
2022-02-08
|
04 | Xiao Min | New version available: draft-ietf-bfd-unaffiliated-echo-04.txt |
2022-02-08
|
04 | (System) | New version accepted (logged-in submitter: Xiao Min) |
2022-02-08
|
04 | Xiao Min | Uploaded new revision |
2022-01-24
|
03 | Xiao Min | New version available: draft-ietf-bfd-unaffiliated-echo-03.txt |
2022-01-24
|
03 | (System) | New version accepted (logged-in submitter: Xiao Min) |
2022-01-24
|
03 | Xiao Min | Uploaded new revision |
2021-12-24
|
02 | (System) | Document has expired |
2021-06-22
|
02 | Xiao Min | New version available: draft-ietf-bfd-unaffiliated-echo-02.txt |
2021-06-22
|
02 | (System) | New version approved |
2021-06-22
|
02 | (System) | Request for posting confirmation emailed to previous authors: Raj Boddireddy , Reshad Rahman , Ruixue Wang , Weiqiang Cheng , Xiao Min , bfd-chairs@ietf.org |
2021-06-22
|
02 | Xiao Min | Uploaded new revision |
2021-05-06
|
01 | (System) | Document has expired |
2020-11-02
|
01 | Weiqiang Cheng | New version available: draft-ietf-bfd-unaffiliated-echo-01.txt |
2020-11-02
|
01 | (System) | New version accepted (logged-in submitter: Weiqiang Cheng) |
2020-11-02
|
01 | Weiqiang Cheng | Uploaded new revision |
2020-09-10
|
00 | Reshad Rahman | This document now replaces draft-cw-bfd-unaffiliated-echo instead of None |
2020-09-10
|
00 | Weiqiang Cheng | New version available: draft-ietf-bfd-unaffiliated-echo-00.txt |
2020-09-10
|
00 | (System) | WG -00 approved |
2020-09-09
|
00 | Weiqiang Cheng | Set submitter to "Weiqiang Cheng ", replaces to (none) and sent approval email to group chairs: bfd-chairs@ietf.org |
2020-09-09
|
00 | Weiqiang Cheng | Uploaded new revision |