Maybe there is misunderstanding ...
Chris example was stating:
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)
One path comes without signature the other one with signature .. AS
PATHs they traverse is disjoined at some point.
Are you saying this can not happen ?
Many thx,
R.
On 3/21/12 6:05 PM, "Robert Raszuk"<[email protected]> wrote:
What happens in your example if singed comes with PATH_SIG listing
4 ASes
(pCount=1 of each) and real AS_PATH is length of 3 ?
so, pcount I'm not a fan of.... but, you're suggesting a path that's
invalid? or impossible?
Worse .. in my example both paths are valid, crystal clear and pass all
validations one can apply.
If you are talking about BGPSEC as currently proposed, this can't happen.
The definition of validity of a PATH_SIG is that valid signatures exactly
correspond to AS_PATH data.
See:
http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-02#section-5.1
Once again, given the encoding of AS_PATH directly in PATH_SIG attribute,
the exact scenario is moot (a BGPSEC update will never contain both
AS_PATH and PATH_SIG attributes), but the spirit is the same, the
validation algorithm will return "Invalid"
Dougm
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
