Hi Tim, Thank you for your comments and I would like to make some clarifications. > 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. As analyzed in Section 3 and 4, uRPF can generate SAV rules in an automatic way, but it will have improper block problems in the scenario of asymmetric route or hidden prefix. Network operators can manually configure and update accurate SAV rules, but this requires high operational overhead. In conclusion, none of the existing intra-domain SAV mechanisms can achieve both accurate validation and automatic updating due to their technical limitations. > 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. In Section 5, this document briefly introduces the exploration of the new solutions and presents five requirements that should be considered when designing the new ones. As many members in the WG agree that this document should not restrict how to design or implement the new solutions, we do not describe details about solutions in this document. > 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” Thank you for your helpful editorial comments. Best, Lancheng > -----Original Messages----- > From: "Tim Evens via Datatracker" <noreply@xxxxxxxx> > Send time:Wednesday, 01/22/2025 01:49:07 > To: gen-art@xxxxxxxx > Cc: draft-ietf-savnet-intra-domain-problem-statement.all@xxxxxxxx, last-call@xxxxxxxx, savnet@xxxxxxxx > Subject: [Last-Call] Genart last call review of draft-ietf-savnet-intra-domain-problem-statement-10 > > 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 -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
