>At the Sidr meeting at IETF 69, the following issue was raised in >regards to matching ROAs with NLRI in a BGP update. > >Consider an ISP that receives an allocation of a /20 prefix from source >A, and an allocation of an adajecnt /20 prefix from source B, but wants >to issue an advertisement for the aggregate /19 prefix.
I believe that there was another wrinkle to the issue. (Since I was the one who raised it, I know what I *meant*, although others might have heard differently.) The issue is that some RIRs, when allocating a prefix, will reserve a matching adjacent prefix for future requests, so that the two allocations are aggregatable. This helps limit routing table bloat. Note the difference: this is a *single* source allocating multiple aggregatable allocations. And I believe that it happens frequently, by deliberate process. (Actually, I'm having trouble visualizing allocations from *multiple* sources that are aggregatable - perhaps this only happens when ranges rather than prefixes are involved? I'm lazy and I don't want to do the math - if you have an example of *prefixes* allocated from multiple sources that were aggregatable, could you describe it?) An aggregated cert from a single source does not run afoul of the encompassing rules of 3779 and the res-certs draft, since it is from a single source. But the architecture notes that an RIR (or a source further down the allocation chain) might not always want to create a cert for the aggregate, as the validity times of the two longer prefix allocations might be different. Hence the need for multiple certs, and the choice between either interpreting the validity of a BGP UPDATE based on multiple (singly signed) ROAs or multiply signed ROAs. I believe that multiply signed ROAs are a direct indication of the intent of the prefix holder, while interpreting UPDATEs based on multiple singly signed ROAs is trying to derive the intent of the prefix holder. I am in favor of multiple signatures on the ROAs. --Sandy _______________________________________________ Sidr mailing list [email protected] https://www1.ietf.org/mailman/listinfo/sidr
