On Wed, Mar 21, 2012 at 3:19 PM, Eric Osterweil <[email protected]> wrote:
> How about we turn this around with a simple question:
> Suppose two different feasible paths are being evaluated for a single
> prefix/origin pair and one was delivered via a signed bgpsec update, and the
> other was delivered via an unsigned update. What
> annotations/influencers/considerations/etc. does the bgpsec design suggest
> when the router is making its path selection between these two?
>
ideall, I think, the process is something like:
1) first path gets evaluated, is it 'good' (next-hop reachable, not
discarded by prefix-list/etc)
2) second path gets evaluated, is it 'good' (same as above +
origin-validate + path-validation)
If both 1 and 2 come out 'ok', assume each path was received from a
different peer on the same device:
1) 1 - 2 - 701 - you
2) 1 - 3 - 7018 - you
If you decide that your network's policy is 'prefer signed and valid
over unsigned' paths, you'd pick #2. It could be that your method of
doing this is saying:
route-map inbound-bgp permit 10
if route-signed and verified
set localpref 100
Which ideally would let localpref on the #1 route stay normal == 80
and magically you'd just use the 'right' (from your perspective) path.
(signed and verified).
of course, in the beginning of this you may choose a more conservative:
route-map inbound-bgp permit 10
if route-signed and verified
set community you:verified
so you could measure the deployment state of your customers + rest-o-interwebs.
In the end, I think 'bgpsec suggests' that the operator would make
some decision... ideally the same decision across the network.
does that make sense? (the policy is deliberately short and simple,
obviously real policy is longer/stranger, but the end result is the
same)
-chris
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
