Communities

Hank Nussbacher hank at att.net.il
Wed Oct 17 16:06:09 UTC 2001


At 17:52 17/10/01 +0200, Niels Bakker wrote:

Been there.  We tried to put together a simple RFC for communities to 
influence routing as can be found at:
http://www.att.net.il/~hank/bgp-glob-comm.txt

IDR never accepted it so it died a quiet death.

-Hank


>* eddy+public+spam at 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.




More information about the NANOG mailing list