Sriram & Greg: I think the underlying issue is some terms used in *implementations*, which do not match exactly with the BGP protocol specifications (1771 and 4271).
There are a few terms which get used interchangeably, unfortunately, which need some disambiguation (IMHO). Those terms are: - unfeasible - withdrawn - unresolvable - invalid - (excluded) and now includes - OV-invalid - (this document's marking of "no-policy-invalid") Whether the same "bit" in the internal representation should/could be used is pretty important; if different implementations conflate distinct situations, interoperability could be affected. I believe it is the case that at least the two big router vendors used the labels "invalid"/"valid" as a representation of "unresolvable", which has lead to this confusion. The RFCs actually use "invalid" to mean that some mandatory attribute is either missing or malformed, and should temporarily be marked that way, until withdrawal(s) happen, including from the RIB/FIB. (I think there are minimum 3 conditions that trigger that in the base spec, probably more in subsequent BGP attributes/families.) Invalid is actually an temporary thing, since the affected NRLI should be purged once other actions are completed. Unfeasible is aka withdrawn, and is also in effect a temporary thing; once processed, the unfeasible routes are gone from the in-RIBs and RIB. Unresolvable is a derived state, based on the NEXT_HOP not being resolvable. It doesn't go away automatically, unlike invalid and unlike unfeasible routes. It CAN change as a result of state changes on the route specified by the NEXT_HOP, independent of the NLRI itself. OV-invalid is similar to, but distinct from, unresolvable, and should NOT be implemented using the same "bit"/flag. However, I believe the "unresolvable" and the "no-policy-invalid" attributes are fine to represent with the same "bit", since neither should be able to pass Phase 2 of the path selection process. At some point down the road, a "bis" version of the base spec should be done, which makes minor revisions to clarify these terms, among other things. IMHO. For now, it may be necessary to add clarification/definitions to this document to make it clear to readers/implementers, what "invalid" means in this context. Brian On Tue, Aug 23, 2016 at 2:21 PM, Sriram, Kotikalapudi (Fed) < [email protected]> wrote: > > >>We also need to distinguish between ‘invalid’ due to RPKI/ROA origin > validation vs. ‘invalid’ due to BGP-sans-policy. > >>If ‘invalid’ due to RPKI/ROA, the route may be installed and advertised > if there is no alternative route (for that prefix). > >>(At least during the early adoption phase.) > > >If the route is invalid in Adj-RIB-In, it wouldn't even reach any next > steps in > >the decision making process as above. So any further mechanisms such as > origin validation, > >prefix filtering, or evaluating routing policies configured by the > operator would not even be reached. > > Let us say, all received routes were ok (i.e. not marked 'invalid') > initially because ingress policy is there. > Now route engine (RE) does origin validation (OV) and marks a route > 'invalid' (see RFC 6811) in the RIB > (i.e. saves the OV result for possible further use later) . > The next time this RIB entry (route) is considered in the decision > process, there may be > confusion if it is policy 'invalid' or OV 'invalid'. > I think the labeling of routes needs to distinguish between the two > (RFC6811 vs. policy). > > > Sriram > _______________________________________________ >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
