Dear Acee, Thank you for taking the time to review the draft and for your comments. Please find my responses and clarifications to your points below.
> 1. The concept of "sub network" is confusing. Why don't you just use "IGP >routing domain"? Also, why do you say that a "sub network" cannot carry >transit traffic? I know transit traffic (not tunneled) is uncommon but isn't >prohibited - is this just not a use case that isn't addressed since it isn't >that common? We define a “sub network” as an IGP routing domain that only originates traffic. We believe this could help understand the capability of intra-domain SAV. That is, intra-domain SAV can perform stricter validation for traffic coming from entities that only originates traffic (e.g., sub networks or hosts), while it can only provide looser validation for traffic coming from external transit networks — inter-domain SAV would be needed to fill this gap. Do you have any suggestions for a clearer or more appropriate name? > 2. I think the problem statement should indicate that any solution >including IGP extensions should make them optional and allow for incremental >deployment. These aspects are currently captured as requirements in Sections 5.3 and 5.4. > 3. I didn't fully understand the "hidden prefix" use case - I reviewed >the document on a plane w/o Internet access so I didn't try too hard. The “hidden prefix scenario” refers to cases where a host is only reachable via one address, but may use a different source address when sending traffic for legitimate reasons. We've recently discussed examples of this scenario on the mailing list — please see [1, 2] for reference. [1] https://mailarchive.ietf.org/arch/msg/savnet/8ywh8naVitPkiLR-e-Cc1T5E4Gw/ [2] https://mailarchive.ietf.org/arch/msg/savnet/pbc3jtv51-Y30M6dZrYYxnzm3pk/ > With the respect to solutions, the draft only talks about the existing > "strict RPF" and "loose RPF". I think there could also be a combination of > solutions to address various use cases. The document focuses on analyzing currently operational intra-domain SAV mechanisms (including ACL and uRPF). If we’ve missed any solutions, we’d greatly appreciate your input. Thanks, Lancheng > -----Original Messages----- > From: "Acee Lindem" <[email protected]> > Send time:Monday, 21/07/2025 21:35:19 > To: Lancheng <[email protected]> > Cc: [email protected], lsr <[email protected]> > Subject: [savnet] Re: I-D Action: > draft-ietf-savnet-intra-domain-problem-statement-17.txt > > Hi Lancheng, > > I know you are presenting this tomorrow in LSR. I finally reviewed this draft > and have the following comments. > > 1. The concept of "sub network" is confusing. Why don't you just use "IGP > routing domain"? Also, why do you say that a "sub network" cannot carry > transit traffic? I know transit traffic (not tunneled) is uncommon but isn't > prohibited - is this just not a use case that isn't addressed since it isn't > that common? > 2. I think the problem statement should indicate that any solution > including IGP extensions should make them optional and allow for incremental > deployment. > 3. I didn't fully understand the "hidden prefix" use case - I reviewed > the document on a plane w/o Internet access so I didn't try too hard. > > With the respect to solutions, the draft only talks about the existing > "strict RPF" and "loose RPF". I think there could also be a combination of > solutions to address various use cases. > > Thanks, > Acee > > > > > On Jul 7, 2025, at 10:27 AM, Lancheng > > <[email protected]> wrote: > > > > Dear all, > > > > Jim wrote in [1]: > >> Additionally, we might want to consider splitting the document into two > >> parts: > >> 1. An informational document that outlines the use cases and identifies > >> technology gaps. > >> 2. A standards-track document that clearly defines the normative > >> requirements for solutions. > >> This separation could help clarify the document’s intent and ensure that > >> any future protocol work based on it has a solid and well-understood > >> foundation, without running into issues like downrefs or misinterpretation. > > > > To address this concern raised by Jim, we have added a clarification in > > Section 5 of this document to make it explicit that “These informational > > requirements can not be used to initiate standards-track protocol changes. > > Any protocol changes would require a standards-track requirements document, > > not a non-normative reference to this informational document.”. > > > > We believe this clarification resolves the concern raised, and we > > appreciate further review from the working group. > > > > Thanks, > > Lancheng > > (on behalf of the authors) > > > > [1] > > https://mailarchive.ietf.org/arch/msg/savnet/FppvNBPuodY84SFD5b6S-rGixKk/ > > > > > > > > > >> -----Original Messages----- > >> From: [email protected] > >> Send time:Monday, 07/07/2025 22:05:50 > >> To: [email protected] > >> Cc: [email protected] > >> Subject: [savnet] I-D Action: > >> draft-ietf-savnet-intra-domain-problem-statement-17.txt > >> > >> Internet-Draft draft-ietf-savnet-intra-domain-problem-statement-17.txt is > >> now > >> available. It is a work item of the Source Address Validation in > >> Intra-domain > >> and Inter-domain Networks (SAVNET) WG of the IETF. > >> > >> Title: Source Address Validation in Intra-domain Networks Gap > >> Analysis, Problem Statement, and Requirements > >> Authors: Dan Li > >> Jianping Wu > >> Lancheng Qin > >> Mingqing Huang > >> Nan Geng > >> Name: draft-ietf-savnet-intra-domain-problem-statement-17.txt > >> Pages: 16 > >> Dates: 2025-07-07 > >> > >> Abstract: > >> > >> This document provides a gap analysis of existing intra-domain source > >> address validation mechanisms, describes the fundamental problems, > >> and defines the basic requirements for technical improvements. > >> > >> The IETF datatracker status page for this Internet-Draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-savnet-intra-domain-problem-statement/ > >> > >> There is also an HTML version available at: > >> https://www.ietf.org/archive/id/draft-ietf-savnet-intra-domain-problem-statement-17.html > >> > >> A diff from the previous version is available at: > >> https://author-tools.ietf.org/iddiff?url2=draft-ietf-savnet-intra-domain-problem-statement-17 > >> > >> Internet-Drafts are also available by rsync at: > >> rsync.ietf.org::internet-drafts > >> > >> > >> -- > >> savnet mailing list -- [email protected] > >> To unsubscribe send an email to [email protected] > > -- > > savnet mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > -- > savnet mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
