On 17 Aug 2005, at 13:49, Jeffrey Haas wrote:
From the document in question:
http://www.ietf.org/internet-drafts/draft-ietf-grow-anycast-01.txt
: 4.4.3 Equal-Cost Paths
:
: [...]
:
: Equal cost paths are commonly supported in IGPs. Multi-node
: selection for a single transaction can be avoided in most cases by
: careful consideration of IGP link metrics, or by applying
equal-cost
: multi-path (ECMP) selection algorithms which cause a single node
to
: be selected for a single multi-packet transaction. For an
example of
: the use of hash-based ECMP selection in anycast service
distribution,
: see [ISC-TN-2004-1].
:
: For services which are distributed across the global Internet
using
: BGP, equal-cost paths are normally not a consideration: BGP's exit
: selection algorithm usually selects a single, consistent exit for
a
: single destination regardless of whether multiple candidate paths
: exist. Implementations of BGP exist that support multi-path exit
: selection, however, and corner cases where dual selected exits
route
: to different nodes are possible. Analysis of the likely
incidence of
: such corner cases for particular distributions of Anycast Nodes a
: recommended for services which involve multi-packet transactions.
[...]
While this is indeed a corner case, it relies on that particular
vendor's
implementation to "get it right". Given that this is a
non-standardized
feature and that I've heard several non-optimal multipath suggestions,
this document would be well served by having some sort of caveat in it.
Such a caveat is there in the last sentence that you quoted. Do you
think additional text is required?
E.g.:
"In cases where a BGP implementation supports multi-path exit selection
in such a fashion that it is possible that routes to different Anycast
Nodes may result, that implementation SHOULD support a feature to
disallow multi-path route selection for Anycast reachability."
This sounds like text more appropriate for RFC1771's successor than for
this draft? It's also BGP-specific, whereas I intended the text to be
more protocol-agnostic (although I was not as explicit as apb was in
his earlier summary).
Joe
_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive: http://darkwing.uoregon.edu/~llynch/grow/
