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

[Lancheng Qin <[e-mail]>]

Hi,




I agree that the architecture should be general, but I need to confirm whether we are talking about architecture or mechanism. It seems that the current discussion has gone beyond the scope of architecture. 


Here are some of my thoughs on the architecture document:
(1) This document proposes a high-level architecture which provides a conceptual framework and guidance for designing new SAV mechanisms/solutions. The specific design of new SAV mechanisms/solutions is outside the scope. If we are going to talk about the design of a new SAV mechanism/solution, I’d suggest starting a new thread.


(2) Similarly, Section 6 is not a mechanism/solution but a guidance. By following the guidance proposed in Section 6, the new SAV mechanism/solution is suggested to preferentially use SAV-specific information to generate accurate SAV rules. If it also uses general information, it must ensure that it does not affect the SAV rules generated by SAV-specific information and does not cause improper block.

(3) If I understand correctly, the thought (2)  is consistent with the three types of cases and your following questions are more about the mechanism/solution. In IETF 118 and IETF 119, several SAV mechanisms/solutions designed under SAVNET architecture were presented in SAVNET WG meeting. I hope we can find the answer in those documents.

Thanks.




Lancheng






-----原始邮件-----
发件人:"Olaf Struck" <[e-mail]>
发送时间:2024-04-02 15:41:36 (星期二)
收件人: "Libin Liu" <[e-mail]>
抄送: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "Lancheng Qin" <[e-mail]>
主题: Re: Re: [savnet] Request WG adoption of draft-wu-savnet-inter-domain-architecture-07



Hi,




 

[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. 

 

First, here you come to the issue. To recap, the selecting mechanism described in Section 6 of this draft could not meet the requirements summarized in section 6 of that previous draft, ‘6.1 Accurate Validation’ and ‘6.2 Automatic Update’. Then, you also mention a scenario here, which is great, but a architecture thing in networks is not a thing like that: Hey, you see, I find a scenario where it works or works better, let’s propose with a WG draft/RFC of architecture for it.

If we really go to a comprehensive view of actual scenarios over the network, generally speaking, they will fall into the following three types of cases. for a source prefix (or an AS):

Case 1: When correct SAV rules with high-priority exist, its corresponding FIB/RIB information is accurate (or inaccurate) on executing SAV for it.

----Is it absolutely necessary here?

Case 2: When its accurate SAV rules with high-priority are lacking, its corresponding FIB/RIB information can be used for accurate SAV.

----How to distinguish this situation on every interface and for each prefix? Shall we leave it to operator guys?

Case3: When its accurate SAV rules with high-priority are lacking, its corresponding FIB/RIB information is inaccurate for executing SAV?

----If the FIB/RIB information preferred here as both the previous reply in mail and the draft. Is that accurate in this case? Do we need to rely on some manual-acting to ensure the correctness? If we have to and already done something manually, so what is the point on the necessity and effectiveness of developing and deploying such a heavy mechanism?

Please consider it in conjunction with the mechanisms in this draft and the mail relay. So, in terms of your original design, for the architecture and mechanisms in Section 6, which of the aforementioned scenarios did you intend to cover?

Indeed, all three scenarios exist in networks, both in intra-domain and inter-domain scenarios, and none of them could be considered a case of absolute rarity. Generally speaking, for an architecture, no matter how abstract it is, it should have the correct and executable approaches to cover all three scenarios, which serves as a basic requirement, it also needs to be necessary and effective for a migration of legacy networks. Apart from these considerations of carrier and network service aspects, it hasn’t even touched on any deeper discussion about how vendors can refer to the architecture to determine and develop correctly on the device in respective scenarios.

To the point, it’s quite astonishing how you manage to completely sidestep such a clear and basic issue in all of your pretty extensive feedback. If you're still unclear about what the problem is, I suggest having some discussions with someone who is familiar with network equipment, and anyone who has ever touched a network knows such an issue and its implications for the network. However, if you understood the issue but were just not concerned about its subsequent impact, we could simply discontinue the talk now and ignore this mail.

Additionally, it also briefly mentions similar designs and mechanisms in section 3.3.2 of draft-li-savnet-intra-domain-architecture-07.

 

[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.

 

Partial or incremental deployment is never a temporary phase of any network that allows for a decrease in network service quality or tolerance for incorrect packet forwarding. Even within the network of a single carrier, the migration procedure usually lasts from 4 months to 3 years. Regardless of whether it is a full deployment or a partial deployment scenario, if the operator has not enabled the existing functions (or even if no corresponding function is supported on devices) before on the device due to the reasons you mentioned, they also will not enable the new architecture now based on the same reasons as before. This is because, for this architecture -Section 6, the fundamental issue is that if a network cannot withstand the unavoidable and uncontrollable worst results (incorrect forwarding or complete ineffectiveness) of a function in certain scenarios, it does not mean that they will deploy that functionality now just because it performs better in some scenarios while the uncontrollable worst case is still existed. More, it has not been considered how many windows will be spent in upgrade and enabling this new architecture on devices.

 

I will skip over other replies in your email, as they seem to be neither wrong nor right and make no sense, just as some of your replies in those previous emails, which is not get to the point and not address any issue; some content may be contradictory between different paragraphs of the reply, or not consistent with the description in the draft; or it is may state something strongly without any following supporting reasons, or reply to practical matters solely with documents. Beyond being difficult to reply to and a waste of time, the worrying thing is whether you have the remotest idea about what’s the network really carries? Whether you care about how your architecture actually works on the networks.

 

Furthermore, based on the replies and previous emails, I wonder if you understand the application and effects of a draft after it becomes to be the RFC or WG draft? For example, in the PoC of a project, if it cannot inform a vender that, since their equipment does not implement comply with the definition in this RFC/WG Draft (e.g., Section 6), it fails to pass the item of in verification, NOR can tell the Operator's network design team that the device that has passed the test and implement an automatic function according to this RFC-xx may lead to some traffic forwarding issues or have no effect in some worse situation while the function been enabled. That kind of things will cause the confusion and trouble for all members. This is the point I care about the most and why do I write a lot here. It leaves behind an open-ended question on paper, but it is difficult for everyone to handle in the network reality.













Best,




Olsf.S

From: Libin Liu <[e-mail]>
Sent: Saturday, 30 March 2024 15:01
To: Olaf Struck <[e-mail]>; Lancheng Qin <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: 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 <[e-mail]> on behalf of Olaf Struck <[e-mail]>
Sent: Friday, March 29, 2024 9:02 PM
To: Lancheng Qin <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
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 <[e-mail]>
Sent: Friday, 29 March 2024 3:49
To: Struck Olaf <[e-mail]>
Cc: [e-mail] <[e-mail]>
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" <[e-mail]>
发送时间:2024-03-28 19:13:43 (星期四)
收件人:
抄送: "[e-mail]" <[e-mail]>
主题: 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<[e-mail]>
Sent: 2024-03-23 10:51:57
To: [e-mail]
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
[e-mail]
https://www.ietf.org/mailman/listinfo/savnet