On Tue, Dec 14, 2004 at 07:32:11AM -0800, Randy Bush wrote:
[snip]
> > ...so many times the analysis comes back to "accept everything
> > and only react to outside-influence-of-the-moment" or "follow
> > allocation guidelines for a baseline filter and adjust as
> > business needs dictate".
>
> you don't think what was discussed on c-nsp is
> o simple enough code the vendors might get it right on
> the third try, and
> o has the knobs you need to set reasonable (to you)
> policy?
>
> if not, why not?
I'm under the weather so need to re-read both the pseudo-code
that was bounced around and draft-hardie-bounded-longest-match
to give an informed reponses. I am compelled to not let the
attempt to have real discussion here fall down just because
of my lack of input. My gut feeling is that for some deployments
where this is a concern [multihoming smaller enterprises],
restricting to next-hop would not be appropriate and that a
knob for next-hop or neighbor-AS would be needed. Given the
nature of current vendor-implementations of ebgp policy knobs
and the way folks have cleverly deployed them, I would think
not closing too many doors would be in the best interest of
all.
So yes I'd suggest giving operators enough rope to hang
themselves if they go overboard, by providing supressing
remote more-specifics ['bounding the longest match'] on a
number of policy axes:
next-hop [straightforward seen as the Right Thing]
router-id [not nescessarily the same as above - also consider
the wildly useful variation of router-id to trigger the
neighbor's supression anologous to the clever use of RPF
to trigger blackholes today]
neighbor AS [to address local next-hop related complexities]
MED ("i wish to get the more-specifics if my neighbor tells me
there is value")
Origin (similar to above point)
It essentially comes down to how much 'sameness' is needed to
consider them identical? If we don't cover for minor variances
lower down the decisions tree then suddenly those 'lower points'
become very significant knobs to turn. I can see people arguing
with me about that [MED and origin]; I can table that for now.
Router ID seems natural and trivial if we're already inspecting
next-hop. I will strenuously argue that neighbor ASN be considered,
specifically to speak to Mr Donacaster's point. This provides
the simple multihoming the end-customers automatic control over
attemtps to siphon their traffic; consquently there is no economic
incentive for those customers' providers to tacitly encourage table
pollution. In the simplified case of
- two multihomed enterprises, one of which
(a) announces extra crap and the other
(b) who doesn't want to hear it
and
- two transit carriers, one of which
(c) deploys the new feature and the other which
(d) does not
+-- C --+
/ \
A --- D --- B
C presents A's long prefix to B
D presents A's long and short prefixes to B
B has paralel links ro D, attached to the same border
within B and disparate aggregation devices in D.
supression based on next-hop or even router-id couldn't
comparison wouldn't help poor B. based on AS would.
Neighbor-AS-based comparison also simplifies configuration
[ports and therefore next-hop migrate more frequently
than ASNs do], and we are told time and again that root
causes of most network issues are configuration-wrangling
related.
In the long term, we [or our memetic descendants] are likely
to be discussing the centralized nature of this point on the
decision tree and a RIB-vs-FIB issue just as we all went round
the separating-a-distributed-FIB-from-centralized-RIB maypole
in the mid->latter 90s.
Cheers,
joe
--
RSUC / GweepNet / Spunk / FnB / Usenix / SAGE