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

[Olaf Struck <[e-mail]>]

Hi,



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


If you are familiar with the term “feature”, you might not have missed an opinion of those solutions expressed in the last sentence of the email on March,29. It’s my view after reading their documents, as copied below.



- March.29

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 partial and explicit scope at first), whether they are derived from the SAV-Specific information or other information available.



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



Based on your reading and discussion of the solutions:

Is there any new feature that selects the candidate RIB/FIB entries for SAV simply by a “Priority” of source information type level and the absence of high-priority entries sources? And can it also guarantee the accuracy?



Alternatively, is there any new SAV feature that alter the inaccurate entries in the RIB/FIB table, which is originally used for guiding the routing.



Can a feature designed to better SAV entries change the state of the worse and inaccurate candidate information included in the candidate list of your selecting mechanism?



Based on the logic described in your reply:

Conversely, if the RIB/FIB entries effective for accurate SAV can be automatically chosen by a factor of ‘priority’ of source type level, as described in the section 6, what are the significant gaps the existing SAV mechanism?

Alternatively, if the candidate source ‘FIB/RIB’ entries have already been alerted or must ensure to be accurate for SAV by some function, what utility and value would an "extra selecting mechanism" and the "new SAV-specific information" provide?



What is the significance of an architecture or mechanism that still matches the gaps analyzed in its corresponding ‘problem Statement’ draft?
And what is the meaning of a new mechanism that is claimed to be merely workable under the precondition that someone (or some function) has already recognized the issue in the previous gap analysis and has ensure it doesn’t happen? Especially, it may point to the FIB/RIB, which are naturally already there. You successfully raised a chicken and egg problem in a proposing WG draft of IETF.





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



You have once again overstepped in responding directly to the question, which was obviously raised in the first part of my last email with details. It is interesting that how do you think it can cover and be correct? Is this new reply consistent with your reply in your first email on March.29?



In your reply, you treat the proposed solutions as applications which are designed based on the architecture and mechanism in this draft. Obviously, as it introduces,  the new feature could utilize some fields from RIB/FIB information, as well as any other available information and information generated by its own design. These factors would be used to calculate accurate SAV rules, in general or in specific scenarios. After the collection and calculation, some new features could also possibly reuse certain FIB/RIB entries if they are identical with the calculated SAV rules. However, that acts as the role of final calculated result then, definitely NOT the role of candidate source information. And the calculating processes for accurate SAV would not obey to a simply selecting from the FIB/RIB (as a candidate) direclty based on a source type level "priority" , as in the description and example in this draft.



That is a thing completely different from the automatic selecting mechanism in the way described in your draft, and they are even contradictory approaches. The mechanism and 'high-level' design in section 6 of your draft, which directly and automatically selects RIB/FIB entries based on the 'Priority' of the RIB/FIB type and the absence of high-priority entries, will not will not benefit them on accuracy. Instead, it inevitably leads to the same worst-case scenario as current mechanisms. Attempting to answer the question by confusing these two things causes misleading and muddling.


I think the issue I mentioned previously, unrelated to any feature or solution, is confined to the mechanism in the section 6.


From the technical perspective, I am always supportive of "high-level" designs. Nerveless, I’m afraid it should not be a guise for an illogical, self-contradictory and infeasible design or a veil to muddle through.



Best,

Olaf.S

________________________________
From: Lancheng Qin <[e-mail]>
Sent: Wednesday, 3 April 2024 4:08
To: Olaf Struck <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: Re: Re: [savnet] Request WG adoption of draft-wu-savnet-inter-domain-architecture-07


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