Re: IDR WG agenda

Paul Knight <pknight@baynetworks.com> Thu, 27 February 1997 21:53 UTC

Received: from cnri by ietf.org id aa12304; 27 Feb 97 16:53 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa24037; 27 Feb 97 16:53 EST
Received: (from daemon@localhost) by merit.edu (8.8.5/merit-2.0) id QAA18340 for idr-outgoing; Thu, 27 Feb 1997 16:26:38 -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 QAA18334 for <bgp@merit.edu>; Thu, 27 Feb 1997 16:26:35 -0500 (EST)
Received: by interlock.ans.net id AA08504 (InterLock SMTP Gateway 3.0 for bgp@ans.net); Thu, 27 Feb 1997 16:25:54 -0500
Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 27 Feb 1997 16:25:54 -0500
Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 27 Feb 1997 16:25:54 -0500
Posted-Date: Thu, 27 Feb 1997 13:25:35 -0800 (PST)
Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 27 Feb 1997 16:25:54 -0500
Message-Id: <3315FB59.6FBE62C0@BayNetworks.com>
Date: Thu, 27 Feb 1997 16:23:37 -0500
From: Paul Knight <pknight@baynetworks.com>
Organization: Bay Networks
X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.3 sun4c)
Mime-Version: 1.0
To: bgp@ans.net
Subject: Re: IDR WG agenda
References: <CMM.0.90.2.857071325.vaf@hq.barrnet.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-idr@merit.edu
Precedence: bulk

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



Vince Fuller wrote:
>     Curtis V:
>     Isn't that MED with a BGP community to send MED no further?
> 
> Is this "BGP community" in the sense of the IRR or in the sense of the
> community attribute? An IRR community isn't very useful to most of us and
> while a well-known community attribute number could be defined to mean this,
> none exists at present (though that might be a reasonable solution).
> 
> There was also some feeling among the large provider community that overloading
> MED in this way could cause other problems, so a separate attribute may be
> preferred.
> 
> Other comments from anyone familiar with the problem to be solved here?
> 
>         --Vince

-- 
Paul Knight 			     mailto:pknight@BayNetworks.com
IP Engineering, Systems Test	     Office: (508) 916-7087
Bay Networks, Inc.	M/S BL2-02	Lab: (508) 670-8888, x-65404
2 Federal St., Billerica, MA 01821	Fax: (508) 670-4004