This is an important document. I have 2 comments, 2 nits, one question and a comparison of this draft with draft-sidr-pfx-validate section 6 called "deployment considerations". I have reviewed Section 5 of draft-sidr- origin-ops only.
Comment 1) The validation state terminology used in this draft is not consistent with the terminology of draft-sidr-pfx-validate. That draft uses states: valid, invalid, not found, whereas this draft uses states: valid, invalid, unknown. Do we want these to be consistent across i-ds? The 3 states are defined in draft-sidr-pfx-validate but are not defined here. We should either define them or point to the definition in draft-sidr-pfx-validate where they are defined. I will refer to this as state "not found" in the remainder of my comments. Comment 2) Some suggested text below for the opening of section 5. Section 5. Routing Policy Background Currently, the origin status information is not verified. With the incremental deployment of RPKI, we will transition to origin validation comprised of three states: valid, invalid and not found [see draft-sidr-pfx-validate]. We specify a relative preference associated with each state as follows: Announcements with valid origins SHOULD be preferred over those with *not found* or invalid origins. Announcements with *not found* origin SHOULD be preferred over those with invalid origins. Announcements with invalid origins MAY be used, but SHOULD be less preferred than those with valid or *not found*. During the RPKI transition period, relative preference is introduced to manage the uncertainty associated with a system in flux. As the RPKI transition moves forward, the number of origin validations with state "not found" will decrease. Nits: Section 5. Routing Policy 1) Reasonable application of local policy should be designed eliminate the threat of unroutability of prefixes due to ill-advised or incorrect certification policies. Suggestion: Reasonable application of local policy should be designed *to* eliminate the threat of unroutability of prefixes due to ill-advised or incorrect certification policies. 2) As origin validation will be rolled out over years coverage will be spotty for a long time. Hence a normal operator's policy should not be overly strict, perhaps preferring valid announcements and giving very low preference, but still using, invalid announcements. Suggestion: As origin validation will be rolled out *incrementally* coverage will be *incomplete* for a long time. Hence an *word deleted* operator's policy should not be overly strict, perhaps preferring valid announcements, *attaching a lower preference to but still using, not found announcements* and giving very low preference, but still using, invalid announcements. I deleted the word "normal" since I don't know what normal is. I think you need to point out here that they will use all three, valid, invalid and not found announcement. For some reason it is missing from this paragraph but is correctly included in the list below. Question: I'm not sure I understand this. "Reasonable application of local policy should be designed *to* eliminate the threat of unroutability of prefixes due to ill-advised or incorrect certification policies." What is ill-advised as opposed to incorrect? Does ill-advised means one kind of error and incorrect another? If they are really one problem, then just use one term. Comparison of draft-sidr-pfx-validate section 6 called "deployment considerations": I'm confused by the relationship of this draft to draft-sidr-pfx-validate section 6 called "deployment considerations". Is this the operational section and therefore should draft-sidr-pfx-validatereference draft-sidr-origin-ops? The deployment guidance is not the same in sidr-pfx-validate as it is in sidr-origin-ops in the sense that there are no SHOULDs or MUSTs. The deployment considerations in sidr-pfx-validate are just advice. Here is the specific text from draft-sidr-pfx-validate: 6. Deployment Considerations "Once a route is received from an EBGP peer it is categorized according the procedure given in section 2. Subsequently, routing policy as discussed in section 3 <http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate-00#section-3> can be used to take action based on the validation state. Policies which could be implemented include filtering routes based on validation state (for example, rejecting all "invalid" routes) or adjusting a route's degree of preference in the selection algorithm based on its validation state. The latter could be accomplished by adjusting the value of such attributes as LOCAL_PREF. In some cases (particularly when the selection algorithm is influenced by the adjustment of a route property that is not propagated into IBGP) it could be necessary for routing correctness to propagate the validation state to the IBGP peer. This can be accomplished on the sending side by setting a community or extended community based on the validation state, and on the receiving side by matching the (extended) community and setting the validation state." Maureen
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
