Re: Communities

["E.B. Dreger" <eddy+public+spam () noc everquick net>]

> Date: Tue, 16 Oct 2001 18:30:05 +0200
> From: Niels Bakker <niels=nanog () bakker net>

> > In short, we start looking at multiple FIBs.  It's not really
> > that much more difficult; it's more of a scalability issue.  I
> > know that Zebra can run multiple router processes, but I've not
> > played with this feature... perhaps that's a start.
>
> Zebra doesn't actually forward packets.  Ciscos with newer IOS can do

Correct.  It edits the *ix kernel's FIB, adding and deleting
routes.  However, Zebra running on a single machine can have
multiple BGP processes running... which is along the same lines.

> this (12.0T and onwards) with different VRFs.  I've seen companies who
> have something like that in production; packets hit the same router a
> few times in a row in a traceroute.

Interesting.  I was unaware of this.

> > > Frankly, if I were B I'm not sure I'd be all that happy with customers
> > > influencing my routing decision process.  They hand me their packets
> > > (or not); that should be it.
> > I disagree.  Let's say that you sell me transit, and purchase
> > yours from 701 and 1239.  Would you complain if I fill my pipe to
> > you with traffic to/from 701?  No.  If I fill it with traffic
> > to/from 1329?  No.
>
> Yes, I would complain if you sent me packets with source addresses you
> shouldn't be sourcing (i.e., not your own).  Traffic from 701 or 1239
> should not pass you to reach me (if I were B and you customer A).

Whoa!  Where did I say spoofed packets?  If 701 is one of your
upstreams or peers, then I can exchange traffic with 701 all day
long.  I never indicated using improper source addresses.  Please
reread my post.

        me <--> you <--> 701
        me <--> you <--> 1239

Both are valid.

> > Why, then, would you complain if I set a community to _prefer_ 
> > 701 over 1239 or vice-versa?  By giving your downstreams fine-
> > grained tuning, you allow them to tinker for a system that they
> > like... and you don't reach the extreme cases that are possible
> > even without fine-grained tuning.
>
> This is about packets from the world via me to you, not from you to the
> outside world.  The case you just described already exists; I wrote so
> before (albeit in a bit broken English).
>
> The only routing decision customer A can force upon B is "Send packets
> destined for these netblocks <here's a BGP announcement> to me," and

In your scenario.  But this is arbitrary; it is not borne of
necessity due to the technology.

> enforces this via a contract both parties enter in and A (presumably)
> pays B for.

Let's say that I'm strictly a Web host.  Inbound traffic is
negligible.  I send any and all 701-bound traffic via you; any
and all other traffic goes through <some other upstreams>.  No
complaint there -- and I can do this in your aforementioned
scheme.

Why do you balk at a community that says "I dislike 1239"[1],
thus _preferring_ 701, when I could simply route _all_ non-701
traffic over another one of my upstreams?  IMHO, your dislike
of tuning is illogical... I can sway the balance _far_ more
with coarse-grained routing when you don't provide fine-grained
controls.

Not providing fine-grained tuning accomplishes nothing positive,
and can be a negative thing.  Offering it provides benefit, and
is not difficult.[2]

[1] Reminder:  Hypothetical example.  Interpret accordingly.  I
used 701 and 1239 in my original example, and don't care to
change the scenario.

[2] Yes, more maintenance with communities.  But a few dozen is
all it takes to handle many ASen with a few different lengths...
both the initial effort and upkeep are negligible.  Search the
archives for this discussion.


Eddy

---------------------------------------------------------------------------
Brotsman & Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence
---------------------------------------------------------------------------

Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist () brics com>
To: blacklist () brics com
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.  Do NOT
send mail to <blacklist () brics com>, or you are likely to be blocked.