Hi Linda, Thank you for your thoughtful comments. > The document could benefit from more concise wording. Some sections are overly > verbose and could be streamlined without losing critical information. Thanks. We will revise this document and make it more concise. > The document would benefit from an exploration of why these challenges remain > unresolved and how new methods could overcome them. Agreed. Actually, more details about these have been discussed and introduced in another WG document, i.e., draft-ietf-savnet-intra-domain-architecture. We agree that introducing insights into overcoming the limitations in this document would not only benefit this document but also help connect the two documents better. We would like to add the following into Section 4 and Section 5, respectively. Section 4: In summary, uRPF-related solutions cannot guarantee the accuracy of SAV because it solely uses the router’s local FIB or RIB information to determine SAV rules. A router cannot see the asymmetric route between itself and another router/network from its own perspective. As a result, strict uRPF has improper block problems in the scenario of asymmetric route. The network operator has a comprehensive perspective so he/she can configure the correct SAV rules. However, manual configuration has limitations on automatic update. Section 5: The key to overcoming the limitations is to automatically combine perspectives of multiple routers, allowing each router to form a more comprehensive perspective. To this end, new SAV solutions can allow routers to exchange and update the asymmetric information that affects the accuracy of SAV (i.e., SAV-specific information) in an automatic way. Then, routers can use SAV-specific information and local routing information to determine accurate SAV rules. It is also important to reduce the complexity and overhead of SAV implementation. To this end, routers MUST NOT signal too much information. Only information that cannot be learned from local routing information and is necessary for SAV should be signaled. In addition, in order to better compatibility with the current intra-domain network, it is recommended that existing routing protocols can be used to implement the SAV function. Looking forward to your comments. Best, Lancheng > -----Original Messages----- > From: "Linda Dunbar via Datatracker" <noreply@xxxxxxxx> > Send time:Thursday, 01/16/2025 10:35:26 > To: rtg-dir@xxxxxxxx > Cc: draft-ietf-savnet-intra-domain-problem-statement.all@xxxxxxxx, last-call@xxxxxxxx, savnet@xxxxxxxx > Subject: [savnet] Rtgdir last call review of draft-ietf-savnet-intra-domain-problem-statement-09 > > Reviewer: Linda Dunbar > Review result: Has Issues > > General Comments: > The document could benefit from more concise wording. Some sections are overly > verbose and could be streamlined without losing critical information. > > The document effectively describes two existing methods for Source Address > Validation (SAV): Access Control Lists (ACLs) and Unicast Reverse Path > Forwarding (uRPF). It highlights that ACLs have a high operational cost due to > the need for manual updates and maintenance in dynamic networks. uRPF, while > automated, struggles with asymmetric routing scenarios, leading to improper > blocking of legitimate traffic. These limitations are well known, and the > document does not provide sufficient new insights into overcoming them. > > Section 5 (Requirements for New SAV Mechanisms): > > The requirements listed in this section reflect desirable outcomes for any SAV > mechanism, such as automatic updates, accurate validation, and support for > incremental deployment. The previous efforts likely shared similar goals but > may have been deemed too complex or expensive to implement at scale. A more > valuable approach would be to discuss the technical challenges or trade-offs > involved in meeting these requirements and propose specific frameworks to > address them. > > The document would benefit from an exploration of why these challenges remain > unresolved and how new methods could overcome them. > > Best Regards, > Linda Dunbar > > > -- > savnet mailing list -- savnet@xxxxxxxx > To unsubscribe send an email to savnet-leave@xxxxxxxx -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
