Hi Sriram,
> Question 1:
>
> It seems this draft proposes Changes to the BGP Decision Process (Section 3).
> It is not clear that the decision process behavior described in this ID can
> be implemented
> by manipulation of the existing policy knobs.
> What is described seems to be an addition to the decision process, not just
> policy tricks.
> I am wondering if that is acceptable?
The decision process changes in the draft are to define an automatic way of
preferring
valid routes for folks that do not want to do manual policy tricks. As we have
discussed
previously, the steps in origin validation are as follows:
1. Check against the origin AS database,
2. Mark the routes as one of {valid, not found, invalid}
3. [Policy tricks to match on the marking and change attributes]
4. [decision process change to automatically prefer valid > not found > invalid]
The last two steps are optional - they can both be executed or one of them or
none ;-)
> Question 2:
>
> The I-D is proposing to explicitly work with
> "validation state" 0 (valid), 1 (not found), and 2 (invalid)
> in the BGP Decision Process.
>
> One thing I am not clear about the proposal is how can this proposed
> order of actions work?
> a. Validation step: "When comparing a pair of routes for a BGP destination,
> the route
> with the lowest "validation state" value is preferred."
>
> b. "the validation step MUST
> be performed prior to any of the steps defined in the decision
> process of [RFC4271]."
>
> As I see, at first the decision process has to select from available paths
> the candidates for best path (including policy considerations, etc.);
> it then makes an ordered list of the candidates; then it can apply the rule of
> "the lowest "validation state" value is preferred."
>
> Seems to me that it is not possible the other way round that the I-D seems to
> require (MUST)?
What (b) really says is that the validation state of a pair of routes should be
compared
before the LOCAL_PREF comparison step (that comes first in the decision process
followed by AS_PATH length followed by origin etc.)
- Pradosh
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
