>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.
In the case OV, the marking (in accordance with RFC 6811) needs to be per route (regardless of the peer it was received from). My suggestion for the case of policy/no-policy: There can be two overarching flags per peer that can be Red (set) or Green (not set): 1. No-ingress-policy flag: If Red (set) for a given peer, then all routes from that peer will be marked ‘no-policy-invalid’ in the Adj-RIB-in. 2. No-egress-policy flag: If Red (set) for a given peer, then no routes will be announced to that peer. Sriram ----------------------------------------------------------------------------------------------------------------- From: Brian Dickson [mailto:[email protected]] Sent: Tuesday, August 23, 2016 8:33 PM To: Sriram, Kotikalapudi (Fed) <[email protected]> Cc: Greg Hankins <[email protected]>; [email protected]; Job Snijders <[email protected]> Subject: Re: [GROW] Working Group Adoption Call: draft-mauch-bgp-reject 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 _____________________ _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
