Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document



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/ 

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.