Appeal to the forwarding of draft-ietf-lsr-igp-ureach-prefix-announce (Aijun Wang) - 2025-06-17
Response - 2025-09-08

Summary

On June 17, 2025, Aijun Wang appealed the Link State Routing (LSR) working group’s request to the IESG for publication of draft-ietf-lsr-igp-ureach-prefix-announce following conclusion of the Working Group Last Call (WGLC) due to three technical issues identified as “unsolved deficiency designs” by the appellant and claimed by the appellant as not addressed when raised. See the full appeal text.

The responsible Area Director (AD) for the LSR working group is Gunter van de Velde. He did not take part in the processing of this appeal as he is a contributor to the document under appeal. James Guichard who is the responsible AD for this document also did not take part in the processing of this appeal.

The IESG has reviewed the working group’s processing of the document and its mailing list archive, and finds that the record does not support the claimed defects in process or technical content. The appeal is thus denied.

Procedural History

According to the IETF datatracker and the LSR mailing list archive:

2022-03-25: -00 version of individual draft draft-ppsenak-lsr-igp-ureach-prefix-announce published
2023-08-23: WG adoption poll started for draft-ppsenak-lsr-igp-ureach-prefix-annouce
2023-08-13: WG adoption poll concluded with rough consensus called by the WG chairs
2023-09-11: -00 first version of adopted working group draft published
2023-09-14: Complaint to AD (John Scudder) by appellant on the document adoption
2023-10-17: Reminder about complaint by appellant
2023-10-31: Response from AD (John Scudder) to the appellant upholding the document adoption
2025-04-17: -04 version placed in WGLC state
2025-05-14: Chairs declare WGLC complete with rough consensus to proceed
2025-05-16: “Appeal for the WGLC of UPA draft” to the AD (James Guichard) posted
2025-05-23: Reply from the responsible AD (James Guichard) posted
2025-06-10: IETF LC Initiated
2025-06-17: appeal received by IESG
2025-06-24: IETF LC Expired

IETF process and other documents relevant to this appeal are:

  • BCP 9 (RFC 2026): “The Internet Standards Process -- Revision 3”
  • BCP 25 (RFC 2418): “IETF Working Group Guidelines and Procedures”
  • RFC 7282: “On Consensus and Humming in the IETF”

Discussion of Technical Issues

This appeal comes under Section 3.4 of RFC 2418, which for working-group-specific appeals refers to the process of Section 6.5.1 of RFC 2026. The appeal appears to be invoking both the (a) and (b) clauses of this section, i.e., respectively, that the appellant’s “concerns have not been adequately addressed by the working group”, and the ”working group has made a … technical choice which places the quality of the WG’s products in significant jeopardy.”

The record confirms that the appellant has first appealed to the working group as a whole over the general course of the document’s life cycle, then to the Chairs during WGLC, and then to the responsible AD. Dissatisfied with the outcome at each phase, the appellant now accordingly seeks resolution from the IESG. The appeal also meets the time constraint and criteria in Section 6.5.4 of RFC 2026.

While not a BCP, RFC 7282 is a consensus document of the IETF, capturing the essence of the IETF’s operating philosophy with respect to how community decisions are made. Importantly, it points out, as a section heading, that “rough consensus is achieved when all issues are addressed, but not necessarily accommodated.”

The appellant has raised three technical issues on the document.

Technical Issue (a)

Description

“(a) The proposal doesn’t work even in simple scenario” per Section 2 of draft-wang-lsr-reasons-of-abandon-upa-proposal”

Response

draft-ietf-lsr-igp-ureach-prefix-announce specifies how the propagation of the unreachable prefix announcement is to happen for OSPF in Section 4.2 as follows:

4.2. Propagation of UPA in OSPF
OSPF ABRs or ASBRs, which would be responsible for propagating UPA advertisements into other areas MUST recognize such advertisements.

Advertising prefix reachability between OSPF areas assumes prefix reachability in a source area. Such requirement of reachability MUST NOT be applied for UPAs, as they are propagating unreachability.

OSPF ABRs or ASBRs MAY advertise received UPAs between connected areas or domains. When doing so, the original LSInfinity metric value in UPA MUST be preserved. The cost to reach the originator of the received UPA MUST NOT be considered when readvertising the UPA to connected areas.




This issue was not raised by the appellant in the WG during its processing of the UPA document until after the conclusion of the WGLC. When this question was raised on the LSR mailing list by the appellant on 10-June-2025 coinciding with the IETF LC, the response from one of the document authors also provided a pointer to the same section of the document referenced above.

Technical Issue (b)

Description

“(b) The proposal is based on one flawed feature” per Section 3 of draft-wang-lsr-reasons-of-abandon-upa-proposal

Response

This claim characterizes one of the architectural constants of the OSPFv2 protocol specification RFC 2328 ‘LSInfinity’ as a “flawed feature”. The OSPF protocol (which applies to both OSPFv2 and OSPFv3) is an Internet Standard that has multiple implementations and deployments. There is no technical issue with the use of the LSInfinity mechanism. The appellant’s argument ignores that network operators are aware of this protocol constant and choose metric values for links and prefixes considering this constant.

This topic was discussed and clarified by working group members (including one of the co-authors) providing explanations and pointers to existing RFCs. See these select responses to discussion during the WGLC of the document:

Repeated restatement of the same questions by the appellant led to the WG chairs directing the appellant on 15-May-2025 to cease further repeating the same arguments.

Technical Issue (c)

Description

“(c) No explicit UPA withdrawn signal” per Section 4 of draft-wang-lsr-reasons-of-abandon-upa-proposal

Response

This claim assumes a requirement, presented after WGLC, for the distinction between the two reasons (Case A & B) without stating the rationale for this requirement. Section 2 of draft-ietf-lsr-igp-ureach-prefix-announce that specifies the generation of the UPA also describes the intent of the same. More specifically, since UPA is advertised as a “state” that is meant to “signal the transition of a destination from reachable to unreachable” and not intended to be a persistent state, it needs to be withdrawn as per IS-IS and OSPF protocol procedures. The document does not say that withdrawal of an UPA announcement indicates reachability. Further, section 7 of the document [https://www.ietf.org/archive/id/draft-ietf-lsr-igp-ureach-prefix-announce-09.html#section-7] makes it clear that the mechanism for using the UPA is outside the scope of the document (BGP-PIC [https://datatracker.ietf.org/doc/draft-ietf-rtgwg-bgp-pic] being an example) and therefore does not require the distinction between the Cases A & B.

This issue was raised on the LSR mailing list after the WGLC, but before the IETF LC. The topic was then discussed in the WG with members (including co-authors) having responded and clarified the scenarios in detail. Some of those explanations have also gone beyond the scope of this document to describe the interplay of this mechanism with BGP convergence in the context of BGP-PIC.

Conclusion

The appellant has requested three actions of the IESG: to provide the requested technical answers, alternatively to abandon the document, and to modify the leadership of the LSR working group.

Regarding the first two actions, the IESG finds that the technical issues raised above have been answered in the document, by the authors, and by others in the WG. The IESG finds that ample grounds exist to support the assertion that working group consensus was properly reached. Therefore, there are no further actions required from the WG in the matter of this appeal. Furthermore, the IESG concurs with the decision of the AD responsible for this document on the complaint made by the appellant. Should the responsible AD be satisfied with this document, he may request a ballot for its evaluation.

However, the IESG notes that the path to publication is not complete yet and the gate of IESG Evaluation remains where ADs perform their individual review of the document and balloting for approval of the document for publication.

With regards to the third action, the IESG confirms that the WG chairs have followed the IETF standards process as outlined in RFC 2418. The IESG recommends that the appellant approach the responsible AD of the LSR WG with their suggestions and feedback on LSR WG leadership.

The appeal is denied.