[Xueyan:] I have the same concern with Sriram. Actually I have discussed this question with the editor about a half month ago. About Figure 4, the comparasion results between SAV-specific message, RPKI, IRR, etc., there is no reference for the results source and no experimental data support, so it's not convincing for me. And about Figure 5, the priority-set for the related SAV information source (RPKI, SAV, IRR, etc.) which is based-on the results provided in Figure 4, is also not convincing.
To select which SAV method should be implementation or scenarios dependent, it's very hard to say which one is the best and be suitable to every scenarios. Considering there are many existing methods, I also agree that these methods should be complementary for optimization of source address validation.
[Libin:] "The analysis of existing data sources provides the evidence in Section 5: (1) For ROA and ASPA objects, a recent study [1] reported that the process of updating RPKI information is not timely, even requiring an hour. (2) For local routing information, the analysis is based on the PS draft, which analyzes existing SAV solutions using local routing information. (3) IRR data may not be always accurate, which is also stated in RFC8704."
In the offline discussion with you, I think I had addressed your concerns about Figure 5 by explaining the following paragraph in the draft:
"It is noteworthy that the priority ranking of SAV information sources in Figure 5 is recommended rather than mandated. If a new inter-domain SAV mechanism needs to generate SAV rules using low-priority SAV informaiton sources, it should ensure that the correct information is obtained from the corresponding sources and adopts appropriate SAV actions in the data plane to avoid improper block and minimize improper permit. A new inter-domain SAVNET mechanism, in line with the inter-domain SAVNET architecture, has the flexibility to determine the utilized SAV information sources and their priorities accordingly. Especially, when using RPKI ROA objects and ASPA objects as the SAV information source, the new inter-domain SAVNET mechanism should avoid jeopardizing the use of RPKI in routing security."
Joel:] With regard to the priority ranking, trying to translate the terminology into more normative language, is the ranking a SHOULD or a MAY? If it is a SHOULD, when does it not apply? If it is a MAY, why is it included?
[Libin:] This may include two aspects:
(1) is data source ranking a SHOULD or a MAY?
(2) is data source ranking recommendation a SHOULD or a MAY?
For the first question, I think it is a SHOULD. No one data source is perfect. Considering multiple data sources for SAV is natural. As a result, there MUST exist the scenarios that multiple data sources are available at the same time for a prefix, data source ranking is needed to deal with them.
I think it does not apply when only one data source can be used. For such scenarios, if operators want to enable SAV, they can only deploy a SAV solution which only leverages that source.
For the second question, I think it is a MAY. Before determining a SAV solution, the recommendation can be only based on data sources themselves in terms of accuracy, timeliness, and trustworthiness. Yet, providing the ranking recommendation is helpful for operators or the designers of new SAV solutions to guide their selections of data sources. The generated SAV rules are not only related to the data sources, but also the SAV algorithms and deployment scenarios. Therefore, in the draft, the ranking list of data sources is not mandated.
Also, I think solutions using multiple data sources equally just assign the same priority ranking to them.
[Joel:] If what you are saying is that in the architecture it can note that solutions need to include descriptions for how they weigh / rank different sources of truth, that makes good sense. I do not see why there is any need to specify a particular ranking as one that MAY be used in this document.
[Libin:] IMO, this document tries to provide the guidelines for the new SAV solutions design to solve the problems which existing solutons cannot deal with. Thus, the recommended ranking order aims to provide just a general guideline for the utilization/selection of data sources in new SAV solutions.
[KS:] The idea or purpose of ranking is still not clear. For a given customer interface, if SAV-specific data does not show a prefix but BGP data does, would the prefix not be included in the SAV table because the SAV-specific data is ranked higher? The SAV-specific data may not be showing the prefix simply because of partial deployment.
Also, the same question applies to RPKI data vs. BGP data.
So, in partial deployment, doesn't it become necessary to use multiple data sources in a complementary fashion without any ranking order?
[Libin:] No. For that prefix which is only included in the BGP data in your example, the SAV table can include it according to the BGP data, just according to the relative higher ranking data source. The draft provides an example using Figures 6 and 7 in Section 6. Hope it is more clear.
[Igor:] It makes sense to prioritize information sources, when they contradict each other. Whether any two information sources contradict each other is very specific to which information sources we are considering.
For example, if a valid ROA for a prefix exists in RPKI, then a BGP UPDATE message for this prefix with origin ASN not in ROA contradicts RPKI, and we consider RPKI to be of a higher priority, so we ignore the BGP UPDATE message. But if there is no ROA for a prefix in RKPI at all, then we consider ROA and BGP to complement each other in regard to that prefix. This rule is very specific to ROA vs BGP.
It will have to depend on the nature of whatever SAV-specific information is proposed by a SAV solution to determine what it means for it to contradict any other SAV information source.
[Libin:] Thank you, Igor. Your example is clear.
Regarding to the SAV-specific information, I think its definition is clearly provided. It includes the prefixes and their legitimate incoming directions to enter an AS for inter-domain SAV. Thus, if a prefix's SAV-specific information is obtained, it is expected to just use it to generate SAV table for that prefix. I think if a solution cannot learn the SAV-specific information, it means the solution has problem and it cannot satisfy the requirement for obtaining the real SAV-specific information. We should improve the solution.
[Xueyan:] I have the same concern with Sriram. Actually I have discussed this question with the editor about a half month ago. About Figure 4, the comparasion results between SAV-specific message, RPKI, IRR, etc., there is no reference for the results source and no experimental data support, so it's not convincing for me. And about Figure 5, the priority-set for the related SAV information source (RPKI, SAV, IRR, etc.) which is based-on the results provided in Figure 4, is also not convincing. To select which SAV method should be implementation or scenarios dependent, it's very hard to say which one is the best and be suitable to every scenarios. Considering there are many existing methods, I also agree that these methods should be complementary for optimization of source address validation.
[Libin:] "The analysis of existing data sources provides the evidence in Section 5: (1) For ROA and ASPA objects, a recent study [1] reported that the process of updating RPKI information is not timely, even requiring an hour. (2) For local routing information, the analysis is based on the PS draft, which analyzes existing SAV solutions using local routing information. (3) IRR data may not be always accurate, which is also stated in RFC8704." In the offline discussion with you, I think I had addressed your concerns about Figure 5 by explaining the following paragraph in the draft: "It is noteworthy that the priority ranking of SAV information sources in Figure 5 is recommended rather than mandated. If a new inter-domain SAV mechanism needs to generate SAV rules using low-priority SAV informaiton sources, it should ensure that the correct information is obtained from the corresponding sources and adopts appropriate SAV actions in the data plane to avoid improper block and minimize improper permit. A new inter-domain SAVNET mechanism, in line with the inter-domain SAVNET architecture, has the flexibility to determine the utilized SAV information sources and their priorities accordingly. Especially, when using RPKI ROA objects and ASPA objects as the SAV information source, the new inter-domain SAVNET mechanism should avoid jeopardizing the use of RPKI in routing security."
Joel:] With regard to the priority ranking, trying to translate the terminology into more normative language, is the ranking a SHOULD or a MAY? If it is a SHOULD, when does it not apply? If it is a MAY, why is it included?
[Libin:] This may include two aspects: (1) is data source ranking a SHOULD or a MAY? (2) is data source ranking recommendation a SHOULD or a MAY? For the first question, I think it is a SHOULD. No one data source is perfect. Considering multiple data sources for SAV is natural. As a result, there MUST exist the scenarios that multiple data sources are available at the same time for a prefix, data source ranking is needed to deal with them. I think it does not apply when only one data source can be used. For such scenarios, if operators want to enable SAV, they can only deploy a SAV solution which only leverages that source. For the second question, I think it is a MAY. Before determining a SAV solution, the recommendation can be only based on data sources themselves in terms of accuracy, timeliness, and trustworthiness. Yet, providing the ranking recommendation is helpful for operators or the designers of new SAV solutions to guide their selections of data sources. The generated SAV rules are not only related to the data sources, but also the SAV algorithms and deployment scenarios. Therefore, in the draft, the ranking list of data sources is not mandated. Also, I think solutions using multiple data sources equally just assign the same priority ranking to them.
[Joel:] If what you are saying is that in the architecture it can note that solutions need to include descriptions for how they weigh / rank different sources of truth, that makes good sense. I do not see why there is any need to specify a particular ranking as one that MAY be used in this document.
[KS:] The idea or purpose of ranking is still not clear. For a given customer interface, if SAV-specific data does not show a prefix but BGP data does, would the prefix not be included in the SAV table because the SAV-specific data is ranked higher? The SAV-specific data may not be showing the prefix simply because of partial deployment. Also, the same question applies to RPKI data vs. BGP data. So, in partial deployment, doesn't it become necessary to use multiple data sources in a complementary fashion without any ranking order?
[Libin:] No. For that prefix which is only included in the BGP data in your example, the SAV table can include it according to the BGP data, just according to the relative higher ranking data source. The draft provides an example using Figures 6 and 7 in Section 6. Hope it is more clear.
[Igor:] It makes sense to prioritize information sources, when they contradict each other. Whether any two information sources contradict each other is very specific to which information sources we are considering. For example, if a valid ROA for a prefix exists in RPKI, then a BGP UPDATE message for this prefix with origin ASN not in ROA contradicts RPKI, and we consider RPKI to be of a higher priority, so we ignore the BGP UPDATE message. But if there is no ROA for a prefix in RKPI at all, then we consider ROA and BGP to complement each other in regard to that prefix. This rule is very specific to ROA vs BGP. It will have to depend on the nature of whatever SAV-specific information is proposed by a SAV solution to determine what it means for it to contradict any other SAV information source.
[Libin:] Thank you, Igor. Your example is clear. Regarding to the SAV-specific information, I think its definition is clearly provided. It includes the prefixes and their legitimate incoming directions to enter an AS for inter-domain SAV. Thus, if a prefix's SAV-specific information is obtained, it is expected to just use it to generate SAV table for that prefix. I think if a solution cannot learn the SAV-specific information, it means the solution has problem and it cannot satisfy the requirement for obtaining the real SAV-specific information. We should improve the solution.