Re: [savnet] Request WG adoption of draft-wu-savnet-inter-domain-architecture-07

Hi Olaf.S,

Thank you for sharing your thoughts. Please see my reply below.

> The SAV architecture in the draft seems to employ the same or similar automatic mechanism in style as the route selection for FIB, but there are fundamental differences between the two, which will lead to different executing effects on the device.

[Libin:] The inter-domain SAVNET architecture draft proposes a fundamentally different mechanism for generating accurate SAV rules with the route selection for FIB. The route selection for FIB selects the “best” route to a destination prefix/address from all “accurate” candidates. Instead, inter-domain SAV rule generation relies on obtaining the real incoming direction of a source prefix/address to enter an AS. The draft obtains the accurate SAV rules (i.e., source prefix and their legitimate incoming direction) from SAV-specific information to perform SAV and recommends utilizing the general information for generating SAV rules when the SAV-specific information of ASes cannot be obtained. Different from SAV-specific information, the general information, e.g., local routing information, may be not accurate in many scenarios and has other problems in timeliness and trustworthiness as analyzed in Sections 5 and 8 of the draft. Also, this is why the SAV-specific information is recommended the highest priority.

> Route (FIB) selection is a process for selecting the optimal routes among all those feasible routes. As we known, it was created for this purpose from the first beginning. The key premise of this general functionality is that all alternative routes from different protocols always provide exactly accurate packets forwarding in any case. It is not a workable mechanism to seek out relatively more accurate entries, especially when it may tolerate potentially inaccurate SAV entries on a network equipment.

[Libin:] The draft utilizes SAV-specific information to generate SAV rules, as long as it is available. However, in the partial or incremental deployment of SAV-specific information, operators can utilize the general information to generate SAV rules according to the recommended priorities, which at least provides protect for the prefixes in the scenarios where existing SAV mechanisms work.

> Forwarding and processing packets correctly is the basic task of a device. If the mechanism is just copied from there to here, then perhaps it doesn’t need to state more about the consequence that the mechanism will cause on the network. The new architecture introduced in this draft also cloud not meet the requirements ultimately concluded in draft “draft-ietf-savnet-inter-domain-problem-statement-04”.

[Libin:] Agree that forwarding and processing packets correctly is the basic task of a device. Therefore, the inter-domain SAVNET architecture draft proposes SAV-specific information to solve the problems of existing SAV mechanisms as analyzed in the draft draft-ietf-savnet-inter-domain-problem-statement-04 and satisfy the requirements for new inter-domain SAV mechanisms in Section 6 of the problem statement (PS) draft. Also, in Section 6.1.1 of the PS draft, we have illustrated the accurate validation in all directions of an AS. The mechanism for generating SAV rules is fundamentally different with route selection as illustrated above.

> It might be valuable as a research effort, especially as it proposed the concept of specific rules table for accurately performing source address validation. But if we treat the main mechanism of this architecture as a potential standard that will emerge into the industry recently, it’s obvious that it cannot stand to the most basic verification of network practices, and I don’t think any vendor will develop and implement complying with it on devices in the foreseeable future.

[Libin:] I do not agree with this. Existing SAV mechanisms which had been implemented by vendors on their devices lead to improper blocks or improper admits in many practical scenarios. Operators complain a lot and they usually disable them on the devices. The inter-domain SAVNET architecture proposes SAV-specific information and solves the practical problems in industry and gives the guideline for designing and implementing new SAV mechanisms. Therefore, we discussed it in the IETF meetings and requested SAVNET WG adoption of the draft to promote new inter-domain SAV solutions.

> In addition, the above is not a negation to any new feature for generating accurate source address validating entries(even if it will take effect in patial and explicit scope at first), whether they are derived from the SAV-Specific information or other information available.

[Libin:] Yes, SAV is important and generating accurate SAV rules makes it work in practical scenarios.

Best,

Libin

________________________________
From: savnet <savnet-bounces@ietf.org> on behalf of Olaf Struck <olafstruck@hotmail.com>
Sent: Friday, March 29, 2024 9:02 PM
To: Lancheng Qin <qlc19@mails.tsinghua.edu.cn>
Cc: savnet@ietf.org <savnet@ietf.org>; liulb@zgclab.edu.cn <liulb@zgclab.edu.cn>
Subject: Re: [savnet] Request WG adoption of draft-wu-savnet-inter-domain-architecture-07

Hi，

Thank you for the reply, it becomes clear to me.

The SAV architecture in the draft seems to employ the same or similar automatic mechanism in style as the route selection for FIB, but there are fundamental differences between the two, which will lead to different executing effects on the device.

Route (FIB) selection is a process for selecting the optimal routes among all those feasible routes. As we known, it was created for this purpose from the first beginning. The key premise of this genenral functionality is that all alternative routes from different protocols always provide exactly accurate packets forwarding in any case. It is not a workable mechanism to seek out relatively more accurate entries, especially when it may tolerate potentially inaccurate SAV entries on a network equipment.

Forwarding and processing packets correctly is the basic task of a device. If the mechanism is just copied from there to here, then perhaps it doesn’t need to state more about the consequence that the mechanism will cause on the network. The new architecture introduced in this draft also cloud not meet the requirements ultimately concluded in draft “draft-ietf-savnet-inter-domain-problem-statement-04”.

It might be valuable as a research effort, especially as it proposed the concept of specific rules table for accurately performing source address validation. But if we treat the main mechanism of this architecture as a potential standard that will emerge into the industry recently, it’s obvious that it cannot stand to the most basic verification of network practices, and I don’t think any vendor will develop and implement complying with it on devices in the foreseeable future.

In addition, the above is not a negation to any new feature for generating accurate source address validating entries(even if it will take effect in patial and explicit scope at first), whether they are derived from the SAV-Specific information or other information available.

Best,

Olaf.S

________________________________
From: Lancheng Qin <qlc19@mails.tsinghua.edu.cn>
Sent: Friday, 29 March 2024 3:49
To: Struck Olaf <olafstruck@hotmail.com>
Cc: savnet@ietf.org <savnet@ietf.org>
Subject: Re: Re: [savnet] Request WG adoption of draft-wu-savnet-inter-domain-architecture-07

Hi Olaf.s,

Correct.

To achieve accurate validation (especially in the incremental deployment scenario), the new SAV solution is suggested to preferentially use higher-priority SAV-related information to generate SAV rules. You can refer to Section 9 for more details.

Best,
Lancheng

-----原始邮件-----
发件人: "Struck Olaf" <olafstruck@hotmail.com>
发送时间: 2024-03-28 19:13:43 (星期四)
收件人:
抄送: "savnet@ietf.org" <savnet@ietf.org>
主题: Re: [savnet] Request WG adoption of draft-wu-savnet-inter-domain-architecture-07

Hi Libin,

Referring to the introduction in section 6, does it mean that if the high-priority entry existed in SIB, then the SIB Manager will select it (e.g., SAV-specific Information, RPIK information) as the SAV Rule that will be executed on forwarding plane, otherwise the relatively low-priority entries (e.g., information from RIB, FIB, etc.) are preferred.

Just to be clear, according to the design concept of the mechanism in this draft, is that a right understanding of how it roughly works?

Best,

Olaf.s

From: Libin Liu<liulb@zgclab.edu.cn>
Sent: 2024-03-23 10:51:57
To: savnet@ietf.org
Subject: [savnet] Request WG adoption of draft-wu-savnet-inter-domain-architecture-07

Dear WG and Chairs,
Following the presentation in the WG meeting on this draft, we would like to request the SAVNET WG adoption for it.
As we presented in the WG meeting, this draft addresses all the comments from our community and all its updates have been discussed during the meetings from IETF 115 to IETF 119, as well as in the mailing list.
Thank you.
Best,
Libin
--
savnet mailing list
savnet@ietf.org
https://www.ietf.org/mailman/listinfo/savnet