Re: IDR WG agenda

Curtis Villamizar <curtis@ans.net> Fri, 28 February 1997 16:11 UTC

Received: from cnri by ietf.org id ab15197; 28 Feb 97 11:11 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa11970; 28 Feb 97 11:11 EST
Received: (from daemon@localhost) by merit.edu (8.8.5/merit-2.0) id KAA01488 for idr-outgoing; Fri, 28 Feb 1997 10:28:13 -0500 (EST)
Received: from interlock.ans.net (interlock.ans.net [147.225.5.5]) by merit.edu (8.8.5/merit-2.0) with SMTP id KAA01480 for <bgp@merit.edu>; Fri, 28 Feb 1997 10:28:09 -0500 (EST)
Received: by interlock.ans.net id AA09857 (InterLock SMTP Gateway 3.0 for bgp@ans.net); Fri, 28 Feb 1997 10:28:06 -0500
Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 28 Feb 1997 10:28:06 -0500
Message-Id: <199702281525.KAA06769@brookfield.ans.net>
To: Paul Knight <pknight@baynetworks.com>
Cc: bgp@ans.net
Reply-To: curtis@ans.net
Subject: Re: IDR WG agenda
In-Reply-To: Your message of "Thu, 27 Feb 1997 16:23:37 EST." <3315FB59.6FBE62C0@BayNetworks.com>
Date: Fri, 28 Feb 1997 10:25:56 -0500
From: Curtis Villamizar <curtis@ans.net>
Sender: owner-idr@merit.edu
Precedence: bulk

In message <3315FB59.6FBE62C0@BayNetworks.com>, Paul Knight writes:
> I believe Curtis is right about this.  
> 
> There is clearly a well-known community (NO_ADVERTISE) which looks like
> it should accomplish this (allowing setting a local-pref known only at a
> specific router).
> 
> from draft-ietf-idr-communities-00.txt:
> 
> Well-known Communities
> 
>    The following communities have global significance and their
>    operations shall be implemented in any community-attribute-aware BGP
>    speaker.
>       NO_EXPORT (0xFFFFFF01)
>          All routes received carrying a communities attribute containing
>          this value MUST NOT be advertised outside a BGP confederation
>          boundary (a stand-alone autonomous system that is not part of a
>          confederation should be considered a confederation itself).
>       NO_ADVERTISE (0xFFFFFF02)
>          All routes received carrying a communities attribute containing
>          this value MUST NOT be advertised to other BGP peers.
>       NO_EXPORT_SUBCONFED (0xFFFFFF03)
>          All routes received carrying a communities attribute containing
>          this value MUST NOT be advertised to external BGP peers (this
>          includes peers in other members autonomous systems inside a BGP
>          confederation).


That's not quite it.  NO_ADVERTISE works if you are sending a more
specific route that you want propogated no further than the immediate
router.

There are some cases.  Most are covered.

  1.  You want to provide a MED solely for the purpose of choosing one
      of two routers.  You want the prefixe advertised into the
      entire world after the choice is made.  This (I think) is
      Vince's case and it is not covered.  Nothing a new community
      wouldn't fix.

  2.  You want to provide a MED for the purpose of selecting an exit
      point among many interconnect points.  This is covered.  Just
      send MED (the other end may refuse it, opting for shortest out).

  3.  You would like to send one metric to pick an interconnect and
      another to select the next hop at the preferred interconnect.
      This could be done with MED.  Multiple all link metrics by N
      (reconfigure your IGP, if you don't have some sort of MED
      algebra on your router, none do).  Then add a small offset (less
      than N) to choose among as many as N routers.

  4.  You either have 1 router, or more than 1 routers and 0 clues, or
      your routers are broken or have no practical way to configure
      MED and/or communities, or you are paranoid that someone else's
      router is broken or you don't care where traffic goes.  Don't
      send MED and/or communities.

  5.  You want to send more specifics to refine the next hop at the
      immediate router.  Set MED and NO_ADVERTISE on the more specifics.

  6.  You want to send send more specifics to refine the exit point
      among multiple interconnects.  Set MED and NO_EXPORT on the more
      specifics.

  7.  You have intimate knowledge of your peer's topology and want to
      send more specifics to choose among multiple interconnects that
      you know are within the same BGP confederation in your peer's
      topology.  Set MED and NO_EXPORT_SUBCONFED (consenting adults
      only).

  8.  You just heard about BGP and don't really understand much of this
      aggregation, loca-pref, MED, community, confederation, stuff.  You
      want to advertise everything you know to your peer and hope they
      can figure out the right thing to do with it and you can't be
      bothered registering any information about your AS or prefixes.
      Leave the planet.  :)

Did I miss any cases?  (Actually I might have one or two extras).

Curtis