Hi Roque,
Thanks for the review and comments.
> General Comment:
> " Depending on the lookup result, we define a property for each route,
> called the "validity state". It can assume the values "valid", "not
> found", or "invalid"."
>
> You may want to consider calling it "Origin AS validity state" to distinguish
> it from the validity state in BGPSEC ("valid" and "invalid").
Ack.
> Section 1:
> p2: s/verifyable/verifiable
Ack.
> Section 2:
> "An AS can originate more than one
> prefix set. Thus, multiple prefix sets in the database can contain
> the same origin AS(es)."
>
> I believe you also need to mention that in the table there may be
> "multi-origin prefixes". Geoff report identifies 2400 but you may find more
> in local/regional environments (http://bgp.potaroo.net/as6447/report.txt).
I looked at the document again and I see many places where we say there can be
multiple origin ASes for the prefix. E.g.:
we define terms "UPDATE prefix" and "UPDATE origin
AS number" to denote the values derived from the received UPDATE message, and
"database prefix set" and "database origin AS number set" to mean the values
derived from the database lookup.
where it's defined as "database origin AS number set" instead of just an AS
number.
>
> Section 5:
> p5:
> I believe you should reference draft-ietf-sidr-origin-validation-signaling-00
Ack
> Security Consideration:
> I think you need to consider what you already mentioned in section 4, if the
> connectivity to the local-caches is lost, invalid routes will be classified
> as "not-found", which could have a different set of local policies.
Is this different from current behavior?
- Pradosh
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
