I spent some time thinking about your points, and here's the conclusion
I came to:
(i) what you are proposing is essentially weak ES (with longest prefix match),
with a variant to the "cost" used for ECMP: within a set of equal
prefix length routes, the ones that have a src addr match are considered
"lower cost".
(ii) Whereas what I'm defining as src-priority is (like strong ES)
not the longest prefix match- its saying "first try strong ES, and if
that fails, fall back to weak ES".
For the common case of a host having equal length routes (typically
the default) for the dst, it turns out that both definitions will result
in the exact same behavior.
for the less common cases e.g., host participates in routing, but
not forwarding, resulting in unequal prefix length routes
for the target subnet, e.g.,
target
longer path : |
rtr1 rtr2
\ /
A B
sender
there will be some differences between (i) and (ii). In the above
example, (ii) would have a better shot of getting past ingress filters
by going through the longer path (unless some other routing table
massaging is applied).
I'm not currently proposing variations in today's ECMP algorithm
for weak ES model such as those suggested in (i).
If the variations needed to ECMP for weak ES in (i) are seen
as a solution to some problem that's not covered by the common case
(which is covered by (ii)), then as Jim points out this proposal does
not provide that solution.
But given that the "common case" is actually covered by (ii), *if*
the "uncommon case" scenario is really found to be a rampant one, we'd
have to modify the ECMP algorithm for weak ES to implement (i). I'm
suggesting that we should defer that ECMP extension until we have enough
data on how rampant this scenario is.
--Sowmini
_______________________________________________
opensolaris-arc mailing list
[email protected]
