On Wed, Mar 06, 2002 at 01:21:01PM -0500, Howard C. Berkowitz wrote:
> At an abstract level, not much. On a real level, I would be concerned
> about the performance implication. Does one domain, for example,
> send all its policy rules to another, or does the receiving design
> request the ones it needs?
Theoretically, you could just flood all certificates at the
start of your peering session and any updates to them (highly
infrequent?) at the start of your peering session. You only
need propagate certificates for the routes you are using and
propagating.
> Perhaps there's an analogy here to ORF, but outbound policy filters.
> I'm not prejudging, but just as we often want to avoid the transfer
> of a whole RIB, we may want to prevent the transfer of an entire
> domain policy.
See above.
> There are certainly several ways to avoid this. Something like ORF in
> the "routing protocol," or a client/server ability to request policy,
> perhaps in the spirit of source demand routing (SDR).
No different really. You only get that which the other guy is using.
> But I'm drifting into the area of protocol. The broad requirement, I
> believe, is that policy distribution should not have an appreciable
> effect on the performance of what, for lack of a better term, I'll
> call the real-time control plane.
But that *is* a protocol issue. If its distributed in-band, its
going to delay convergence. If the protocol says to process the
certificates synchronously with installing the routes, thats an
issue. Out of band certificate reception also forces things
to be asynchronous with respect to validation and propagation of
routes. The exact mechanisms aren't important, but the generalities
are - they specify the architecture.
> Is something missing before your next couple of paragraphs?
About 6 hours of sleep. Sorry.
> I'm unclear, for example, if the updates,
> the policy data base, or both are signed.
Some elements may require signing. I'm generically referring to the
signature method as "certificates" although that particular mechanism
may not be appropriate. More analysis is required.
> That is one potential requirement, which I'll call the optimistic
> case. There may be a different but equal pessimistic case where
> routes are not used until validated. A requirement document could
> very well identify these as alternate choices.
Or leave the route usage pre- or post- validation as a matter of
choice with the requirement that you indicate that you've
validated your validation of it or not. In the case of
nested signatures, this is pretty apparent.
-- Jeff Haas NextHop Technologies
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT