Reviewer: Tim Evens Review result: On the Right Track I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-savnet-intra-domain-problem-statement-?? Reviewer: Tim Evens Review Date: 2025-01-21 IETF LC End Date: 2025-01-17 IESG Telechat date: Not scheduled for a telechat Summary: Needs more work. Major issues: uRPF limitations are well known, including in the Linux community considering `rp_filter` causes a lot of pain for folks. In section 3 and 4, none of the provided scenarios are new. They are described more as lessons learned from trying to implement uRPF incorrectly. The statement in section 3.2, "the operational overhead of maintaining updated ACL rules will be extremely high when there are multiple AS border routers adopting SAV” does not apply to everyone, especially when routers and linux/platforms are configured/provisioned by automation. It appears that this draft is more of a requirements document to create or extend existing protocols to support SAV without the limitations of uRPF and overhead of ACLs. It suggests dynamic messaging between devices by reusing existing routing protocols, but fails to provide any solutions. This draft by itself doesn’t appear to describe all the requirements that would be needed for drafting alternative conveyance and enforcement mechanisms for SAV. Rather than describe the existing known limitations of uRPF and how manual ACL updates are problematic, it might be better for the requirements document to describe the scenarios of where SAV is to be applied and what needs to be performed at each of those points of enforcement. IPv6 IOAM (RFC9486) or similar could be considered to help in identifying the ASes a packet traversed and if the source is legitimate or not based on where it originates and the hops it went through to reach a given point. Nits/editorial comments: In abstract, change “the gap analysis” to “a gap analysis” In introduction: * suggest changing “which is coarser than the granularity of access network SAV” to “which is less granular than the access network SAV” * “Consider an AS X …” is a bit out of place and would be okay to drop the sentence. * Suggest rewording to remove AS X and Y in favor of “an AS” Section 5, change “in order to better compatibility” to “to improve compatibility” Section 5.2, change “intra-domain SAV mechanism need to improve” to “intra-domain SAV mechanism needs to improve” -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
