Re: Addresses in traffic selectors in IKEv2

[Michael Thomas <mat@cisco.com>]

Isn't this just a presentation issue? That is, you
could allow net admins to input things as subnets,
but under the hood, it converts things to ranges
for IKE. I'd think the TCAM issue would be
similar: if people mainly use the selectors on
subnet boundaries, it wouldn't have an effect on
TCAM consumption, right? Assuming that you allow
for ranges anyway, I don't really see what the 
upside is.

	Mike


David Waitzman writes:
 > 
 > We recommend against ranges and for masks for two reasons:
 > 
 >  - ranges are less natural to network administrators; they tend to
 >    work more with IP prefixes (masks) when handling configuration
 >    tasks; IP prefixes also tend to reflect the sub-topology of a local
 >    network, while ranges don't.  (However, ranges are more flexible,
 >    and *don't* bind you to subnet topology, so they're also useful,
 >    especially for things like web farms.)
 > 
 >  - (as stated already) arbitrary ranges don't compile into ternary
 >    CAMs very well, especially if there are multiple range-based
 >    selectors in a policy or SAD entry; in the worst case, it uses
 >    2*(log2 rangeSize)-1 entries per range; if multiple ranges are
 >    found in the same selector, you need the *product* of the number of
 >    CAM entries for each field, in total.  (Don't expect this happens
 >    much in the real world, though.)  IP prefixes (or other mask/value
 >    entries) only require a single CAM entry.
 > 
 > -david waitzman
 >  BBN Technologies Internetwork Research Department