Re: Communities

[Niels Bakker <niels=nanog () bakker net>]

* eddy+public+spam () noc everquick net (E.B. Dreger) [Tue 16 Oct 2001, 21:09 CEST]:
> > > 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.

Except that Zebra currently does not have any provisions to be able to
tell the forwarding engine it's running on (i.e. any Unix) a rule to the
effect of "If packets originate from this peer [this interface] and are
destined for this prefix, route them over that particular interface
instead of the interface that would've been taken for all packets from
all other prefixes."  Which is, in effect, what multiple FIBs mean in
practice.


> > > > 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.

Sorry, I misread you.  Let me restate my previous statement before that
a bit then: Yes, I would mind them attempting to choose which exit point
into AS701 their packets would take.  This could lead to suboptimal
performance for all B's customers and a loss of control over the bills
sent to B by its upstream providers.  In addition to having to monitor
its own network for long-term bottlenecks B will have to stay on a
continuous alert for customers clogging one link.


>       me <--> you <--> 701
>       me <--> you <--> 1239
>
> Both are valid.

Used above by me,
customer A <--> B <--> AS701 (West Buttmunch)
                  <--> AS701 (East Buttmunch)

(numbers hold of course no discernable relationship to reality)


> > > 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.

Actually, yes. The technology exists today for customer A to tell B to
announce A's prefixes only to some peers/upstream providers of B, but
not to route packets from A all via some peers/upstream providers of B
and not via the others, even though B would choose those routes for its
own packets (and thus has installed them into the FIBs of their routers).


> > 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.

Because then you introduce C into the mix, another upstream provider of
A.  That's cheating.  :-)

I thought the whole discussion was about B having multiple exit points
and A influencing what exit points from B's network A's packets would
take?


> Not providing fine-grained tuning accomplishes nothing positive,

Simplicity for its own sake also has value (even aside from benefits
like easier troubleshooting in case of failures, no need to generate
transient outages while fiddling with the tuning knobs, etc.).

Regards,


        -- Niels.