At the end of Section 4, you may consider adding a sentence to the effect: It is expected that the AGGREGATOR AS will have a ROA registered that permits the AGGREGATOR AS to originate the aggregate prefix.
The following comments are similar to what I have observed for draft-ietf-sidr-roa-validation-03: There is substantial commonality in the problem space addressed as well as the solution (algorithm) described between the two documents: draft-pmohapat-sidr-pfx-validate-03 and draft-ietf-sidr-roa-validation-03. The algorithm in this ID and also that in draft-ietf-sidr-roa-validation-03 do not cover another case of partial deployment where suballocations legitimately originate from a different AS and while a parent prefix has a ROA with ISP's AS origin, the suballocation (customer's) has no ROA registered yet. Please see slide 4 in link below (I had emailed this to SIDR list soon after the SIDR WG meeting in Stockholm): http://www.antd.nist.gov/~ksriram/SIDR_ROA_BOA_Interpretation.pdf I must admit that I am a bit torn about how to cater to this type of partial deployment condition. One way out is to have a deadline prior to which the validation decisions would be soft ("not found") for this case and then the hard decision ("invalid") kicks in after the deadline (again see my slides; use of BOA or ROA with AS0 may be helpful but not essential as discussed in my slides 5 and 6). Sriram K. Sriram +1 301 975 3793 http://www.antd.nist.gov/~ksriram/ _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
