I also have some problems with aspects of the
draft-ietf-sidr-pfx-validate-04.txt draft, particularly this bit from
Section 2:
When a BGP speaker receives an UPDATE from one of its EBGP peers,
it SHOULD perform a lookup as described above for each of the
Routes in the UPDATE message. [...] This procedure SHOULD NOT be
performed for Routes learned from peers of types other than EBGP.
... and this from Section 5:
In some cases (particularly when the selection algorithm is
influenced by the adjustment of a route property that is not
propagated into IBGP) it could be necessary for routing correctness
to propagate the validation state to the IBGP peer. [...]
Regarding the latter: What kind of route property is envisioned that
is not propagated into IBGP, but _is_ propagated via EBGP?
Regarding the former: I expect many networks to be faced with
partial-deployment of origin validation for some time: some older edge
routers will never be upgraded to be rpki-cognizant, while most newer
edges and route reflectors will be.
When a route reflector learns a route from an rpki-ignorant edge, I
would want the RR to perform its own origin validation, deciding the
validation state based on its own local cache.
But taking this further: why _wouldn't_ we want the RR to perform the
same origin validation on every prefix it learns, based again on
contents of local cache and local policy? I think we would.
Going still further: rpki-cognizant edge routers should themselves
perform origin validation on all BGP-learned routes, even those
learned via IBGP from RRs.
At a minimum, if the draft's authors persist in recommending that
origin validation is only for EBGP, they should describe why that is.
Jay B.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
