On 3/13/13 1:28 PM, "Andrew Chi" <a...@bbn.com> wrote:
>On 3/13/13 10:19 AM, Andrew Chi wrote: >> Yesterday, Ruediger talked about a 4th validation state for BGP routes >> (RFC 6811 gives only 3). After thinking about it more, I believe it may >> be helpful to call this validation state "Uninitialized". Here's why. > >After talking to Doug and Sriram, it sounds like others already had this >discussion using the term "Undefined." That's probably a better word, >since one might need it for more than just startup conditions. > >Should we explicitly call out this state? Did we already decide not to? As you correctly state Doug and Sriram, we do allow the validation state "undefined" in our implementations BGP-Srx and QuaggaSRx. This is for the timeframe where no information regarding the particular prefix/origin is known or during its calculation. In our implementation for instance we out-sorced the internal validation process into its own API - checking the prefix-origin against the output of the validation cache outside of the router. During this timeframe (which is a very short timeframe for origin validation - but longer for path validation) we provide the state "undefined" to allow the router to continue processing the update until the final validation result is available and handed back to the router. We added policies that can specifically deal with this situation which allows us for instance to ignore the update until a calculated result (one of the three specified ones) is available. But IMHO this is an implementation specific solution and others might do it differently. The main problem, as far as I understood it after talking to Ruediger yesterday, is the timeframe in which the router fetches new information. In other words the timeframe between "Serial Query" and "End of Data" - RFC 6810. During this time new ROAS will be introduced or removed from the router. If during this time the router reacts to each change individually without waiting for the "big picture" of this particular fetch/synchronization, the following problem can arise: In case a route with a x/24 prefix has the validation result of "NotFound" and a new ROA is introduced with a lesser specific prefix and insufficient max length or even another ASN, this route will automatically change its state from "NotFound" to "Invalid". If on top of this the prefix in question belongs to the route that is selected, a withdrawal of this route occurs. Now an additional ROA is introduced that contains the exact x/24 prefix including the same ASN, the route's validation state switches from "Invalid" to "Valid" and the route will be re-selected. If the router would have waited with its processing of the new information until all new information are added to the system, the route never would have been switched to "Invalid". In contrary, it would have switched right away from "NotFound" to "Valid" without passing "Invalid" and therefore no change in path selection would have occurred. For this I see two solutions: (A) The validation cache MUST send the deltas ordered from more specific to less specific prefixes. (B) The router does not process the new information until "End of Data" Thinking further about (A) it would only solve the problem of a ROA specifying the lesser specific prefixes that would invalidate the more specific prefix but not the problem of a "same" specific prefix with a different ASN. Here the temporary switch to "Invalid" will occur. This leaves us with only solution (B) that requires the router to wait until the cache update is performed (receiving "End of Data"), before using the new information "snapshot". But to not having to wait with calculating validation results until the update is performed, the old "snapshot" should be used. But this problem will not be resolved by adding a fourth state "undefined". It is more a Best Practice kind of thing which the implementer MUST be aware of. Going back to the missing state "undefined", I think this is an implementation dependent solution that actually only exists during the time until either a validation state is calculated or during a power up or until the FIRST "End of Data" is received from the validation cache - I would not call it uninitialized because it also includes the time between validation request and validation result as described earlier. This time is short but not to neglectable, especially during table dumps. Said that I firmly believe the state "undefined" should be added for clarity and allowing a defined asynchronous processing of update validation without delays of regular update-processing due to the fact of a synchronization between router and cache. But again this could also be only seen as too much implementation dependent. Maybe one more information to our implementation, we allow to freely configure our initialization state, which is by default "undefined" but can be configured to any other state and therefore provide the operator with a maximum on flexibility on how to proceed in this case. Oliver --------------------------------------------------------------------------- - Oliver Borchert Computer Scientist National Institute of Standards and Technology phone: 301-975-4856, fax: 301-975-6238 _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
