From idr-admin@ietf.org Mon Mar 1 03:25:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01487 for ; Mon, 1 Mar 2004 03:25:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axijz-00053G-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 03:25:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axij1-0004ul-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 03:24:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxiiA-0004oR-00; Mon, 01 Mar 2004 03:23:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axign-0006Nh-9P; Mon, 01 Mar 2004 03:22:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axifv-0006HG-Db for idr@optimus.ietf.org; Mon, 01 Mar 2004 03:21:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01065 for ; Mon, 1 Mar 2004 03:21:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiYT-0003qt-00 for idr@ietf.org; Mon, 01 Mar 2004 03:13:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiXR-0003ky-00 for idr@ietf.org; Mon, 01 Mar 2004 03:12:33 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AxiWi-0003g8-00 for idr@ietf.org; Mon, 01 Mar 2004 03:11:48 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxiWj-000HNl-Ic for idr@ietf.org; Mon, 01 Mar 2004 08:11:49 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <9934308202.20040301171127@psg.com> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Idr] Experimental code-points Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 17:11:27 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. -- Alex http://www.psg.com/~zinin/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 03:25:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01509 for ; Mon, 1 Mar 2004 03:25:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axik0-00053S-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 03:25:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axij2-0004v0-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 03:24:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxiiA-0004oS-00; Mon, 01 Mar 2004 03:23:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axigg-0006L9-Pc; Mon, 01 Mar 2004 03:22:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axifs-0006Gg-Pk for idr@optimus.ietf.org; Mon, 01 Mar 2004 03:21:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01031 for ; Mon, 1 Mar 2004 03:21:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiZU-0003xv-00 for idr@ietf.org; Mon, 01 Mar 2004 03:14:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiYb-0003sK-00 for idr@ietf.org; Mon, 01 Mar 2004 03:13:46 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AxiY4-0003lc-00 for idr@ietf.org; Mon, 01 Mar 2004 03:13:12 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxiY5-000HTj-1k for idr@ietf.org; Mon, 01 Mar 2004 08:13:13 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5734391782.20040301171251@psg.com> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Idr] Comments on draft-chen-bgp-redist-00.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 17:12:51 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Comments I brought up today: 1. The problem appears because there are two points within the router where two routes are compared. The draft suggests that the BGP path selection process is made consistent with the selection process in the routing table (AdminDist-based). The question is whether the problem statement is applicable for the implementations where BGP path selection and AD comparison happens at the same time (from what I remember, gated did that). In other words, the question is whether the problem is implementations specific or not, and hence whether a change to the protocol is appropriate. 2. Suggestion: seems that the problem can be solved without changing the best path selection process. The idea is to establish a 1:1 mapping between LOCAL_RPEF and AD, i.e. take the AD value and use it as LOCAL_PREF value when importing (redistributing) routes to BGP, and use the LOCAL_PREF value as the AD when installing routes in the routing table. The advantage is it automagically makes the route selection decisions consistent not only within a single router, but throughout the iBGP mesh too. Food for thoughts... -- Alex http://www.psg.com/~zinin/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 03:34:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02219 for ; Mon, 1 Mar 2004 03:34:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axism-0006K3-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 03:34:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axirv-0006EL-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 03:33:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxirI-00068D-00; Mon, 01 Mar 2004 03:33:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxirF-0000kv-P8; Mon, 01 Mar 2004 03:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axiqp-0000ji-Dz for idr@optimus.ietf.org; Mon, 01 Mar 2004 03:32:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02097 for ; Mon, 1 Mar 2004 03:32:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axiqn-00066Z-00 for idr@ietf.org; Mon, 01 Mar 2004 03:32:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axiq0-00061o-00 for idr@ietf.org; Mon, 01 Mar 2004 03:31:45 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=kummer.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AxipM-0005rb-00 for idr@ietf.org; Mon, 01 Mar 2004 03:31:04 -0500 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id i218UZPg027790 for ; Mon, 1 Mar 2004 00:30:35 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id i218UZLn027787 for ; Mon, 1 Mar 2004 00:30:35 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs From: Kireeti Kompella To: idr@ietf.org Message-ID: <20040301001457.L27706@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Idr] BGP-based VPLS Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 00:30:35 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Following up on the discussion regarding BGP for L2VPN auto-discovery, draft-ietf-l2vpn-vpls-bgp-01.txt does auto-discovery and signaling for VPLS. Of special interest to this WG is section 3, where the NLRI format for this AFI/SAFI (*) pair, and other topics are described. (*) SAFI = 65; AFI not yet allocated. It seems sensible to use the AFI allocated for auto-discovery. Kireeti. ------- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 03:35:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02252 for ; Mon, 1 Mar 2004 03:35:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axisq-0000uD-LF for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 03:34:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i218YeKZ003475 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 03:34:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axisq-0000ty-43 for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 03:34:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02227 for ; Mon, 1 Mar 2004 03:34:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axisn-0006K9-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 03:34:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axirw-0006ES-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 03:33:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxirI-00068D-00; Mon, 01 Mar 2004 03:33:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxirF-0000kv-P8; Mon, 01 Mar 2004 03:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axiqp-0000ji-Dz for idr@optimus.ietf.org; Mon, 01 Mar 2004 03:32:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02097 for ; Mon, 1 Mar 2004 03:32:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axiqn-00066Z-00 for idr@ietf.org; Mon, 01 Mar 2004 03:32:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axiq0-00061o-00 for idr@ietf.org; Mon, 01 Mar 2004 03:31:45 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=kummer.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AxipM-0005rb-00 for idr@ietf.org; Mon, 01 Mar 2004 03:31:04 -0500 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id i218UZPg027790 for ; Mon, 1 Mar 2004 00:30:35 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id i218UZLn027787 for ; Mon, 1 Mar 2004 00:30:35 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs From: Kireeti Kompella To: idr@ietf.org Message-ID: <20040301001457.L27706@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Idr] BGP-based VPLS Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 00:30:35 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Following up on the discussion regarding BGP for L2VPN auto-discovery, draft-ietf-l2vpn-vpls-bgp-01.txt does auto-discovery and signaling for VPLS. Of special interest to this WG is section 3, where the NLRI format for this AFI/SAFI (*) pair, and other topics are described. (*) SAFI = 65; AFI not yet allocated. It seems sensible to use the AFI allocated for auto-discovery. Kireeti. ------- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 05:31:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07996 for ; Mon, 1 Mar 2004 05:31:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axki4-0002dR-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 05:31:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxkhF-0002Xj-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 05:30:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axkga-0002RP-00; Mon, 01 Mar 2004 05:30:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxkgT-0002SV-J5; Mon, 01 Mar 2004 05:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axkg2-0002Mz-KX for idr@optimus.ietf.org; Mon, 01 Mar 2004 05:29:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07865 for ; Mon, 1 Mar 2004 05:29:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axkfz-0002PK-00 for idr@ietf.org; Mon, 01 Mar 2004 05:29:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axkf2-0002KA-00 for idr@ietf.org; Mon, 01 Mar 2004 05:28:33 -0500 Received: from web25210.mail.ukl.yahoo.com ([217.12.10.70]) by ietf-mx with smtp (Exim 4.12) id 1AxkeG-0002AU-00 for idr@ietf.org; Mon, 01 Mar 2004 05:27:44 -0500 Message-ID: <20040301102712.85640.qmail@web25210.mail.ukl.yahoo.com> Received: from [67.170.234.128] by web25210.mail.ukl.yahoo.com via HTTP; Mon, 01 Mar 2004 10:27:12 GMT From: =?iso-8859-1?q?BGP=20Guru?= Subject: Re: [Idr] Question on MinASOrig Timer To: curtis@fictitious.org, Pedro Roque Marques Cc: idr@ietf.org In-Reply-To: <200402270722.i1R7MvRX031806@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 10:27:12 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit --- Curtis Villamizar wrote: > > In message > <200402270650.i1R6oBuU039747@roque-bsd.juniper.net>, > Pedro Roque Mar > ques writes: > > Curtis Villamizar writes: > > > > > If withdraws propogate faster first the > unfeasible AS paths are > > > removed, then the feasible ones start > propogating. The result is > > > some withdraw followed by add but much less AS > path change in the > > > presence of cycles. > > > > The point in which we differ is that you equate > withdraws and updates > > w/ unfeasible and feasible paths. I don't believe > one can make that > > assumption. > > > > For a given AS, if you have as input an withdraw > that can result in an > > update being generated or vice-versa, depending on > the policy. > > > > You can have a link up event result in withdrawns > being generated, and > > a link down event result in updates. In other > words the addition of > > feasible paths, can result via policy, in > withdrawls. > > > > > Providing separate timers allows us to defer the > question of which > > > is preferable. > > > > Providing separate timers, imho, will just further > confuse the issue > > :-). It has already been showen that there is no > single choice of MRAI > > timer that is appropriate for all situations. Now > you propose an > > additional one. That is two parameters nobody > knows what the optimal > > setting should be. > > > > Furthermore, i believe that, due to the meshed > nature of internet > > connectivity, using different delays may increase > the duration of > > transients. > > > > Lets say that you start w/ a current path through > as3 and > > you have a link up event (a) that brings up a > prefered path. > > > > as 3 > > | > > --a-> as 1 --> as 4 > > > > --a-> as 2 --> as 4 > > > > If a is a peer route for as 1 but a customer route > for as 2, then by > > propagating the withdrawl faster you are > increasing the transient time > > and causing increase connectivity to create a > blackhole for as4. > > > > imho, currently there is only one good known value > for MRAI for both > > updates and withdrawls, and that is 0. Let BGP > speakers propagate > > updates as fast as they can, taking into account > that BGP itself > > already has embedded flow control mechanisms that > allow a receiver to > > pace a sender appropriatly. > > > > Unfortunatly, even that setting (0) has its > drawbacks. One is that > > values should probably be consistent within an as, > and there are very > > different interpretations of MRAI between > different vendors. The > > second is that in case of MED oscillations, MRAI > helps reduce the > > ammount of churn. > > > > regards, > > Pedro. > > > Pedro, > > If you have separate timers for route > origination/advertisement and > up/down and the best solution is to set them all the > same then it is > possible to set them all the same. > > If you specify that they must be the same and that > doesn't turn out to > be the best way to do things you are stuck. > > Its clear that there isn't agreement on the best > solution, so for the > time being flexibility is needed. > As everyone may know, Cisco SWs have the same MRAI of 30sec for both Advertised as well as Withdrawn NLRIs since IOS 12S and ISPs, including our NWs in Asia, dont seem to be having issues with this. I guess Juniper's implementation is the same, need to check (JUNOS guys please pitch in). IMO, the default configuration on the SWs should be good enough and capable of handling over 95% of deployment senarios. ISPs would like to play with knobs as little as possible on live NWs. 30sec is a good approx of transient link flaps and time-staggered Withdrawals do reduce traffic on the wire due to transient flaps. One would be more worried about loosing 150-200 peerings due to excessive control traffic rather than a few data-flows being black-holed for a few seconds. Hence it would be better to keep the MRAI/MAOI for withdrawals as well. One comment here, Cisco's 5sec MAOI seems far to frequent - desirable would be 15sec atleast. Also, I think per-peer MRAI/MAOI timers are a bit too excessive. I shudder at the thought that a Route-reflector/route-collector with 500 peerings will have 500 timers popping every 5secs. Is this standard and common-practise in implementations or can this be bettered? ___________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 05:32:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08028 for ; Mon, 1 Mar 2004 05:32:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axki8-0002gc-SO for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 05:31:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21AVimZ010325 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 05:31:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axki8-0002gS-Mo for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 05:31:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08014 for ; Mon, 1 Mar 2004 05:31:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axki5-0002dW-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 05:31:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxkhG-0002Xq-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 05:30:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axkga-0002RP-00; Mon, 01 Mar 2004 05:30:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxkgT-0002SV-J5; Mon, 01 Mar 2004 05:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axkg2-0002Mz-KX for idr@optimus.ietf.org; Mon, 01 Mar 2004 05:29:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07865 for ; Mon, 1 Mar 2004 05:29:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axkfz-0002PK-00 for idr@ietf.org; Mon, 01 Mar 2004 05:29:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axkf2-0002KA-00 for idr@ietf.org; Mon, 01 Mar 2004 05:28:33 -0500 Received: from web25210.mail.ukl.yahoo.com ([217.12.10.70]) by ietf-mx with smtp (Exim 4.12) id 1AxkeG-0002AU-00 for idr@ietf.org; Mon, 01 Mar 2004 05:27:44 -0500 Message-ID: <20040301102712.85640.qmail@web25210.mail.ukl.yahoo.com> Received: from [67.170.234.128] by web25210.mail.ukl.yahoo.com via HTTP; Mon, 01 Mar 2004 10:27:12 GMT From: =?iso-8859-1?q?BGP=20Guru?= Subject: Re: [Idr] Question on MinASOrig Timer To: curtis@fictitious.org, Pedro Roque Marques Cc: idr@ietf.org In-Reply-To: <200402270722.i1R7MvRX031806@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 10:27:12 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit --- Curtis Villamizar wrote: > > In message > <200402270650.i1R6oBuU039747@roque-bsd.juniper.net>, > Pedro Roque Mar > ques writes: > > Curtis Villamizar writes: > > > > > If withdraws propogate faster first the > unfeasible AS paths are > > > removed, then the feasible ones start > propogating. The result is > > > some withdraw followed by add but much less AS > path change in the > > > presence of cycles. > > > > The point in which we differ is that you equate > withdraws and updates > > w/ unfeasible and feasible paths. I don't believe > one can make that > > assumption. > > > > For a given AS, if you have as input an withdraw > that can result in an > > update being generated or vice-versa, depending on > the policy. > > > > You can have a link up event result in withdrawns > being generated, and > > a link down event result in updates. In other > words the addition of > > feasible paths, can result via policy, in > withdrawls. > > > > > Providing separate timers allows us to defer the > question of which > > > is preferable. > > > > Providing separate timers, imho, will just further > confuse the issue > > :-). It has already been showen that there is no > single choice of MRAI > > timer that is appropriate for all situations. Now > you propose an > > additional one. That is two parameters nobody > knows what the optimal > > setting should be. > > > > Furthermore, i believe that, due to the meshed > nature of internet > > connectivity, using different delays may increase > the duration of > > transients. > > > > Lets say that you start w/ a current path through > as3 and > > you have a link up event (a) that brings up a > prefered path. > > > > as 3 > > | > > --a-> as 1 --> as 4 > > > > --a-> as 2 --> as 4 > > > > If a is a peer route for as 1 but a customer route > for as 2, then by > > propagating the withdrawl faster you are > increasing the transient time > > and causing increase connectivity to create a > blackhole for as4. > > > > imho, currently there is only one good known value > for MRAI for both > > updates and withdrawls, and that is 0. Let BGP > speakers propagate > > updates as fast as they can, taking into account > that BGP itself > > already has embedded flow control mechanisms that > allow a receiver to > > pace a sender appropriatly. > > > > Unfortunatly, even that setting (0) has its > drawbacks. One is that > > values should probably be consistent within an as, > and there are very > > different interpretations of MRAI between > different vendors. The > > second is that in case of MED oscillations, MRAI > helps reduce the > > ammount of churn. > > > > regards, > > Pedro. > > > Pedro, > > If you have separate timers for route > origination/advertisement and > up/down and the best solution is to set them all the > same then it is > possible to set them all the same. > > If you specify that they must be the same and that > doesn't turn out to > be the best way to do things you are stuck. > > Its clear that there isn't agreement on the best > solution, so for the > time being flexibility is needed. > As everyone may know, Cisco SWs have the same MRAI of 30sec for both Advertised as well as Withdrawn NLRIs since IOS 12S and ISPs, including our NWs in Asia, dont seem to be having issues with this. I guess Juniper's implementation is the same, need to check (JUNOS guys please pitch in). IMO, the default configuration on the SWs should be good enough and capable of handling over 95% of deployment senarios. ISPs would like to play with knobs as little as possible on live NWs. 30sec is a good approx of transient link flaps and time-staggered Withdrawals do reduce traffic on the wire due to transient flaps. One would be more worried about loosing 150-200 peerings due to excessive control traffic rather than a few data-flows being black-holed for a few seconds. Hence it would be better to keep the MRAI/MAOI for withdrawals as well. One comment here, Cisco's 5sec MAOI seems far to frequent - desirable would be 15sec atleast. Also, I think per-peer MRAI/MAOI timers are a bit too excessive. I shudder at the thought that a Route-reflector/route-collector with 500 peerings will have 500 timers popping every 5secs. Is this standard and common-practise in implementations or can this be bettered? ___________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 09:32:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25536 for ; Mon, 1 Mar 2004 09:32:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxoSR-0006Mu-BN for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 09:31:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21EVliS024474 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 09:31:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxoSR-0006Mf-6h for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 09:31:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25381 for ; Mon, 1 Mar 2004 09:31:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxoSP-0002OP-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 09:31:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxoF1-0006eM-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 09:17:59 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Axo2t-0003c4-02 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 09:05:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Axo2n-0007z1-I0 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 09:05:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axo2k-0004ad-QW for idr-web-archive@ietf.org; Mon, 01 Mar 2004 09:05:14 -0500 Date: Mon, 01 Mar 2004 09:05:14 -0500 Message-ID: <20040301140514.27462.28213.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: idr-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, idr-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for idr-web-archive@ietf.org: List Password // URL ---- -------- idr@ietf.org ginaip https://www1.ietf.org/mailman/options/idr/idr-web-archive%40ietf.org From mailman-admin@ietf.org Mon Mar 1 11:44:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19490 for ; Mon, 1 Mar 2004 11:42:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxpRL-0001xn-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 10:34:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxoyT-0002K5-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 10:04:55 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AxoYL-0003lL-01 for idr-archive@ietf.org; Mon, 01 Mar 2004 09:37:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AxoAF-0000gP-L1 for idr-archive@ietf.org; Mon, 01 Mar 2004 09:12:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxoAE-0003nZ-Ez for idr-archive@ietf.org; Mon, 01 Mar 2004 09:12:58 -0500 Date: Mon, 01 Mar 2004 09:12:58 -0500 Message-ID: <20040301141258.27462.32098.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: idr-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, idr-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for idr-archive@ietf.org: List Password // URL ---- -------- idr@ietf.org omkeeh https://www1.ietf.org/mailman/options/idr/idr-archive%40ietf.org From idr-admin@ietf.org Mon Mar 1 13:00:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25004 for ; Mon, 1 Mar 2004 13:00:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxriD-0002iK-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 13:00:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxrhB-0002Wh-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 12:59:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxrgG-0002LO-00; Mon, 01 Mar 2004 12:58:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axrg1-0005GQ-OX; Mon, 01 Mar 2004 12:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axrf7-0005EH-14 for idr@optimus.ietf.org; Mon, 01 Mar 2004 12:57:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24730 for ; Mon, 1 Mar 2004 12:57:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axrf5-0002AL-00 for idr@ietf.org; Mon, 01 Mar 2004 12:57:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxreG-00022W-00 for idr@ietf.org; Mon, 01 Mar 2004 12:56:12 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AxrdA-0001o3-00 for idr@ietf.org; Mon, 01 Mar 2004 12:55:04 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i21HsY1K049306; Mon, 1 Mar 2004 09:54:34 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i21HsYHi049303; Mon, 1 Mar 2004 09:54:34 -0800 (PST) Message-Id: <200403011754.i21HsYHi049303@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Yakov Rekhter Cc: idr@ietf.org Subject: Re: [Idr] Question on MinASOrig Timer In-Reply-To: <200402290009.i1T09Oo29392@merlot.juniper.net> References: <200402270722.i1R7MvRX031806@workhorse.fictitious.org> <200402290009.i1T09Oo29392@merlot.juniper.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 09:54:34 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Yakov Rekhter writes: > Curtis, [clipped...] >> Pedro, >> >> If you have separate timers for route origination/advertisement and >> up/down and the best solution is to set them all the same then it >> is possible to set them all the same. >> >> If you specify that they must be the same and that doesn't turn out >> to be the best way to do things you are stuck. >> >> Its clear that there isn't agreement on the best solution, so for >> the time being flexibility is needed. > One point to keep in mind is that since we are moving the spec to a > Draft Standard, a *necessary* condition for relaxing the spec to > support the flexibility you mentioned above would be more than one > implementation that supports such flexibility. Just for the record... Regardless of the ietf process I'm opposed to modifying the spec. imho, the propagating withdrawls faster than updates is detrimental in a significant number of realistic scenarios. Also, it doesn't seem to me that the proponents of such change have considered the potential drawbacks that are inherent to any change in behaviour. Implementations are always free to and expected to have functionality that is beyond what the standard specifies. Curtis can still add the flexibility he believes necessary... while other implementors can make their own judgement based on what they consider the best interest of their users. This is also not by far the most confusing aspect regarding interoperability in MRAI. I belive the WG as decided previously that we agree not to agree on MRAI. But if we are going to discuss the topic then we should discuss not what timer values but what do the timer values mean exactly. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 13:00:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25070 for ; Mon, 1 Mar 2004 13:00:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxriF-0005oH-UJ for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 13:00:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21I0JlU022327 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 13:00:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxriF-0005o2-Ks for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 13:00:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25017 for ; Mon, 1 Mar 2004 13:00:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxriD-0002iQ-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 13:00:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxrhC-0002Wp-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 12:59:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxrgG-0002LO-00; Mon, 01 Mar 2004 12:58:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axrg1-0005GQ-OX; Mon, 01 Mar 2004 12:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axrf7-0005EH-14 for idr@optimus.ietf.org; Mon, 01 Mar 2004 12:57:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24730 for ; Mon, 1 Mar 2004 12:57:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axrf5-0002AL-00 for idr@ietf.org; Mon, 01 Mar 2004 12:57:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxreG-00022W-00 for idr@ietf.org; Mon, 01 Mar 2004 12:56:12 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AxrdA-0001o3-00 for idr@ietf.org; Mon, 01 Mar 2004 12:55:04 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i21HsY1K049306; Mon, 1 Mar 2004 09:54:34 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i21HsYHi049303; Mon, 1 Mar 2004 09:54:34 -0800 (PST) Message-Id: <200403011754.i21HsYHi049303@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Yakov Rekhter Cc: idr@ietf.org Subject: Re: [Idr] Question on MinASOrig Timer In-Reply-To: <200402290009.i1T09Oo29392@merlot.juniper.net> References: <200402270722.i1R7MvRX031806@workhorse.fictitious.org> <200402290009.i1T09Oo29392@merlot.juniper.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 09:54:34 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yakov Rekhter writes: > Curtis, [clipped...] >> Pedro, >> >> If you have separate timers for route origination/advertisement and >> up/down and the best solution is to set them all the same then it >> is possible to set them all the same. >> >> If you specify that they must be the same and that doesn't turn out >> to be the best way to do things you are stuck. >> >> Its clear that there isn't agreement on the best solution, so for >> the time being flexibility is needed. > One point to keep in mind is that since we are moving the spec to a > Draft Standard, a *necessary* condition for relaxing the spec to > support the flexibility you mentioned above would be more than one > implementation that supports such flexibility. Just for the record... Regardless of the ietf process I'm opposed to modifying the spec. imho, the propagating withdrawls faster than updates is detrimental in a significant number of realistic scenarios. Also, it doesn't seem to me that the proponents of such change have considered the potential drawbacks that are inherent to any change in behaviour. Implementations are always free to and expected to have functionality that is beyond what the standard specifies. Curtis can still add the flexibility he believes necessary... while other implementors can make their own judgement based on what they consider the best interest of their users. This is also not by far the most confusing aspect regarding interoperability in MRAI. I belive the WG as decided previously that we agree not to agree on MRAI. But if we are going to discuss the topic then we should discuss not what timer values but what do the timer values mean exactly. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 13:16:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26298 for ; Mon, 1 Mar 2004 13:16:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxryO-00055G-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 13:17:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxrxT-0004xR-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 13:16:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axrwb-0004pm-00; Mon, 01 Mar 2004 13:15:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrwV-0006qj-2V; Mon, 01 Mar 2004 13:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrwK-0006qC-GK for idr@optimus.ietf.org; Mon, 01 Mar 2004 13:14:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26168 for ; Mon, 1 Mar 2004 13:14:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxrwI-0004ni-00 for idr@ietf.org; Mon, 01 Mar 2004 13:14:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxrvJ-0004gq-00 for idr@ietf.org; Mon, 01 Mar 2004 13:13:50 -0500 Received: from colossus.systems.pipex.net ([62.241.160.73]) by ietf-mx with esmtp (Exim 4.12) id 1AxruP-0004V7-00 for idr@ietf.org; Mon, 01 Mar 2004 13:12:53 -0500 Received: from tom3 (1Cust2.tnt15.lnd4.gbr.da.uu.net [62.188.144.2]) by colossus.systems.pipex.net (Postfix) with SMTP id A1FE51C00158; Mon, 1 Mar 2004 18:12:19 +0000 (GMT) Message-ID: <00b101c3ffb8$89bdf9a0$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Pekka Savola" , "idr" Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 18:10:44 -0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit It's a fair point but sounds more like draft-ietf-idr-bgp4-experience-protocol-03.txt than draft-ietf-idr-bgp4-23.txt Tom Petch -----Original Message----- From: Pekka Savola To: idr@ietf.org Date: 29 February 2004 06:24 Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes >After some off-list iteration, a revamped version of the possible text >could be: > >In certain common deployment scenarios, the next-hop addresses are >supposed to be valid only if resolved via routes of a specific type >(e.g., IGP, connected or local). There are likely less specific >routes from other sources (e.g., static or BGP) which may resolve the >next-hops as well, but such resolvability typically leads to problems >when the less specific route actually can't be used to reach the >next-hop, and the BGP routes are not invalidated even though their >next-hop is, for all intents and purposes, unroutable. Therefore, it >is advisable that the implementations allow the operator to specify >which routes should yield a positive result if they covered the the >next-hop. > >.. thoughts? This doesn't have any MAY/SHOULD etc. terminology, at >least yet -- maybe it should. > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 13:17:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26338 for ; Mon, 1 Mar 2004 13:17:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxryR-00073K-NZ for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 13:17:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21IH3RB027109 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 13:17:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxryR-00073A-J5 for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 13:17:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26316 for ; Mon, 1 Mar 2004 13:17:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxryP-00055O-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 13:17:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxrxU-0004xY-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 13:16:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axrwb-0004pm-00; Mon, 01 Mar 2004 13:15:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrwV-0006qj-2V; Mon, 01 Mar 2004 13:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrwK-0006qC-GK for idr@optimus.ietf.org; Mon, 01 Mar 2004 13:14:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26168 for ; Mon, 1 Mar 2004 13:14:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxrwI-0004ni-00 for idr@ietf.org; Mon, 01 Mar 2004 13:14:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxrvJ-0004gq-00 for idr@ietf.org; Mon, 01 Mar 2004 13:13:50 -0500 Received: from colossus.systems.pipex.net ([62.241.160.73]) by ietf-mx with esmtp (Exim 4.12) id 1AxruP-0004V7-00 for idr@ietf.org; Mon, 01 Mar 2004 13:12:53 -0500 Received: from tom3 (1Cust2.tnt15.lnd4.gbr.da.uu.net [62.188.144.2]) by colossus.systems.pipex.net (Postfix) with SMTP id A1FE51C00158; Mon, 1 Mar 2004 18:12:19 +0000 (GMT) Message-ID: <00b101c3ffb8$89bdf9a0$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Pekka Savola" , "idr" Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 18:10:44 -0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It's a fair point but sounds more like draft-ietf-idr-bgp4-experience-protocol-03.txt than draft-ietf-idr-bgp4-23.txt Tom Petch -----Original Message----- From: Pekka Savola To: idr@ietf.org Date: 29 February 2004 06:24 Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes >After some off-list iteration, a revamped version of the possible text >could be: > >In certain common deployment scenarios, the next-hop addresses are >supposed to be valid only if resolved via routes of a specific type >(e.g., IGP, connected or local). There are likely less specific >routes from other sources (e.g., static or BGP) which may resolve the >next-hops as well, but such resolvability typically leads to problems >when the less specific route actually can't be used to reach the >next-hop, and the BGP routes are not invalidated even though their >next-hop is, for all intents and purposes, unroutable. Therefore, it >is advisable that the implementations allow the operator to specify >which routes should yield a positive result if they covered the the >next-hop. > >.. thoughts? This doesn't have any MAY/SHOULD etc. terminology, at >least yet -- maybe it should. > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 13:56:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27706 for ; Mon, 1 Mar 2004 13:56:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxsaG-0001TH-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 13:56:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxsZD-0001Ke-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 13:55:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxsYL-0001Df-00; Mon, 01 Mar 2004 13:54:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxsYD-0000NX-O5; Mon, 01 Mar 2004 13:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxsY5-0000N4-6V for idr@optimus.ietf.org; Mon, 01 Mar 2004 13:53:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27583 for ; Mon, 1 Mar 2004 13:53:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxsY2-0001Av-00 for idr@ietf.org; Mon, 01 Mar 2004 13:53:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxsX5-00013c-00 for idr@ietf.org; Mon, 01 Mar 2004 13:52:51 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AxsW9-0000sM-00 for idr@ietf.org; Mon, 01 Mar 2004 13:51:53 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i21IpN1K049437; Mon, 1 Mar 2004 10:51:23 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i21IpNKd049434; Mon, 1 Mar 2004 10:51:23 -0800 (PST) Message-Id: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pekka Savola Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 10:51:23 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Pekka Savola writes: > What I'm arguing here that there seem to be very clear operational > reasons why the "BGP route must be used for forwarding" is very > counterproductive and we should fix/clarify the spec to have a more > useful definition for it. > Are there any killer arguments why this is *NOT* a good idea? What is the #1 goal of BGP ? The establishment of *loop free* paths between autonomous systems. How can you guarantee loop free properties ? via the as-path loop detection mechanism... This means that you can only gurantee no forwarding loops if traffic always follows routing. So advertising routes that are not used for forwarding breaks the BGP algorithm. And it means that you can no longer prove of trust the loop free property. But there are more mundane practical consequences: outside | | ----------- a --- b as x | | A and B are border gateways for a stub as (x). Both are configured to originate a given prefix 10.0.1/24 whenever that prefix is reachable throught its IGP. Additionally, they are configured w/ a discard route to 10.0.1/24, which discard traffic whenever the IGP route is not present. In case of failure, one likely gets one of the exit points w/ a discard route as its forwarding state, while the other exit point has a valid IGP route. If the gateway that has a discard route in the forwarding table does advertise the route from its peer gateway it will cause traffic to be dropped. Generalizing: - whenever BGP advertises a route that it doesn't use for forwarding, traffic can easily end up getting dropped. Would there be a kind soul that volunteers to keep a FAQ of this WG list ? That way we wouldn't need to rehash this discussion and the MRAI discussion every 6 months. Please file under: "Issues the WG as agreed not to agree". Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 13:56:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27742 for ; Mon, 1 Mar 2004 13:56:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxsaK-0000Y9-5W for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 13:56:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21IuCPE002107 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 13:56:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxsaK-0000Xu-1G for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 13:56:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27724 for ; Mon, 1 Mar 2004 13:56:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxsaH-0001TM-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 13:56:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxsZE-0001Kl-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 13:55:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxsYL-0001Df-00; Mon, 01 Mar 2004 13:54:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxsYD-0000NX-O5; Mon, 01 Mar 2004 13:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxsY5-0000N4-6V for idr@optimus.ietf.org; Mon, 01 Mar 2004 13:53:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27583 for ; Mon, 1 Mar 2004 13:53:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxsY2-0001Av-00 for idr@ietf.org; Mon, 01 Mar 2004 13:53:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxsX5-00013c-00 for idr@ietf.org; Mon, 01 Mar 2004 13:52:51 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AxsW9-0000sM-00 for idr@ietf.org; Mon, 01 Mar 2004 13:51:53 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i21IpN1K049437; Mon, 1 Mar 2004 10:51:23 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i21IpNKd049434; Mon, 1 Mar 2004 10:51:23 -0800 (PST) Message-Id: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pekka Savola Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 10:51:23 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola writes: > What I'm arguing here that there seem to be very clear operational > reasons why the "BGP route must be used for forwarding" is very > counterproductive and we should fix/clarify the spec to have a more > useful definition for it. > Are there any killer arguments why this is *NOT* a good idea? What is the #1 goal of BGP ? The establishment of *loop free* paths between autonomous systems. How can you guarantee loop free properties ? via the as-path loop detection mechanism... This means that you can only gurantee no forwarding loops if traffic always follows routing. So advertising routes that are not used for forwarding breaks the BGP algorithm. And it means that you can no longer prove of trust the loop free property. But there are more mundane practical consequences: outside | | ----------- a --- b as x | | A and B are border gateways for a stub as (x). Both are configured to originate a given prefix 10.0.1/24 whenever that prefix is reachable throught its IGP. Additionally, they are configured w/ a discard route to 10.0.1/24, which discard traffic whenever the IGP route is not present. In case of failure, one likely gets one of the exit points w/ a discard route as its forwarding state, while the other exit point has a valid IGP route. If the gateway that has a discard route in the forwarding table does advertise the route from its peer gateway it will cause traffic to be dropped. Generalizing: - whenever BGP advertises a route that it doesn't use for forwarding, traffic can easily end up getting dropped. Would there be a kind soul that volunteers to keep a FAQ of this WG list ? That way we wouldn't need to rehash this discussion and the MRAI discussion every 6 months. Please file under: "Issues the WG as agreed not to agree". Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 14:12:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28499 for ; Mon, 1 Mar 2004 14:12:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axspp-0003Kc-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 14:12:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axsov-0003CH-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 14:11:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxsoD-000343-00; Mon, 01 Mar 2004 14:10:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axsnj-0001SH-LX; Mon, 01 Mar 2004 14:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxsnX-0001RE-P6 for idr@optimus.ietf.org; Mon, 01 Mar 2004 14:09:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28386 for ; Mon, 1 Mar 2004 14:09:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxsnV-00030u-00 for idr@ietf.org; Mon, 01 Mar 2004 14:09:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxsmW-0002tA-00 for idr@ietf.org; Mon, 01 Mar 2004 14:08:49 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AxslZ-0002jC-00 for idr@ietf.org; Mon, 01 Mar 2004 14:07:49 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id CDF592D485B for ; Mon, 1 Mar 2004 14:07:12 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 34976-02-70 for ; Mon, 1 Mar 2004 14:07:11 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 23BE72D480C for ; Mon, 1 Mar 2004 14:07:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] FW: Here's the bundle for BGP to go to the IESG Message-ID: Thread-Topic: [Idr] FW: Here's the bundle for BGP to go to the IESG Thread-Index: AcP/RALSuN2jxTbUTESqu57qiw7g9QAFsoow From: "Susan Hares" To: "Alex Zinin" Cc: X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 14:07:10 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-mibagent-survey-00= .txt We'll make sure the -00.txt , -01.txt gets loaded next week. Sue -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Sunday, February 29, 2004 11:16 PM To: Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] FW: Here's the bundle for BGP to go to the IESG For information, the following two documents are not in the IETF draft repository-- > 6) BGP 4 Implementation Report = draft-ietf-idr-bgp-implementation-00.txt > 7) BGP-4 V1 MIB implementation report = draft-ietf-idr-bgp-mibagent-survey-01.txt --we'll have to wait until they are available before we can put them in = the bundle and start the IETF LC on the whole group. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 14:12:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28528 for ; Mon, 1 Mar 2004 14:12:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axspt-0001l4-8e for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 14:12:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21JCHpY006752 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 14:12:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axsps-0001kp-UL for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 14:12:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28516 for ; Mon, 1 Mar 2004 14:12:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axspq-0003Kj-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 14:12:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axsov-0003CO-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 14:11:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxsoD-000343-00; Mon, 01 Mar 2004 14:10:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axsnj-0001SH-LX; Mon, 01 Mar 2004 14:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxsnX-0001RE-P6 for idr@optimus.ietf.org; Mon, 01 Mar 2004 14:09:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28386 for ; Mon, 1 Mar 2004 14:09:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxsnV-00030u-00 for idr@ietf.org; Mon, 01 Mar 2004 14:09:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxsmW-0002tA-00 for idr@ietf.org; Mon, 01 Mar 2004 14:08:49 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AxslZ-0002jC-00 for idr@ietf.org; Mon, 01 Mar 2004 14:07:49 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id CDF592D485B for ; Mon, 1 Mar 2004 14:07:12 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 34976-02-70 for ; Mon, 1 Mar 2004 14:07:11 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 23BE72D480C for ; Mon, 1 Mar 2004 14:07:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] FW: Here's the bundle for BGP to go to the IESG Message-ID: Thread-Topic: [Idr] FW: Here's the bundle for BGP to go to the IESG Thread-Index: AcP/RALSuN2jxTbUTESqu57qiw7g9QAFsoow From: "Susan Hares" To: "Alex Zinin" Cc: X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 14:07:10 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-mibagent-survey-00= .txt We'll make sure the -00.txt , -01.txt gets loaded next week. Sue -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Sunday, February 29, 2004 11:16 PM To: Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] FW: Here's the bundle for BGP to go to the IESG For information, the following two documents are not in the IETF draft repository-- > 6) BGP 4 Implementation Report = draft-ietf-idr-bgp-implementation-00.txt > 7) BGP-4 V1 MIB implementation report = draft-ietf-idr-bgp-mibagent-survey-01.txt --we'll have to wait until they are available before we can put them in = the bundle and start the IETF LC on the whole group. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 14:28:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29127 for ; Mon, 1 Mar 2004 14:28:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axt5w-00057b-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 14:28:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axt53-0004zs-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 14:27:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axt4L-0004uN-00; Mon, 01 Mar 2004 14:27:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt4B-0002CX-V2; Mon, 01 Mar 2004 14:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrLb-0003iz-54 for idr@optimus.ietf.org; Mon, 01 Mar 2004 12:36:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23951 for ; Mon, 1 Mar 2004 12:36:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxrLZ-0007Xx-00 for idr@ietf.org; Mon, 01 Mar 2004 12:36:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxrKi-0007Rh-00 for idr@ietf.org; Mon, 01 Mar 2004 12:36:01 -0500 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1AxrJz-0007IO-00 for idr@ietf.org; Mon, 01 Mar 2004 12:35:15 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HTW000BIR4ZDN@firewall.mci.com> for idr@ietf.org; Mon, 01 Mar 2004 17:26:59 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HTW00H01R3WSD@pmismtp01.mcilink.com>; Mon, 01 Mar 2004 17:26:59 +0000 (GMT) Received: from WS344V8066292 ([153.39.146.200]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HTW00HJLR2FBP@pmismtp01.mcilink.com>; Mon, 01 Mar 2004 17:25:27 +0000 (GMT) From: Parantap Lahiri Subject: RE: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: <200403011646.i21Gk6RX072941@workhorse.fictitious.org> To: curtis@fictitious.org Cc: "'Pekka Savola'" , "'John G. Scudder'" , idr@ietf.org Message-id: <01c101c3ffb2$300c2630$c8922799@mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 12:25:27 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable If you aggregate the prefixes just towards EBGP neighbors it definitely = does solve the problem, but the issue is you will have to touch all your ebgp sessions once you get a new block to aggregate. Operator motto is have a design which requires least touching. Of course that can be equated to laziness, but it depends on which side of fence you are on. >This isn't a problem with the BGP protocol. Its a problem with the >way some providers configure their networks (incorrectly) that is >easily solved by not doing it that way, or can be solved by adding a >config knob to the router to exclude aggregates from this AS from >consideration in the reachability test or exclude specific prefixes. >This is certainly something that can be addressed in a separate >document. This is exactly what I suggested in the 2nd paragraph of my original = mail. -----Original Message----- From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]=20 Sent: Monday, March 01, 2004 11:46 AM To: Parantap Lahiri Cc: curtis@fictitious.org; 'Pekka Savola'; 'John G. Scudder'; = idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In message <019f01c3ffa2$81715960$c8922799@mcilink.com>, Parantap Lahiri writes : > Curtis, >=20 > I was referring to a complete separate address space for the secondary > loopbacks and the idea was not to aggregate that space. It would be = only in > IGP as discrete /32s, and if the node is gone, the /32 will be gone, = thus > immediately invalidating the routes originated by it. The rest of the world > could still reach the box using the primary loopback address, which = would be > aggregated and would be in BGP.=20 >=20 > Anyway, my initial message was delayed by the moderator and I found = John > Scudder referring to this option in one of his later mails. So I think = its > covered.=20 >=20 > -Parantap =20 The way we did this when I was doing operations was we aggregated and sent the aggregate to EBGP peers. Since we didn't have the aggregate for our own address allocation within our AS this never came up. This also was not a problem because the loopback by definition cannot become unreachable, only interface addresses can become unreachable. IBGP peers should be announcing their loopback, which can never go down unless the router becomes completely unreachable. If the provider's aggregate is only sent outside the AS, then this is fine. I personally felt as an operator that if another provider is to *lazy* to configure the aggregate statement on each EBGP peer, and instead chooses to announce that aggreate into IBGP, then they get what they deserve. Working for a vendor now, I have to take the position that the customer can be as arbitrarily lazy as they like and thats just fine. This isn't a problem with the BGP protocol. Its a problem with the way some providers configure their networks (incorrectly) that is easily solved by not doing it that way, or can be solved by adding a config knob to the router to exclude aggreates from this AS from consideration in the reachability test or exclude specific prefixes. This is certainly something that can be addressed in a separate document. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 14:28:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29151 for ; Mon, 1 Mar 2004 14:28:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axt61-00058T-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 14:28:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axt56-00050O-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 14:28:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axt4N-0004uQ-00; Mon, 01 Mar 2004 14:27:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt4A-0002AL-AG; Mon, 01 Mar 2004 14:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqDH-0005VG-1O for idr@optimus.ietf.org; Mon, 01 Mar 2004 11:24:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16108 for ; Mon, 1 Mar 2004 11:24:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxqAr-0001qm-00 for idr@ietf.org; Mon, 01 Mar 2004 11:21:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axq9r-0001Lm-00 for idr@ietf.org; Mon, 01 Mar 2004 11:20:44 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1Axq8t-0001Ep-00 for idr@ietf.org; Mon, 01 Mar 2004 11:19:44 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i21GIVRX072804; Mon, 1 Mar 2004 11:18:31 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403011618.i21GIVRX072804@workhorse.fictitious.org> To: Alex Zinin cc: idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] Comments on draft-chen-bgp-redist-00.txt In-reply-to: Your message of "Mon, 01 Mar 2004 17:12:51 +0900." <5734391782.20040301171251@psg.com> From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 11:18:31 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <5734391782.20040301171251@psg.com>, Alex Zinin writes: > Comments I brought up today: > > 1. The problem appears because there are two points within the router where > two routes are compared. The draft suggests that the BGP path selection > process is made consistent with the selection process in the routing > table (AdminDist-based). > > The question is whether the problem statement is applicable for the > implementations where BGP path selection and AD comparison happens > at the same time (from what I remember, gated did that). In other words, > the question is whether the problem is implementations specific or not, > and hence whether a change to the protocol is appropriate. > > 2. Suggestion: seems that the problem can be solved without changing the > best path selection process. > > The idea is to establish a 1:1 mapping between LOCAL_RPEF and AD, i.e. ta > ke > the AD value and use it as LOCAL_PREF value when importing (redistributin > g) > routes to BGP, and use the LOCAL_PREF value as the AD when installing rou > tes > in the routing table. The advantage is it automagically makes the route > selection decisions consistent not only within a single router, but > throughout the iBGP mesh too. > > Food for thoughts... > > -- > Alex > http://www.psg.com/~zinin/ Sounds like this could go in a follow up internet-draft. It is outside of BGP itself. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 14:28:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29178 for ; Mon, 1 Mar 2004 14:28:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axt63-00058l-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 14:28:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axt57-00050f-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 14:28:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axt4N-0004uV-00; Mon, 01 Mar 2004 14:27:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt4B-0002BZ-66; Mon, 01 Mar 2004 14:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqlR-0000Lx-5q for idr@optimus.ietf.org; Mon, 01 Mar 2004 11:59:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21282 for ; Mon, 1 Mar 2004 11:59:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxqbJ-0000gc-00 for idr@ietf.org; Mon, 01 Mar 2004 11:49:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axqa8-0000QO-00 for idr@ietf.org; Mon, 01 Mar 2004 11:47:53 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AxqZf-0000KR-00 for idr@ietf.org; Mon, 01 Mar 2004 11:47:23 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i21Gk6RX072941; Mon, 1 Mar 2004 11:46:06 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403011646.i21Gk6RX072941@workhorse.fictitious.org> To: Parantap Lahiri cc: curtis@fictitious.org, "'Pekka Savola'" , "'John G. Scudder'" , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: Your message of "Mon, 01 Mar 2004 10:33:11 EST." <019f01c3ffa2$81715960$c8922799@mcilink.com> From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 11:46:06 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <019f01c3ffa2$81715960$c8922799@mcilink.com>, Parantap Lahiri writes : > Curtis, > > I was referring to a complete separate address space for the secondary > loopbacks and the idea was not to aggregate that space. It would be only in > IGP as discrete /32s, and if the node is gone, the /32 will be gone, thus > immediately invalidating the routes originated by it. The rest of the world > could still reach the box using the primary loopback address, which would be > aggregated and would be in BGP. > > Anyway, my initial message was delayed by the moderator and I found John > Scudder referring to this option in one of his later mails. So I think its > covered. > > -Parantap The way we did this when I was doing operations was we aggregated and sent the aggregate to EBGP peers. Since we didn't have the aggregate for our own address allocation within our AS this never came up. This also was not a problem because the loopback by definition cannot become unreachable, only interface addresses can become unreachable. IBGP peers should be announcing their loopback, which can never go down unless the router becomes completely unreachable. If the provider's aggregate is only sent outside the AS, then this is fine. I personally felt as an operator that if another provider is to *lazy* to configure the aggregate statement on each EBGP peer, and instead chooses to announce that aggreate into IBGP, then they get what they deserve. Working for a vendor now, I have to take the position that the customer can be as arbitrarily lazy as they like and thats just fine. This isn't a problem with the BGP protocol. Its a problem with the way some providers configure their networks (incorrectly) that is easily solved by not doing it that way, or can be solved by adding a config knob to the router to exclude aggreates from this AS from consideration in the reachability test or exclude specific prefixes. This is certainly something that can be addressed in a separate document. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 14:29:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29204 for ; Mon, 1 Mar 2004 14:29:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axt66-000594-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 14:29:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axt59-00050w-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 14:28:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axt4N-0004uX-00; Mon, 01 Mar 2004 14:27:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt4C-0002DJ-N1; Mon, 01 Mar 2004 14:27:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxszH-00020v-9t for idr@optimus.ietf.org; Mon, 01 Mar 2004 14:21:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28881 for ; Mon, 1 Mar 2004 14:21:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxszE-0004Lg-00 for idr@ietf.org; Mon, 01 Mar 2004 14:21:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxsyM-0004GK-00 for idr@ietf.org; Mon, 01 Mar 2004 14:21:03 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1Axsxy-0004AU-00 for idr@ietf.org; Mon, 01 Mar 2004 14:20:38 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i21JJORX073772; Mon, 1 Mar 2004 14:19:24 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403011919.i21JJORX073772@workhorse.fictitious.org> To: Pedro Roque Marques cc: Yakov Rekhter , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] Question on MinASOrig Timer In-reply-to: Your message of "Mon, 01 Mar 2004 09:54:34 PST." <200403011754.i21HsYHi049303@roque-bsd.juniper.net> From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 14:19:24 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <200403011754.i21HsYHi049303@roque-bsd.juniper.net>, Pedro Roque Mar ques writes: > > Implementations are always free to and expected to have functionality > that is beyond what the standard specifies. Curtis can still add the > flexibility he believes necessary... while other implementors can make > their own judgement based on what they consider the best interest of > their users. Ultimately it is up to the operators whether to use such a feature or not. It does no harm to code it in and allow the operator the choice. I'm also fine with the idea of leaving the spec alone (which I'm sure will make Yakov and Sue a bit relieved). Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 14:29:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29230 for ; Mon, 1 Mar 2004 14:29:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axt68-00059N-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 14:29:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axt5A-00051F-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 14:28:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axt4N-0004uZ-00; Mon, 01 Mar 2004 14:27:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt49-0002AD-O9; Mon, 01 Mar 2004 14:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axpum-00020Y-Nt for idr@optimus.ietf.org; Mon, 01 Mar 2004 11:05:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13110 for ; Mon, 1 Mar 2004 11:04:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxpqT-0002uE-00 for idr@ietf.org; Mon, 01 Mar 2004 11:00:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axpir-00000f-00 for idr@ietf.org; Mon, 01 Mar 2004 10:52:53 -0500 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx with esmtp (Exim 4.12) id 1AxpXd-0003m1-00 for idr@ietf.org; Mon, 01 Mar 2004 10:41:13 -0500 Received: from pmismtp05.wcomnet.com ([166.38.62.53]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HTW00H8DLVCM1@firewall.mci.com> for idr@ietf.org; Mon, 01 Mar 2004 15:33:12 +0000 (GMT) Received: from pmismtp05.wcomnet.com by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HTW00801LVBCQ@pmismtp05.mcilink.com>; Mon, 01 Mar 2004 15:33:12 +0000 (GMT) Received: from WS344V8066292 ([153.39.146.200]) by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HTW007VKLVBDL@pmismtp05.mcilink.com>; Mon, 01 Mar 2004 15:33:11 +0000 (GMT) From: Parantap Lahiri Subject: RE: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: <200402281824.i1SIO7RX049414@workhorse.fictitious.org> To: curtis@fictitious.org Cc: "'Pekka Savola'" , "'John G. Scudder'" , idr@ietf.org Message-id: <019f01c3ffa2$81715960$c8922799@mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 10:33:11 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Curtis, I was referring to a complete separate address space for the secondary loopbacks and the idea was not to aggregate that space. It would be only = in IGP as discrete /32s, and if the node is gone, the /32 will be gone, = thus immediately invalidating the routes originated by it. The rest of the = world could still reach the box using the primary loopback address, which = would be aggregated and would be in BGP.=20 Anyway, my initial message was delayed by the moderator and I found John Scudder referring to this option in one of his later mails. So I think = its covered.=20 -Parantap =20 -----Original Message----- From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]=20 Sent: Saturday, February 28, 2004 1:24 PM To: Parantap Lahiri Cc: 'Pekka Savola'; 'John G. Scudder'; idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In message <00b801c3fd70$0badcd50$c8922799@mcilink.com>, Parantap Lahiri writes : > The problem Pekka is describing is definitely a very valid problem = which > exists. I am not sure though if the fix is in some design = modifications or > in fixing the spec itself.=20 >=20 > The ways to fix it by design modification would be ... >=20 > The router R1 in question resets the BGP next-hop to some secondary loopback > address which is different from the primary loopback (part of the prefix/16) > and the secondary loopback address range is only in IGP as discrete = /32s, > this problem might be mitigated. Though it's going to load the IGP = with a > new set of IP prefixes and may be problematic in some situations since some > IGP protocols have limited capability to carry large number of IP prefixes.=20 >=20 > The other way to solve it might be a vendor implemented knob, where a > particular address range (like prefix/16) is never considered while = doing > BGP next hop resolution. Though, I am not sure if this knob would be a part > of the spec. >=20 > -Parantap I'm not sure what that has to do with discard routes unless you are talking about generating an aggregate and the next hop falling into the unused portion of the aggregate. If you allow the next hop to resolved to the unused portion of an aggregated, your implementation is simply broken. You can't forward on a aggregate you generate, you can only forward on the components that make up the aggregate and if you miss this distinction in your BGP implementation, that is just an implementation mistake. If OTOH, some other router did the aggregation and sent the aggregate into the IGP or IBGP, then the problem is not one that needs to be fixed in the spec. If allowing BGP learned routes to resolve BGP next hops, which is commonly configured, another knob that can be added is to exclude routes in which the aggregator is in the same AS. If that was not sufficient you'd need a knob to exclude specific prefixes. This is clearly outside of the BGP spec. It seems to me to be more a case of adding configuration knobs to cover up the problems caused by misconfiguration. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 15:20:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04007 for ; Mon, 1 Mar 2004 15:20:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxtuH-0003Yc-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 15:20:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxttO-0003TK-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 15:19:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axtsd-0003Nl-00; Mon, 01 Mar 2004 15:19:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxtsT-0007AL-KU; Mon, 01 Mar 2004 15:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxtsQ-00079R-Qc for idr@optimus.ietf.org; Mon, 01 Mar 2004 15:18:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03854 for ; Mon, 1 Mar 2004 15:18:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxtsP-0003Mb-00 for idr@ietf.org; Mon, 01 Mar 2004 15:18:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxtrT-0003HT-00 for idr@ietf.org; Mon, 01 Mar 2004 15:18:00 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1Axtr5-0003C4-00 for idr@ietf.org; Mon, 01 Mar 2004 15:17:35 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D52232D4947 for ; Mon, 1 Mar 2004 15:17:05 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 36947-01-40 for ; Mon, 1 Mar 2004 15:17:04 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 87DCB2D4937 for ; Mon, 1 Mar 2004 15:17:03 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] BGP-based VPLS Message-ID: Thread-Topic: [Idr] BGP-based VPLS Thread-Index: AcP/Z+OM98URFVCuTEiRHg0YjRgf5gAXP64g From: "Susan Hares" To: "Kireeti Kompella" , X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 15:17:03 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Kireeti: Just to make sure, I understand you. You are suggesting: SAFI =3D 1,2,3 per draft SAFI =3D 65 per your draft Same afi, same BGP mechanisms in draft? Sue -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Monday, March 01, 2004 3:31 AM To: idr@ietf.org Subject: [Idr] BGP-based VPLS Following up on the discussion regarding BGP for L2VPN auto-discovery, draft-ietf-l2vpn-vpls-bgp-01.txt does auto-discovery and signaling for VPLS. Of special interest to this WG is section 3, where the NLRI format for this AFI/SAFI (*) pair, and other topics are described. (*) SAFI =3D 65; AFI not yet allocated. It seems sensible to use the AFI allocated for auto-discovery. Kireeti. ------- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 15:21:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04047 for ; Mon, 1 Mar 2004 15:21:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxtuK-0007ht-Rc for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 15:20:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21KKun9029611 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 15:20:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxtuK-0007hV-4D for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 15:20:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04017 for ; Mon, 1 Mar 2004 15:20:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxtuI-0003Yh-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 15:20:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxttP-0003TR-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 15:20:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axtsd-0003Nl-00; Mon, 01 Mar 2004 15:19:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxtsT-0007AL-KU; Mon, 01 Mar 2004 15:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxtsQ-00079R-Qc for idr@optimus.ietf.org; Mon, 01 Mar 2004 15:18:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03854 for ; Mon, 1 Mar 2004 15:18:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxtsP-0003Mb-00 for idr@ietf.org; Mon, 01 Mar 2004 15:18:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxtrT-0003HT-00 for idr@ietf.org; Mon, 01 Mar 2004 15:18:00 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1Axtr5-0003C4-00 for idr@ietf.org; Mon, 01 Mar 2004 15:17:35 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D52232D4947 for ; Mon, 1 Mar 2004 15:17:05 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 36947-01-40 for ; Mon, 1 Mar 2004 15:17:04 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 87DCB2D4937 for ; Mon, 1 Mar 2004 15:17:03 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] BGP-based VPLS Message-ID: Thread-Topic: [Idr] BGP-based VPLS Thread-Index: AcP/Z+OM98URFVCuTEiRHg0YjRgf5gAXP64g From: "Susan Hares" To: "Kireeti Kompella" , X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 15:17:03 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Kireeti: Just to make sure, I understand you. You are suggesting: SAFI =3D 1,2,3 per draft SAFI =3D 65 per your draft Same afi, same BGP mechanisms in draft? Sue -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Monday, March 01, 2004 3:31 AM To: idr@ietf.org Subject: [Idr] BGP-based VPLS Following up on the discussion regarding BGP for L2VPN auto-discovery, draft-ietf-l2vpn-vpls-bgp-01.txt does auto-discovery and signaling for VPLS. Of special interest to this WG is section 3, where the NLRI format for this AFI/SAFI (*) pair, and other topics are described. (*) SAFI =3D 65; AFI not yet allocated. It seems sensible to use the AFI allocated for auto-discovery. Kireeti. ------- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 15:37:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05095 for ; Mon, 1 Mar 2004 15:37:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axu9w-0005eU-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 15:37:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axu8w-0005WW-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 15:36:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axu85-0005P7-00; Mon, 01 Mar 2004 15:35:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axu7z-0008Qz-5b; Mon, 01 Mar 2004 15:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axu7s-0008Pk-1f for idr@optimus.ietf.org; Mon, 01 Mar 2004 15:34:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04860 for ; Mon, 1 Mar 2004 15:34:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axu7q-0005Mg-00 for idr@ietf.org; Mon, 01 Mar 2004 15:34:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axu6p-0005Cw-00 for idr@ietf.org; Mon, 01 Mar 2004 15:33:52 -0500 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1Axu5v-00050A-00 for idr@ietf.org; Mon, 01 Mar 2004 15:32:56 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HTW00B59ZMJXX@firewall.mci.com> for idr@ietf.org; Mon, 01 Mar 2004 20:30:19 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HTW00801ZMILT@pmismtp01.mcilink.com>; Mon, 01 Mar 2004 20:30:19 +0000 (GMT) Received: from WS344V8066292 ([153.39.146.200]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HTW007FIZMITB@pmismtp01.mcilink.com>; Mon, 01 Mar 2004 20:30:18 +0000 (GMT) From: Parantap Lahiri Subject: RE: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: <200403012002.i21K2DRX074068@workhorse.fictitious.org> To: curtis@fictitious.org Cc: "'Pekka Savola'" , "'John G. Scudder'" , idr@ietf.org Message-id: <01da01c3ffcc$03125450$c8922799@mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 15:30:18 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Not to beat a dead horse here but in some major vendor implementations, = you can't send an "aggregate" if it is not in your routing table. And it = defeats the purpose. -----Original Message----- From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]=20 Sent: Monday, March 01, 2004 3:02 PM To: Parantap Lahiri Cc: curtis@fictitious.org; 'Pekka Savola'; 'John G. Scudder'; = idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In message <01c101c3ffb2$300c2630$c8922799@mcilink.com>, Parantap Lahiri writes : > If you aggregate the prefixes just towards EBGP neighbors it = definitely does > solve the problem, but the issue is you will have to touch all your = ebgp > sessions once you get a new block to aggregate. Operator motto is have = a > design which requires least touching. Of course that can be equated to > laziness, but it depends on which side of fence you are on. How many different blocks of addresses do you put your IBGP loopbacks in? Last I counted it was one. You don't have to treat your customer aggregates this way if you don't want to, just the aggregate that covers your backbone. And btw - with machine generated configs there is no problem generating aggregates on each EBGP speaking router - its only when you try to hand configure your 1,000+ routers (or whatever). Anyway, we already seemed to agree that this at most ends up in a separate new document. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 15:37:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05143 for ; Mon, 1 Mar 2004 15:37:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxuA0-0000Ft-2Z for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 15:37:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21Kb8dr000975 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 15:37:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axu9z-0000FS-Mz for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 15:37:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05113 for ; Mon, 1 Mar 2004 15:37:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axu9y-0005ep-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 15:37:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axu8x-0005Wi-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 15:36:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axu85-0005P7-00; Mon, 01 Mar 2004 15:35:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axu7z-0008Qz-5b; Mon, 01 Mar 2004 15:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axu7s-0008Pk-1f for idr@optimus.ietf.org; Mon, 01 Mar 2004 15:34:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04860 for ; Mon, 1 Mar 2004 15:34:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axu7q-0005Mg-00 for idr@ietf.org; Mon, 01 Mar 2004 15:34:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axu6p-0005Cw-00 for idr@ietf.org; Mon, 01 Mar 2004 15:33:52 -0500 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1Axu5v-00050A-00 for idr@ietf.org; Mon, 01 Mar 2004 15:32:56 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HTW00B59ZMJXX@firewall.mci.com> for idr@ietf.org; Mon, 01 Mar 2004 20:30:19 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HTW00801ZMILT@pmismtp01.mcilink.com>; Mon, 01 Mar 2004 20:30:19 +0000 (GMT) Received: from WS344V8066292 ([153.39.146.200]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HTW007FIZMITB@pmismtp01.mcilink.com>; Mon, 01 Mar 2004 20:30:18 +0000 (GMT) From: Parantap Lahiri Subject: RE: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: <200403012002.i21K2DRX074068@workhorse.fictitious.org> To: curtis@fictitious.org Cc: "'Pekka Savola'" , "'John G. Scudder'" , idr@ietf.org Message-id: <01da01c3ffcc$03125450$c8922799@mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 15:30:18 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Not to beat a dead horse here but in some major vendor implementations, = you can't send an "aggregate" if it is not in your routing table. And it = defeats the purpose. -----Original Message----- From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]=20 Sent: Monday, March 01, 2004 3:02 PM To: Parantap Lahiri Cc: curtis@fictitious.org; 'Pekka Savola'; 'John G. Scudder'; = idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In message <01c101c3ffb2$300c2630$c8922799@mcilink.com>, Parantap Lahiri writes : > If you aggregate the prefixes just towards EBGP neighbors it = definitely does > solve the problem, but the issue is you will have to touch all your = ebgp > sessions once you get a new block to aggregate. Operator motto is have = a > design which requires least touching. Of course that can be equated to > laziness, but it depends on which side of fence you are on. How many different blocks of addresses do you put your IBGP loopbacks in? Last I counted it was one. You don't have to treat your customer aggregates this way if you don't want to, just the aggregate that covers your backbone. And btw - with machine generated configs there is no problem generating aggregates on each EBGP speaking router - its only when you try to hand configure your 1,000+ routers (or whatever). Anyway, we already seemed to agree that this at most ends up in a separate new document. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 17:52:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10705 for ; Mon, 1 Mar 2004 17:52:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxwHR-0004yo-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 17:52:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxwGT-0004tT-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 17:51:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxwFh-0004oo-00; Mon, 01 Mar 2004 17:51:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxwFb-00087x-7I; Mon, 01 Mar 2004 17:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxwFX-00087P-Eb for idr@optimus.ietf.org; Mon, 01 Mar 2004 17:50:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10695 for ; Mon, 1 Mar 2004 17:50:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxwFU-0004oW-00 for idr@ietf.org; Mon, 01 Mar 2004 17:50:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxwEW-0004kD-00 for idr@ietf.org; Mon, 01 Mar 2004 17:49:57 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1AxwDz-0004br-00 for idr@ietf.org; Mon, 01 Mar 2004 17:49:23 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i21Mmrl90128 for ; Mon, 1 Mar 2004 14:48:53 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i21Mmmo33958 for ; Mon, 1 Mar 2004 14:48:48 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200403012248.i21Mmmo33958@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8109.1078181328.1@juniper.net> From: Yakov Rekhter Subject: [Idr] WG Last Call on draft-ietf-idr-cease-subcode-04.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 14:48:48 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Folks THis is to start the WG Last Call on advancing draft-ietf-idr-cease-subcode-04.txt to Proposed Standard. The Last Call ends March 21. Please send comments to the list. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 17:53:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10744 for ; Mon, 1 Mar 2004 17:53:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxwHV-0008Kh-HZ for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 17:53:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21Mr1NW032025 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 17:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxwHV-0008KS-7c for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 17:53:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10723 for ; Mon, 1 Mar 2004 17:52:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxwHS-0004yu-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 17:52:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxwGT-0004ta-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 17:51:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxwFh-0004oo-00; Mon, 01 Mar 2004 17:51:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxwFb-00087x-7I; Mon, 01 Mar 2004 17:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxwFX-00087P-Eb for idr@optimus.ietf.org; Mon, 01 Mar 2004 17:50:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10695 for ; Mon, 1 Mar 2004 17:50:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxwFU-0004oW-00 for idr@ietf.org; Mon, 01 Mar 2004 17:50:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxwEW-0004kD-00 for idr@ietf.org; Mon, 01 Mar 2004 17:49:57 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1AxwDz-0004br-00 for idr@ietf.org; Mon, 01 Mar 2004 17:49:23 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i21Mmrl90128 for ; Mon, 1 Mar 2004 14:48:53 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i21Mmmo33958 for ; Mon, 1 Mar 2004 14:48:48 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200403012248.i21Mmmo33958@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8109.1078181328.1@juniper.net> From: Yakov Rekhter Subject: [Idr] WG Last Call on draft-ietf-idr-cease-subcode-04.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 14:48:48 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Folks THis is to start the WG Last Call on advancing draft-ietf-idr-cease-subcode-04.txt to Proposed Standard. The Last Call ends March 21. Please send comments to the list. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 18:46:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13563 for ; Mon, 1 Mar 2004 18:46:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axx7k-0002f9-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 18:47:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axx6o-0002Yb-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 18:46:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axx60-0002TR-00; Mon, 01 Mar 2004 18:45:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axx5s-0001KT-BL; Mon, 01 Mar 2004 18:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axx5A-0001Im-00 for idr@optimus.ietf.org; Mon, 01 Mar 2004 18:44:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13420 for ; Mon, 1 Mar 2004 18:44:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axx56-0002Nc-00 for idr@ietf.org; Mon, 01 Mar 2004 18:44:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axx4B-0002GQ-00 for idr@ietf.org; Mon, 01 Mar 2004 18:43:20 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axx3L-00024H-00 for idr@ietf.org; Mon, 01 Mar 2004 18:42:28 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i21NffY14129; Tue, 2 Mar 2004 01:41:42 +0200 From: Pekka Savola To: curtis@fictitious.org cc: Parantap Lahiri , "'John G. Scudder'" , Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <200403012044.i21KijRX074248@workhorse.fictitious.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 01:41:41 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 1 Mar 2004, Curtis Villamizar wrote: > I suppose this is the original reason that the discard route was > mentioned, but with a failure to mention the entire context. You can > manually configure discard routes but that is generally only done in > very unusual circumstances, such as a DoS attack to a specific > destination. I guess you weren't following. Discard routes are set up because folks want to announce that aggregate route to their peers. That's not a "very unusual circumstance". > No need to modify the spec. If you've installed a special type of > route in the kernel that is there explicitly to indicate > non-reachability, then that route should not be allowed to indicate > reachability. I dont' think we really need to say that. You would think so, but the current spec does not say so. Maybe a problem is that a discard route should not fail the resolvability check when propagated as a DDoS prevention hack, referred earlier. IMHO, excluding these routes seems obvious to me, but as it wasn't obvious to the implementors and they hadn't done it, it MUST be in the spec in one form or another. Whether it should be discussed at more length in some other document (Targeting BCP or PS, I don't know). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 18:47:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13630 for ; Mon, 1 Mar 2004 18:47:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axx7o-0001tW-JK for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 18:47:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21Nl472007276 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 18:47:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axx7o-0001tH-Ek for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 18:47:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13572 for ; Mon, 1 Mar 2004 18:47:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axx7l-0002fE-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 18:47:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axx6p-0002Yi-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 18:46:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axx60-0002TR-00; Mon, 01 Mar 2004 18:45:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axx5s-0001KT-BL; Mon, 01 Mar 2004 18:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axx5A-0001Im-00 for idr@optimus.ietf.org; Mon, 01 Mar 2004 18:44:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13420 for ; Mon, 1 Mar 2004 18:44:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axx56-0002Nc-00 for idr@ietf.org; Mon, 01 Mar 2004 18:44:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axx4B-0002GQ-00 for idr@ietf.org; Mon, 01 Mar 2004 18:43:20 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axx3L-00024H-00 for idr@ietf.org; Mon, 01 Mar 2004 18:42:28 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i21NffY14129; Tue, 2 Mar 2004 01:41:42 +0200 From: Pekka Savola To: curtis@fictitious.org cc: Parantap Lahiri , "'John G. Scudder'" , Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <200403012044.i21KijRX074248@workhorse.fictitious.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 01:41:41 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 1 Mar 2004, Curtis Villamizar wrote: > I suppose this is the original reason that the discard route was > mentioned, but with a failure to mention the entire context. You can > manually configure discard routes but that is generally only done in > very unusual circumstances, such as a DoS attack to a specific > destination. I guess you weren't following. Discard routes are set up because folks want to announce that aggregate route to their peers. That's not a "very unusual circumstance". > No need to modify the spec. If you've installed a special type of > route in the kernel that is there explicitly to indicate > non-reachability, then that route should not be allowed to indicate > reachability. I dont' think we really need to say that. You would think so, but the current spec does not say so. Maybe a problem is that a discard route should not fail the resolvability check when propagated as a DDoS prevention hack, referred earlier. IMHO, excluding these routes seems obvious to me, but as it wasn't obvious to the implementors and they hadn't done it, it MUST be in the spec in one form or another. Whether it should be discussed at more length in some other document (Targeting BCP or PS, I don't know). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 19:13:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14414 for ; Mon, 1 Mar 2004 19:13:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxX0-0005Cq-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:13:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxW3-00056q-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:12:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxxVX-00051D-00; Mon, 01 Mar 2004 19:11:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxUz-0003cT-HA; Mon, 01 Mar 2004 19:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxU6-0003Yx-Nn for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:10:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14326 for ; Mon, 1 Mar 2004 19:10:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxU3-0004uq-00 for idr@ietf.org; Mon, 01 Mar 2004 19:10:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxT9-0004pu-00 for idr@ietf.org; Mon, 01 Mar 2004 19:09:08 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxSp-0004kD-00 for idr@ietf.org; Mon, 01 Mar 2004 19:08:47 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2208FC14582; Tue, 2 Mar 2004 02:08:15 +0200 From: Pekka Savola To: Pedro Roque Marques cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 02:08:15 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 1 Mar 2004, Pedro Roque Marques wrote: > What is the #1 goal of BGP ? > The establishment of *loop free* paths between autonomous > systems. How can you guarantee loop free properties ? via the as-path > loop detection mechanism... This means that you can only gurantee no > forwarding loops if traffic always follows routing. This is IMHO a bogus argument in this case. BGP already relies on the consistency of the AS in its operations. This is just a matter of the IGP and BGP in the AS being consistent. As stated earlier, there is ample operational experience that this modification works. The operators, with or without this modification, can shoot themselves in the foot and discard packets. > But there are more mundane practical consequences: > > outside > | | > ----------- > a --- b as x > | | > > A and B are border gateways for a stub as (x). Both are configured to > originate a given prefix 10.0.1/24 whenever that prefix is reachable > throught its IGP. > > Additionally, they are configured w/ a discard route to 10.0.1/24, > which discard traffic whenever the IGP route is not present. > > In case of failure, one likely gets one of the exit points w/ a > discard route as its forwarding state, while the other exit point has > a valid IGP route. [I don't quickly see how this is related to this specific issue, but I'm still grasping to understand the specific scenario and the failure model you're describing.] I don't see this happening. Which specific failure are you talking about? It seems to me that: - either the router (a/b) is down making the point moot (the other is in IGP) - either a link has failed (e.g., between a and b), but then the IGP redundancy fixes this problem by rerouting through the stub area (by your description I get that the prefix is learned from some other router in the area). If a link has failed but rerouting is not possible (i.e.: a and b become isolated from each other, or both a and b become isolated from the route originator), the internal consistency has failed. But as they have configured a discard route, this is an intended consequence -- the routers by its definition are supposed to know everything in the area. > If the gateway that has a discard route in the forwarding table does > advertise the route from its peer gateway it will cause traffic to be > dropped. I didn't quite follow this description, but if the stub had a discard route configured, but the IGP is inconsistent, this should definitely be the expected behaviour. > Generalizing: > - whenever BGP advertises a route that it doesn't use for forwarding, > traffic can easily end up getting dropped. Spelling out the root cause: - having an inconsistent/wrong IGP configuration can cause easily traffic to be dropped -- nothing new there. > Would there be a kind soul that volunteers to keep a FAQ of this WG > list ? That way we wouldn't need to rehash this discussion and the > MRAI discussion every 6 months. No objection to having such a FAQ, as long as such a FAQ is not based on bogus arguments. Issue 11 was covered in the BGP issues list, for example, but with incorrect assumptions. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 19:13:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14445 for ; Mon, 1 Mar 2004 19:13:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxX2-0003nr-HV for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 19:13:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i220D8xf014613 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 19:13:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxX2-0003nc-Dh for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 19:13:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14432 for ; Mon, 1 Mar 2004 19:13:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxX0-0005Cw-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:13:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxW4-00056x-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:12:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxxVX-00051D-00; Mon, 01 Mar 2004 19:11:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxUz-0003cT-HA; Mon, 01 Mar 2004 19:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxU6-0003Yx-Nn for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:10:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14326 for ; Mon, 1 Mar 2004 19:10:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxU3-0004uq-00 for idr@ietf.org; Mon, 01 Mar 2004 19:10:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxT9-0004pu-00 for idr@ietf.org; Mon, 01 Mar 2004 19:09:08 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxSp-0004kD-00 for idr@ietf.org; Mon, 01 Mar 2004 19:08:47 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2208FC14582; Tue, 2 Mar 2004 02:08:15 +0200 From: Pekka Savola To: Pedro Roque Marques cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 02:08:15 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 1 Mar 2004, Pedro Roque Marques wrote: > What is the #1 goal of BGP ? > The establishment of *loop free* paths between autonomous > systems. How can you guarantee loop free properties ? via the as-path > loop detection mechanism... This means that you can only gurantee no > forwarding loops if traffic always follows routing. This is IMHO a bogus argument in this case. BGP already relies on the consistency of the AS in its operations. This is just a matter of the IGP and BGP in the AS being consistent. As stated earlier, there is ample operational experience that this modification works. The operators, with or without this modification, can shoot themselves in the foot and discard packets. > But there are more mundane practical consequences: > > outside > | | > ----------- > a --- b as x > | | > > A and B are border gateways for a stub as (x). Both are configured to > originate a given prefix 10.0.1/24 whenever that prefix is reachable > throught its IGP. > > Additionally, they are configured w/ a discard route to 10.0.1/24, > which discard traffic whenever the IGP route is not present. > > In case of failure, one likely gets one of the exit points w/ a > discard route as its forwarding state, while the other exit point has > a valid IGP route. [I don't quickly see how this is related to this specific issue, but I'm still grasping to understand the specific scenario and the failure model you're describing.] I don't see this happening. Which specific failure are you talking about? It seems to me that: - either the router (a/b) is down making the point moot (the other is in IGP) - either a link has failed (e.g., between a and b), but then the IGP redundancy fixes this problem by rerouting through the stub area (by your description I get that the prefix is learned from some other router in the area). If a link has failed but rerouting is not possible (i.e.: a and b become isolated from each other, or both a and b become isolated from the route originator), the internal consistency has failed. But as they have configured a discard route, this is an intended consequence -- the routers by its definition are supposed to know everything in the area. > If the gateway that has a discard route in the forwarding table does > advertise the route from its peer gateway it will cause traffic to be > dropped. I didn't quite follow this description, but if the stub had a discard route configured, but the IGP is inconsistent, this should definitely be the expected behaviour. > Generalizing: > - whenever BGP advertises a route that it doesn't use for forwarding, > traffic can easily end up getting dropped. Spelling out the root cause: - having an inconsistent/wrong IGP configuration can cause easily traffic to be dropped -- nothing new there. > Would there be a kind soul that volunteers to keep a FAQ of this WG > list ? That way we wouldn't need to rehash this discussion and the > MRAI discussion every 6 months. No objection to having such a FAQ, as long as such a FAQ is not based on bogus arguments. Issue 11 was covered in the BGP issues list, for example, but with incorrect assumptions. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 19:22:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14874 for ; Mon, 1 Mar 2004 19:22:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axxfl-0006NE-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:22:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axxen-0006E9-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:21:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axxdm-00065b-00; Mon, 01 Mar 2004 19:20:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxdi-0004CI-HF; Mon, 01 Mar 2004 19:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxd6-00045K-Le for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:19:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14736 for ; Mon, 1 Mar 2004 19:19:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axxd5-0005yb-00 for idr@ietf.org; Mon, 01 Mar 2004 19:19:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axxc5-0005r8-00 for idr@ietf.org; Mon, 01 Mar 2004 19:18:22 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AxxbU-0005h4-00 for idr@ietf.org; Mon, 01 Mar 2004 19:17:44 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i220HE1K050125; Mon, 1 Mar 2004 16:17:14 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i220HE0F050122; Mon, 1 Mar 2004 16:17:14 -0800 (PST) Message-Id: <200403020017.i220HE0F050122@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pekka Savola Cc: Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: References: <200403012044.i21KijRX074248@workhorse.fictitious.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 16:17:14 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Pekka Savola writes: > You would think so, but the current spec does not say so. > Maybe a problem is that a discard route should not fail the > resolvability check when propagated as a DDoS prevention hack, > referred earlier. > IMHO, excluding these routes seems obvious to me And to me it seems obvious that a route is a route, regardless of next-hop type. The later being an implementation specific concept and not something to be addressed at the spec level... It is clear that what 'seems obvious' is highly subjective to the person in question. >, but as it wasn't > obvious to the implementors and they hadn't done it, it MUST be in > the spec in one form or another. imho, it MUST NOT be in the BGP specification in one way or another. The BGP specification deals w/ the protocol definition, not with how to implement it. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 19:22:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14952 for ; Mon, 1 Mar 2004 19:22:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxfo-0004OY-5J for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 19:22:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i220MCLG016888 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 19:22:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxfo-0004OJ-19 for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 19:22:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14882 for ; Mon, 1 Mar 2004 19:22:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axxfm-0006NK-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:22:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axxeo-0006EG-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:21:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axxdm-00065b-00; Mon, 01 Mar 2004 19:20:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxdi-0004CI-HF; Mon, 01 Mar 2004 19:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxd6-00045K-Le for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:19:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14736 for ; Mon, 1 Mar 2004 19:19:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axxd5-0005yb-00 for idr@ietf.org; Mon, 01 Mar 2004 19:19:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axxc5-0005r8-00 for idr@ietf.org; Mon, 01 Mar 2004 19:18:22 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AxxbU-0005h4-00 for idr@ietf.org; Mon, 01 Mar 2004 19:17:44 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i220HE1K050125; Mon, 1 Mar 2004 16:17:14 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i220HE0F050122; Mon, 1 Mar 2004 16:17:14 -0800 (PST) Message-Id: <200403020017.i220HE0F050122@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pekka Savola Cc: Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: References: <200403012044.i21KijRX074248@workhorse.fictitious.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 16:17:14 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola writes: > You would think so, but the current spec does not say so. > Maybe a problem is that a discard route should not fail the > resolvability check when propagated as a DDoS prevention hack, > referred earlier. > IMHO, excluding these routes seems obvious to me And to me it seems obvious that a route is a route, regardless of next-hop type. The later being an implementation specific concept and not something to be addressed at the spec level... It is clear that what 'seems obvious' is highly subjective to the person in question. >, but as it wasn't > obvious to the implementors and they hadn't done it, it MUST be in > the spec in one form or another. imho, it MUST NOT be in the BGP specification in one way or another. The BGP specification deals w/ the protocol definition, not with how to implement it. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 19:29:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15351 for ; Mon, 1 Mar 2004 19:29:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxnM-0007Go-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:30:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxmO-0007AE-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:29:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxxlT-00074D-00; Mon, 01 Mar 2004 19:28:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxlR-0005VV-AL; Mon, 01 Mar 2004 19:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxkg-0005Uq-7c for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:27:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15230 for ; Mon, 1 Mar 2004 19:27:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axxke-0006zB-00 for idr@ietf.org; Mon, 01 Mar 2004 19:27:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axxjs-0006su-00 for idr@ietf.org; Mon, 01 Mar 2004 19:26:25 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AxxjH-0006kB-00 for idr@ietf.org; Mon, 01 Mar 2004 19:25:47 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i220PI1K050141; Mon, 1 Mar 2004 16:25:18 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i220PI9P050138; Mon, 1 Mar 2004 16:25:18 -0800 (PST) Message-Id: <200403020025.i220PI9P050138@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pekka Savola Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 16:25:18 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Pekka Savola writes: > On Mon, 1 Mar 2004, Pedro Roque Marques wrote: >> What is the #1 goal of BGP ? The establishment of *loop free* >> paths between autonomous systems. How can you guarantee loop free >> properties ? via the as-path loop detection mechanism... This means >> that you can only gurantee no forwarding loops if traffic always >> follows routing. > This is IMHO a bogus argument in this case. BGP already relies on > the consistency of the AS in its operations. This is just a matter > of the IGP and BGP in the AS being consistent. > As stated earlier, there is ample operational experience that this > modification works. > The operators, with or without this modification, can shoot > themselves in the foot and discard packets. It seems that you did not understand my argument... i'll repeat it: - How can you prove that a given path that is learned by BGP is loop free ? - That can only be done if forwarding follows routing. Proof: configure a static route for a given prefix in a border router that points to a BGP neighbor that selects this router as best path... watch permanent forwarding loops. Protocol correctness matters. The point of the BGP spec is not how to deal w/ implementation quirks... but it is about protocol correctness. Implementations may feel free to disregard safety rules... and allow uses "to shoot themselfs in the foot"... but it must be clear what the risks are and the BGP spec should be as conservative as possible. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 19:30:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15390 for ; Mon, 1 Mar 2004 19:30:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxnP-0005jo-9s for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 19:30:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i220U3lO022050 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 19:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxnP-0005jW-6O for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 19:30:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15369 for ; Mon, 1 Mar 2004 19:30:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxnN-0007Gv-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:30:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxmP-0007AL-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:29:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxxlT-00074D-00; Mon, 01 Mar 2004 19:28:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxlR-0005VV-AL; Mon, 01 Mar 2004 19:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxkg-0005Uq-7c for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:27:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15230 for ; Mon, 1 Mar 2004 19:27:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axxke-0006zB-00 for idr@ietf.org; Mon, 01 Mar 2004 19:27:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axxjs-0006su-00 for idr@ietf.org; Mon, 01 Mar 2004 19:26:25 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AxxjH-0006kB-00 for idr@ietf.org; Mon, 01 Mar 2004 19:25:47 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i220PI1K050141; Mon, 1 Mar 2004 16:25:18 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i220PI9P050138; Mon, 1 Mar 2004 16:25:18 -0800 (PST) Message-Id: <200403020025.i220PI9P050138@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pekka Savola Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 16:25:18 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola writes: > On Mon, 1 Mar 2004, Pedro Roque Marques wrote: >> What is the #1 goal of BGP ? The establishment of *loop free* >> paths between autonomous systems. How can you guarantee loop free >> properties ? via the as-path loop detection mechanism... This means >> that you can only gurantee no forwarding loops if traffic always >> follows routing. > This is IMHO a bogus argument in this case. BGP already relies on > the consistency of the AS in its operations. This is just a matter > of the IGP and BGP in the AS being consistent. > As stated earlier, there is ample operational experience that this > modification works. > The operators, with or without this modification, can shoot > themselves in the foot and discard packets. It seems that you did not understand my argument... i'll repeat it: - How can you prove that a given path that is learned by BGP is loop free ? - That can only be done if forwarding follows routing. Proof: configure a static route for a given prefix in a border router that points to a BGP neighbor that selects this router as best path... watch permanent forwarding loops. Protocol correctness matters. The point of the BGP spec is not how to deal w/ implementation quirks... but it is about protocol correctness. Implementations may feel free to disregard safety rules... and allow uses "to shoot themselfs in the foot"... but it must be clear what the risks are and the BGP spec should be as conservative as possible. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 19:32:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15569 for ; Mon, 1 Mar 2004 19:32:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxqF-0007dY-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:32:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxpI-0007Wa-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:32:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxxoN-0007Ov-00; Mon, 01 Mar 2004 19:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxoM-0005my-Sa; Mon, 01 Mar 2004 19:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxnQ-0005jx-Vk for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:30:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15376 for ; Mon, 1 Mar 2004 19:30:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxnP-0007HD-00 for idr@ietf.org; Mon, 01 Mar 2004 19:30:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxmT-0007As-00 for idr@ietf.org; Mon, 01 Mar 2004 19:29:06 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AxxlX-0006zP-00 for idr@ietf.org; Mon, 01 Mar 2004 19:28:07 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9990B2D4838; Mon, 1 Mar 2004 19:27:33 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 42001-01-23; Mon, 1 Mar 2004 19:27:32 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9A3E22D481E; Mon, 1 Mar 2004 19:27:32 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i220RWx21603; Mon, 1 Mar 2004 19:27:32 -0500 (EST) From: Jeffrey Haas To: Pekka Savola Cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes Message-ID: <20040301192732.A21492@nexthop.com> References: <200403012044.i21KijRX074248@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pekkas@netcore.fi on Tue, Mar 02, 2004 at 01:41:41AM +0200 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 19:27:32 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Pekka, On Tue, Mar 02, 2004 at 01:41:41AM +0200, Pekka Savola wrote: > I guess you weren't following. Discard routes are set up because > folks want to announce that aggregate route to their peers. That's > not a "very unusual circumstance". If I'm following you correctly, here's an example of the condition that you're talking about. C /| A | \| B B has prefix D1 - 192/17 C has prefix D2 - 192.128/17 B and C advertises these routes with loopback addresses. (next-hop-self) A synthesizes an aggregate, 192/16 using B and C's routes as contributors. A thus installs 192/16 in it's FIB as a reject route per accepted practice. C is nuked from space in a green fireball. Prior to BGP figuring out that C has gone away, C's loopback is no longer advertised, leaving B to use the aggregate from A to calculate the resolved nexthop for D2. Thus, B has a route to D2 via A, which will eventually reach a reject route. Is this your scenario? -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 19:33:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15638 for ; Mon, 1 Mar 2004 19:33:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxqI-00063Y-Dp for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 19:33:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i220X2X5023274 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 19:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxqI-00063J-AY for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 19:33:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15587 for ; Mon, 1 Mar 2004 19:32:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxqG-0007de-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:33:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxpJ-0007Wi-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:32:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxxoN-0007Ov-00; Mon, 01 Mar 2004 19:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxoM-0005my-Sa; Mon, 01 Mar 2004 19:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxnQ-0005jx-Vk for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:30:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15376 for ; Mon, 1 Mar 2004 19:30:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxnP-0007HD-00 for idr@ietf.org; Mon, 01 Mar 2004 19:30:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxmT-0007As-00 for idr@ietf.org; Mon, 01 Mar 2004 19:29:06 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AxxlX-0006zP-00 for idr@ietf.org; Mon, 01 Mar 2004 19:28:07 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9990B2D4838; Mon, 1 Mar 2004 19:27:33 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 42001-01-23; Mon, 1 Mar 2004 19:27:32 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9A3E22D481E; Mon, 1 Mar 2004 19:27:32 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i220RWx21603; Mon, 1 Mar 2004 19:27:32 -0500 (EST) From: Jeffrey Haas To: Pekka Savola Cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes Message-ID: <20040301192732.A21492@nexthop.com> References: <200403012044.i21KijRX074248@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pekkas@netcore.fi on Tue, Mar 02, 2004 at 01:41:41AM +0200 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 19:27:32 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Pekka, On Tue, Mar 02, 2004 at 01:41:41AM +0200, Pekka Savola wrote: > I guess you weren't following. Discard routes are set up because > folks want to announce that aggregate route to their peers. That's > not a "very unusual circumstance". If I'm following you correctly, here's an example of the condition that you're talking about. C /| A | \| B B has prefix D1 - 192/17 C has prefix D2 - 192.128/17 B and C advertises these routes with loopback addresses. (next-hop-self) A synthesizes an aggregate, 192/16 using B and C's routes as contributors. A thus installs 192/16 in it's FIB as a reject route per accepted practice. C is nuked from space in a green fireball. Prior to BGP figuring out that C has gone away, C's loopback is no longer advertised, leaving B to use the aggregate from A to calculate the resolved nexthop for D2. Thus, B has a route to D2 via A, which will eventually reach a reject route. Is this your scenario? -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 19:38:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15910 for ; Mon, 1 Mar 2004 19:38:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxvN-0000VM-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:38:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxuP-0000Kl-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:37:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxxtN-0000C9-00; Mon, 01 Mar 2004 19:36:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxtD-0006KV-8T; Mon, 01 Mar 2004 19:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxsJ-0006HG-GT for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:35:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15792 for ; Mon, 1 Mar 2004 19:35:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxsH-000045-00 for idr@ietf.org; Mon, 01 Mar 2004 19:35:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxrM-0007lp-00 for idr@ietf.org; Mon, 01 Mar 2004 19:34:09 -0500 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx with esmtp (Exim 4.12) id 1Axxqh-0007fh-00 for idr@ietf.org; Mon, 01 Mar 2004 19:33:27 -0500 Received: (qmail 7726 invoked by uid 1021); 2 Mar 2004 00:33:14 -0000 From: vijay gill To: Pedro Roque Marques Cc: Pekka Savola , idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) Message-ID: <20040302003314.GA6255@vijaygill.com> References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> <200403020025.i220PI9P050138@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403020025.i220PI9P050138@roque-bsd.juniper.net> User-Agent: Mutt/1.3.28i Organization: vijay gill global logistics Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 00:33:14 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Mon, Mar 01, 2004 at 04:25:18PM -0800, Pedro Roque Marques wrote: > Pekka Savola writes: > > i'll repeat it: > - How can you prove that a given path that is learned by BGP is loop > free ? > - That can only be done if forwarding follows routing. I feel that BGP should only be concerned about creating loop free topologies. If the user then has a mechanism where the forwarding does not follow the routing properly and causes a loop (this is an important distinction), then this is their problem. I can always point a static back up a link if I so want and nothing bgp can do about it. > > Proof: configure a static route for a given prefix in a border router > that points to a BGP neighbor that selects this router as best > path... watch permanent forwarding loops. Yes, and this is a not a matter for BGP to worry about. /vijay _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 19:38:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15932 for ; Mon, 1 Mar 2004 19:38:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxvP-0000VZ-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:38:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxuQ-0000L3-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:37:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxxtN-0000CA-00; Mon, 01 Mar 2004 19:36:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxtE-0006LS-Di; Mon, 01 Mar 2004 19:36:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axtf0-0001y7-A5 for idr@optimus.ietf.org; Mon, 01 Mar 2004 15:05:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02284 for ; Mon, 1 Mar 2004 15:05:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axtex-0001rt-00 for idr@ietf.org; Mon, 01 Mar 2004 15:05:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axte6-0001jW-00 for idr@ietf.org; Mon, 01 Mar 2004 15:04:10 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AxtdT-0001cL-00 for idr@ietf.org; Mon, 01 Mar 2004 15:03:31 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i21K2DRX074068; Mon, 1 Mar 2004 15:02:13 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403012002.i21K2DRX074068@workhorse.fictitious.org> To: Parantap Lahiri cc: curtis@fictitious.org, "'Pekka Savola'" , "'John G. Scudder'" , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: Your message of "Mon, 01 Mar 2004 12:25:27 EST." <01c101c3ffb2$300c2630$c8922799@mcilink.com> From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 15:02:13 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <01c101c3ffb2$300c2630$c8922799@mcilink.com>, Parantap Lahiri writes : > If you aggregate the prefixes just towards EBGP neighbors it definitely does > solve the problem, but the issue is you will have to touch all your ebgp > sessions once you get a new block to aggregate. Operator motto is have a > design which requires least touching. Of course that can be equated to > laziness, but it depends on which side of fence you are on. How many different blocks of addresses do you put your IBGP loopbacks in? Last I counted it was one. You don't have to treat your customer aggregates this way if you don't want to, just the aggregate that covers your backbone. And btw - with machine generated configs there is no problem generating aggregates on each EBGP speaking router - its only when you try to hand configure your 1,000+ routers (or whatever). Anyway, we already seemed to agree that this at most ends up in a separate new document. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 19:38:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15954 for ; Mon, 1 Mar 2004 19:38:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxvR-0000Vk-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:38:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxuS-0000LI-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:37:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxxtN-0000CC-00; Mon, 01 Mar 2004 19:36:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxtF-0006Mq-C6; Mon, 01 Mar 2004 19:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxuKf-00016g-3W for idr@optimus.ietf.org; Mon, 01 Mar 2004 15:48:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05628 for ; Mon, 1 Mar 2004 15:48:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxuKd-0006oY-00 for idr@ietf.org; Mon, 01 Mar 2004 15:48:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxuJf-0006gd-00 for idr@ietf.org; Mon, 01 Mar 2004 15:47:07 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AxuId-0006ZU-00 for idr@ietf.org; Mon, 01 Mar 2004 15:46:03 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i21KijRX074248; Mon, 1 Mar 2004 15:44:45 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403012044.i21KijRX074248@workhorse.fictitious.org> To: Parantap Lahiri cc: curtis@fictitious.org, "'Pekka Savola'" , "'John G. Scudder'" , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: Your message of "Mon, 01 Mar 2004 15:30:18 EST." <01da01c3ffcc$03125450$c8922799@mcilink.com> From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 15:44:45 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <01da01c3ffcc$03125450$c8922799@mcilink.com>, Parantap Lahiri writes : > Not to beat a dead horse here but in some major vendor implementations, you > can't send an "aggregate" if it is not in your routing table. And it defeats > the purpose. Then the aggregate is locally generated and it is very easy to exclude the parts of an aggregate that you generated but are not covered by more specific from the reachability test and it makes perfectly good sense to do so. If other prefixes in the AS match that aggregate then the aggregate is generated but locally it is installed as a discard route. I suppose this is the original reason that the discard route was mentioned, but with a failure to mention the entire context. You can manually configure discard routes but that is generally only done in very unusual circumstances, such as a DoS attack to a specific destination. Even then it doesn't make a whole lot of sense to allow such a discard route to be used in the resolvability test. No need to modify the spec. If you've installed a special type of route in the kernel that is there explicitly to indicate non-reachability, then that route should not be allowed to indicate reachability. I dont' think we really need to say that. Curtis > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > Sent: Monday, March 01, 2004 3:02 PM > To: Parantap Lahiri > Cc: curtis@fictitious.org; 'Pekka Savola'; 'John G. Scudder'; idr@ietf.org > Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 > routes > > > In message <01c101c3ffb2$300c2630$c8922799@mcilink.com>, Parantap Lahiri > writes > : > > If you aggregate the prefixes just towards EBGP neighbors it definitely > does > > solve the problem, but the issue is you will have to touch all your ebgp > > sessions once you get a new block to aggregate. Operator motto is have a > > design which requires least touching. Of course that can be equated to > > laziness, but it depends on which side of fence you are on. > > > How many different blocks of addresses do you put your IBGP loopbacks > in? Last I counted it was one. You don't have to treat your customer > aggregates this way if you don't want to, just the aggregate that > covers your backbone. And btw - with machine generated configs there > is no problem generating aggregates on each EBGP speaking router - its > only when you try to hand configure your 1,000+ routers (or whatever). > > Anyway, we already seemed to agree that this at most ends up in a > separate new document. > > Curtis > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 19:39:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16071 for ; Mon, 1 Mar 2004 19:39:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axxw9-0000fD-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:39:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxvA-0000TM-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:38:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxxuA-0000J0-00; Mon, 01 Mar 2004 19:37:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxuA-0006pX-6k; Mon, 01 Mar 2004 19:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxtP-0006Xg-6M for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:36:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15814 for ; Mon, 1 Mar 2004 19:36:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxtN-0000C8-00 for idr@ietf.org; Mon, 01 Mar 2004 19:36:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxsO-00005D-00 for idr@ietf.org; Mon, 01 Mar 2004 19:35:12 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Axxrl-0007kv-00 for idr@ietf.org; Mon, 01 Mar 2004 19:34:33 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i220TlS17480 for ; Mon, 1 Mar 2004 19:29:47 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Mar 2004 19:29:47 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A5AE2AB@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: idr@ietf.org Cc: "Wijnen, Bert (Bert)" Subject: RE: [Idr] Experimental code-points MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 19:29:47 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 hi In looking through http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00 .txt I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated. In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' Sharon -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Monday, March 01, 2004 3:11 AM To: idr@ietf.org Subject: [Idr] Experimental code-points As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. -- Alex http://www.psg.com/~zinin/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 19:39:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16191 for ; Mon, 1 Mar 2004 19:39:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxwD-0007Z1-Ot for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 19:39:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i220d9BV029069 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 19:39:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxwD-0007Ym-LG for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 19:39:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16089 for ; Mon, 1 Mar 2004 19:39:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxwB-0000fY-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:39:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxvA-0000TU-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:38:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxxuA-0000J0-00; Mon, 01 Mar 2004 19:37:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxuA-0006pX-6k; Mon, 01 Mar 2004 19:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxtP-0006Xg-6M for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:36:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15814 for ; Mon, 1 Mar 2004 19:36:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxtN-0000C8-00 for idr@ietf.org; Mon, 01 Mar 2004 19:36:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxsO-00005D-00 for idr@ietf.org; Mon, 01 Mar 2004 19:35:12 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Axxrl-0007kv-00 for idr@ietf.org; Mon, 01 Mar 2004 19:34:33 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i220TlS17480 for ; Mon, 1 Mar 2004 19:29:47 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Mar 2004 19:29:47 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A5AE2AB@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: idr@ietf.org Cc: "Wijnen, Bert (Bert)" Subject: RE: [Idr] Experimental code-points MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 19:29:47 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 hi In looking through http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00 .txt I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated. In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' Sharon -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Monday, March 01, 2004 3:11 AM To: idr@ietf.org Subject: [Idr] Experimental code-points As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. -- Alex http://www.psg.com/~zinin/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 19:40:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16271 for ; Mon, 1 Mar 2004 19:40:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axxx6-0000ou-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:40:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axxw9-0000fI-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:39:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxxvA-0000TR-00; Mon, 01 Mar 2004 19:38:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxv9-00079k-NM; Mon, 01 Mar 2004 19:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxub-00070B-DC for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:37:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15870 for ; Mon, 1 Mar 2004 19:37:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxuZ-0000MQ-00 for idr@ietf.org; Mon, 01 Mar 2004 19:37:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxtQ-0000Cq-00 for idr@ietf.org; Mon, 01 Mar 2004 19:36:16 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1Axxsb-0007mb-00 for idr@ietf.org; Mon, 01 Mar 2004 19:35:25 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i220Yt1K050160; Mon, 1 Mar 2004 16:34:55 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i220Ytrh050157; Mon, 1 Mar 2004 16:34:55 -0800 (PST) Message-Id: <200403020034.i220Ytrh050157@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pekka Savola Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 16:34:55 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Pekka Savola writes: > [I don't quickly see how this is related to this specific issue, but > I'm still grasping to understand the specific scenario and the > failure model you're describing.] The issue is "what are the drawbacks of advertising a route that is not used for forwarding". > If a link has failed but rerouting is not possible (i.e.: a and b > become isolated from each other, or both a and b become isolated > from the route originator), the internal consistency has failed. > But as they have configured a discard route, this is an intended > consequence -- the routers by its definition are supposed to know > everything in the area. In such scenario, w/ one choice of behaviour a blackhole route is advertised, w/ is not so w/ another choice of behaviour. Which means that your original question as to there being instances where this behaviour is desirable has been answered. It may not be desirable in your network. And i find it perfectly reasonable if you require implementations to support the behaviour that is desirable in your network. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 19:40:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16331 for ; Mon, 1 Mar 2004 19:40:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxxF-0007s4-8A for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 19:40:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i220eC1P030211 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 19:40:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxxA-0007qI-79 for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 19:40:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16289 for ; Mon, 1 Mar 2004 19:40:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axxx8-0000p7-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:40:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxwA-0000fP-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:39:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxxvA-0000TR-00; Mon, 01 Mar 2004 19:38:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxv9-00079k-NM; Mon, 01 Mar 2004 19:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxub-00070B-DC for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:37:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15870 for ; Mon, 1 Mar 2004 19:37:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxuZ-0000MQ-00 for idr@ietf.org; Mon, 01 Mar 2004 19:37:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxtQ-0000Cq-00 for idr@ietf.org; Mon, 01 Mar 2004 19:36:16 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1Axxsb-0007mb-00 for idr@ietf.org; Mon, 01 Mar 2004 19:35:25 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i220Yt1K050160; Mon, 1 Mar 2004 16:34:55 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i220Ytrh050157; Mon, 1 Mar 2004 16:34:55 -0800 (PST) Message-Id: <200403020034.i220Ytrh050157@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pekka Savola Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 16:34:55 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola writes: > [I don't quickly see how this is related to this specific issue, but > I'm still grasping to understand the specific scenario and the > failure model you're describing.] The issue is "what are the drawbacks of advertising a route that is not used for forwarding". > If a link has failed but rerouting is not possible (i.e.: a and b > become isolated from each other, or both a and b become isolated > from the route originator), the internal consistency has failed. > But as they have configured a discard route, this is an intended > consequence -- the routers by its definition are supposed to know > everything in the area. In such scenario, w/ one choice of behaviour a blackhole route is advertised, w/ is not so w/ another choice of behaviour. Which means that your original question as to there being instances where this behaviour is desirable has been answered. It may not be desirable in your network. And i find it perfectly reasonable if you require implementations to support the behaviour that is desirable in your network. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 19:47:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16683 for ; Mon, 1 Mar 2004 19:47:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axy3r-0001ij-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:47:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axy2z-0001ac-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:46:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axy21-0001Si-00; Mon, 01 Mar 2004 19:45:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axy1w-0008KT-Ev; Mon, 01 Mar 2004 19:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axy17-0008JE-Qb for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:44:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16568 for ; Mon, 1 Mar 2004 19:44:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axy16-0001Kt-00 for idr@ietf.org; Mon, 01 Mar 2004 19:44:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axy0E-0001EG-00 for idr@ietf.org; Mon, 01 Mar 2004 19:43:18 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AxxzQ-00010k-00 for idr@ietf.org; Mon, 01 Mar 2004 19:42:28 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i220fw1K050176; Mon, 1 Mar 2004 16:41:58 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i220fwFm050173; Mon, 1 Mar 2004 16:41:58 -0800 (PST) Message-Id: <200403020041.i220fwFm050173@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: vijay gill Cc: Pekka Savola , idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: <20040302003314.GA6255@vijaygill.com> References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> <200403020025.i220PI9P050138@roque-bsd.juniper.net> <20040302003314.GA6255@vijaygill.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 16:41:58 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit vijay gill writes: > On Mon, Mar 01, 2004 at 04:25:18PM -0800, Pedro Roque Marques wrote: >> Pekka Savola writes: >> >> i'll repeat it: - How can you prove that a given path that is >> learned by BGP is loop free ? - That can only be done if >> forwarding follows routing. > I feel that BGP should only be concerned about creating loop free > topologies. If the user then has a mechanism where the forwarding > does not follow the routing properly and causes a loop (this is an > important distinction), then this is their problem. I can always > point a static back up a link if I so want and nothing bgp can do > about it. Your argument assumes that the user always knows that is configuring a situation that may create forwarding loops... That may not be the case. It may come from a configuration mistake... imho, the default approach for the protocol spec is to choose the most graceful failure model possible torwards loop-free forwarding... >> Proof: configure a static route for a given prefix in a border >> router that points to a BGP neighbor that selects this router as >> best path... watch permanent forwarding loops. > Yes, and this is a not a matter for BGP to worry about. I respectfully disagree. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 19:47:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16756 for ; Mon, 1 Mar 2004 19:47:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axy3u-0000CM-MK for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 19:47:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i220l6kU000756 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 19:47:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axy3u-0000C7-Di for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 19:47:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16701 for ; Mon, 1 Mar 2004 19:47:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axy3s-0001io-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:47:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axy30-0001aj-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:46:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axy21-0001Si-00; Mon, 01 Mar 2004 19:45:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axy1w-0008KT-Ev; Mon, 01 Mar 2004 19:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axy17-0008JE-Qb for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:44:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16568 for ; Mon, 1 Mar 2004 19:44:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axy16-0001Kt-00 for idr@ietf.org; Mon, 01 Mar 2004 19:44:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axy0E-0001EG-00 for idr@ietf.org; Mon, 01 Mar 2004 19:43:18 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AxxzQ-00010k-00 for idr@ietf.org; Mon, 01 Mar 2004 19:42:28 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i220fw1K050176; Mon, 1 Mar 2004 16:41:58 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i220fwFm050173; Mon, 1 Mar 2004 16:41:58 -0800 (PST) Message-Id: <200403020041.i220fwFm050173@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: vijay gill Cc: Pekka Savola , idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: <20040302003314.GA6255@vijaygill.com> References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> <200403020025.i220PI9P050138@roque-bsd.juniper.net> <20040302003314.GA6255@vijaygill.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 16:41:58 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit vijay gill writes: > On Mon, Mar 01, 2004 at 04:25:18PM -0800, Pedro Roque Marques wrote: >> Pekka Savola writes: >> >> i'll repeat it: - How can you prove that a given path that is >> learned by BGP is loop free ? - That can only be done if >> forwarding follows routing. > I feel that BGP should only be concerned about creating loop free > topologies. If the user then has a mechanism where the forwarding > does not follow the routing properly and causes a loop (this is an > important distinction), then this is their problem. I can always > point a static back up a link if I so want and nothing bgp can do > about it. Your argument assumes that the user always knows that is configuring a situation that may create forwarding loops... That may not be the case. It may come from a configuration mistake... imho, the default approach for the protocol spec is to choose the most graceful failure model possible torwards loop-free forwarding... >> Proof: configure a static route for a given prefix in a border >> router that points to a BGP neighbor that selects this router as >> best path... watch permanent forwarding loops. > Yes, and this is a not a matter for BGP to worry about. I respectfully disagree. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 19:50:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16934 for ; Mon, 1 Mar 2004 19:50:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axy6n-00026P-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:50:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axy5p-0001xv-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:49:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axy4v-0001r3-00; Mon, 01 Mar 2004 19:48:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axy4n-0000ZS-3B; Mon, 01 Mar 2004 19:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axy3p-000075-Mh for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:47:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16668 for ; Mon, 1 Mar 2004 19:46:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axy3n-0001iC-00 for idr@ietf.org; Mon, 01 Mar 2004 19:46:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axy2p-0001Z6-00 for idr@ietf.org; Mon, 01 Mar 2004 19:45:59 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1Axy1p-0001Mc-00 for idr@ietf.org; Mon, 01 Mar 2004 19:44:57 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 723C22D48B4; Mon, 1 Mar 2004 19:44:28 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 42048-01-55; Mon, 1 Mar 2004 19:44:27 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 720632D4838; Mon, 1 Mar 2004 19:44:27 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i220iR721796; Mon, 1 Mar 2004 19:44:27 -0500 (EST) From: Jeffrey Haas To: curtis@fictitious.org Cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes Message-ID: <20040301194427.B16130@nexthop.com> References: <01da01c3ffcc$03125450$c8922799@mcilink.com> <200403012044.i21KijRX074248@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200403012044.i21KijRX074248@workhorse.fictitious.org>; from curtis@workhorse.fictitious.org on Mon, Mar 01, 2004 at 03:44:45PM -0500 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 19:44:27 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, Mar 01, 2004 at 03:44:45PM -0500, Curtis Villamizar wrote: > Then the aggregate is locally generated and it is very easy to exclude > the parts of an aggregate that you generated but are not covered by > more specific from the reachability test and it makes perfectly good > sense to do so. If other prefixes in the AS match that aggregate then > the aggregate is generated but locally it is installed as a discard > route. > > I suppose this is the original reason that the discard route was > mentioned, but with a failure to mention the entire context. It took me a second to remember, but to dredge up the ghost from the last time this thread came around: rfc 1519, section 4.2.2: : 4.2. Rules for route advertisement : [...] : 2. A routing domain which performs summarization of multiple : routes must discard packets which match the summarization but : do not match any of the explicit routes which makes up the : summarization. This is necessary to prevent routing loops in : the presence of less-specific information (such as a default : route). Implementation note - one simple way to implement : this rule would be for the border router to maintain a "sink" : route for each of its aggregations. By the rule of longest : match, this would cause all traffic destined to components of : the aggregation which are not explicitly known to be : discarded. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 19:50:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17033 for ; Mon, 1 Mar 2004 19:50:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axy6p-0000yE-Pj for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 19:50:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i220o7Nq003724 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 19:50:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axy6p-0000xz-ME for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 19:50:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16952 for ; Mon, 1 Mar 2004 19:50:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axy6n-00026U-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:50:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axy5q-0001y3-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:49:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axy4v-0001r3-00; Mon, 01 Mar 2004 19:48:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axy4n-0000ZS-3B; Mon, 01 Mar 2004 19:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axy3p-000075-Mh for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:47:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16668 for ; Mon, 1 Mar 2004 19:46:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axy3n-0001iC-00 for idr@ietf.org; Mon, 01 Mar 2004 19:46:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axy2p-0001Z6-00 for idr@ietf.org; Mon, 01 Mar 2004 19:45:59 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1Axy1p-0001Mc-00 for idr@ietf.org; Mon, 01 Mar 2004 19:44:57 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 723C22D48B4; Mon, 1 Mar 2004 19:44:28 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 42048-01-55; Mon, 1 Mar 2004 19:44:27 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 720632D4838; Mon, 1 Mar 2004 19:44:27 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i220iR721796; Mon, 1 Mar 2004 19:44:27 -0500 (EST) From: Jeffrey Haas To: curtis@fictitious.org Cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes Message-ID: <20040301194427.B16130@nexthop.com> References: <01da01c3ffcc$03125450$c8922799@mcilink.com> <200403012044.i21KijRX074248@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200403012044.i21KijRX074248@workhorse.fictitious.org>; from curtis@workhorse.fictitious.org on Mon, Mar 01, 2004 at 03:44:45PM -0500 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 19:44:27 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, Mar 01, 2004 at 03:44:45PM -0500, Curtis Villamizar wrote: > Then the aggregate is locally generated and it is very easy to exclude > the parts of an aggregate that you generated but are not covered by > more specific from the reachability test and it makes perfectly good > sense to do so. If other prefixes in the AS match that aggregate then > the aggregate is generated but locally it is installed as a discard > route. > > I suppose this is the original reason that the discard route was > mentioned, but with a failure to mention the entire context. It took me a second to remember, but to dredge up the ghost from the last time this thread came around: rfc 1519, section 4.2.2: : 4.2. Rules for route advertisement : [...] : 2. A routing domain which performs summarization of multiple : routes must discard packets which match the summarization but : do not match any of the explicit routes which makes up the : summarization. This is necessary to prevent routing loops in : the presence of less-specific information (such as a default : route). Implementation note - one simple way to implement : this rule would be for the border router to maintain a "sink" : route for each of its aggregations. By the rule of longest : match, this would cause all traffic destined to components of : the aggregation which are not explicitly known to be : discarded. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 19:58:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17360 for ; Mon, 1 Mar 2004 19:58:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyEU-00030T-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:58:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxyDX-0002tK-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 19:57:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxyCc-0002mw-00; Mon, 01 Mar 2004 19:56:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyCX-0001Nz-T4; Mon, 01 Mar 2004 19:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyBl-0001Eb-3g for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:55:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17247 for ; Mon, 1 Mar 2004 19:55:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyBj-0002gz-00 for idr@ietf.org; Mon, 01 Mar 2004 19:55:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxyAr-0002ac-00 for idr@ietf.org; Mon, 01 Mar 2004 19:54:17 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyA4-0002OD-00 for idr@ietf.org; Mon, 01 Mar 2004 19:53:28 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i220qvR15465; Tue, 2 Mar 2004 02:52:57 +0200 From: Pekka Savola To: Jeffrey Haas cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <20040301192732.A21492@nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 02:52:57 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 1 Mar 2004, Jeffrey Haas wrote: > On Tue, Mar 02, 2004 at 01:41:41AM +0200, Pekka Savola wrote: > > I guess you weren't following. Discard routes are set up because > > folks want to announce that aggregate route to their peers. That's > > not a "very unusual circumstance". > > If I'm following you correctly, here's an example of the condition that > you're talking about. > > C > /| > A | > \| > B > > B has prefix D1 - 192/17 > C has prefix D2 - 192.128/17 > > B and C advertises these routes with loopback addresses. (next-hop-self) > > A synthesizes an aggregate, 192/16 using B and C's routes as contributors. > A thus installs 192/16 in it's FIB as a reject route per accepted > practice. We're doing "manual aggregation" by adding the 192/16 manually as a discard route, and filtering out the more specifics when advertising to peers, but the end result is the same. > C is nuked from space in a green fireball. > > Prior to BGP figuring out that C has gone away, C's loopback is no longer > advertised, leaving B to use the aggregate from A to calculate the > resolved nexthop for D2. Thus, B has a route to D2 via A, which will > eventually reach a reject route. > > Is this your scenario? Yep -- there two flavors here: 1) looking from A's perspective -- the route to C is known to be a reject route by A. 2) looking from B's perspective -- the route to C goes to A, where the packets are rejected. B does not, in BGP, know that the route is a reject route at A. 1) is the root cause; 2) can be worked around by installing "reject" routes on all boxes. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 20:14:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18394 for ; Mon, 1 Mar 2004 20:14:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyU2-00052B-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 20:14:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxyT3-0004sb-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 20:13:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxyS8-0004kJ-00; Mon, 01 Mar 2004 20:12:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyS2-0004UG-5P; Mon, 01 Mar 2004 20:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyRN-0004RM-6d for idr@optimus.ietf.org; Mon, 01 Mar 2004 20:11:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18277 for ; Mon, 1 Mar 2004 20:11:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyRL-0004dY-00 for idr@ietf.org; Mon, 01 Mar 2004 20:11:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxyQU-0004We-00 for idr@ietf.org; Mon, 01 Mar 2004 20:10:27 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AxyPo-0004NA-00 for idr@ietf.org; Mon, 01 Mar 2004 20:09:44 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A2A332D480C; Mon, 1 Mar 2004 20:09:15 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 43228-01-2; Mon, 1 Mar 2004 20:09:14 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A0BB52D4804; Mon, 1 Mar 2004 20:09:14 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i2219Eg22046; Mon, 1 Mar 2004 20:09:14 -0500 (EST) From: Jeffrey Haas To: Pekka Savola Cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes Message-ID: <20040301200914.C16130@nexthop.com> References: <20040301192732.A21492@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pekkas@netcore.fi on Tue, Mar 02, 2004 at 02:52:57AM +0200 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 20:09:14 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Please excuse the long citation. On Tue, Mar 02, 2004 at 02:52:57AM +0200, Pekka Savola wrote: > > C > > /| > > A | > > \| > > B > > > > B has prefix D1 - 192/17 > > C has prefix D2 - 192.128/17 > > > > B and C advertises these routes with loopback addresses. (next-hop-self) > > > > A synthesizes an aggregate, 192/16 using B and C's routes as contributors. > > A thus installs 192/16 in it's FIB as a reject route per accepted > > practice. > > We're doing "manual aggregation" by adding the 192/16 manually as a > discard route, and filtering out the more specifics when advertising > to peers, but the end result is the same. A, B and C are all within a given AS. Regardless of whether A propagates B and C's more specifics to peers outside of this AS isn't important to this particular scenario. To be clear, we may consider A, B and C to be egress routers for this AS and B and C will propagate the aggregate synthesized by A and learned via iBGP. Note that as has been mentioned multiple times, this is not common practice - C and B should be configured to synthesize the aggregate as well, but this will work "ok" without it. > > C is nuked from space in a green fireball. > > > > Prior to BGP figuring out that C has gone away, C's loopback is no longer > > advertised, leaving B to use the aggregate from A to calculate the > > resolved nexthop for D2. Thus, B has a route to D2 via A, which will > > eventually reach a reject route. > > > > Is this your scenario? > > Yep -- there two flavors here: > 1) looking from A's perspective -- the route to C is known to be a > reject route by A. We're fine here. > 2) looking from B's perspective -- the route to C goes to A, where > the packets are rejected. B does not, in BGP, know that the route is a > reject route at A. And thus packets that arrive at B will be propagated to A and be consumed by the reject route. And this is not fine how? The ideal scenario is that each core router within the AS knows all of the routes to networks within an AS. Once a packet hits one of these routers, that router will generate ICMP destination unreachable. In our scenario above, we provide a routing sink that attracts packets that otherwise would be generating ICMP further into the network, but the right thing continues to happen. If we're being clever, we may be doing this intentionally with a default sink as an attempt to collect statistics about packets being sent to hosts within our network that appear outside advertised aggregates for purposes of intrusion detection or something else. At no time does this break routing. What the above scenario indicates is that the network isn't being configured well. Ideally (and please feel to shoot this down based on operational experience): o Aggregation happens at your AS border routers. Every single one of them. o You do not inject your aggregates into your iBGP. o You do not advertised more specifics covered by an announced aggregate unless you are doing intentional traffic engineering. If you are, you're preferably working with your upstream ISPs to make sure those routes aren't propagated "too far" in attempt to keep the Internet routing table clean. One example is tagging the routes with the NO_EXPORT community. However, if you fail in one of the above, routing will still work. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 20:14:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18514 for ; Mon, 1 Mar 2004 20:14:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyU5-0004ui-Rc for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 20:14:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i221E9vU018882 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 20:14:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyU5-0004uT-Mg for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 20:14:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18412 for ; Mon, 1 Mar 2004 20:14:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyU3-00052G-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 20:14:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxyT4-0004si-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 20:13:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxyS8-0004kJ-00; Mon, 01 Mar 2004 20:12:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyS2-0004UG-5P; Mon, 01 Mar 2004 20:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyRN-0004RM-6d for idr@optimus.ietf.org; Mon, 01 Mar 2004 20:11:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18277 for ; Mon, 1 Mar 2004 20:11:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyRL-0004dY-00 for idr@ietf.org; Mon, 01 Mar 2004 20:11:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxyQU-0004We-00 for idr@ietf.org; Mon, 01 Mar 2004 20:10:27 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AxyPo-0004NA-00 for idr@ietf.org; Mon, 01 Mar 2004 20:09:44 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A2A332D480C; Mon, 1 Mar 2004 20:09:15 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 43228-01-2; Mon, 1 Mar 2004 20:09:14 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A0BB52D4804; Mon, 1 Mar 2004 20:09:14 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i2219Eg22046; Mon, 1 Mar 2004 20:09:14 -0500 (EST) From: Jeffrey Haas To: Pekka Savola Cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes Message-ID: <20040301200914.C16130@nexthop.com> References: <20040301192732.A21492@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pekkas@netcore.fi on Tue, Mar 02, 2004 at 02:52:57AM +0200 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 20:09:14 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Please excuse the long citation. On Tue, Mar 02, 2004 at 02:52:57AM +0200, Pekka Savola wrote: > > C > > /| > > A | > > \| > > B > > > > B has prefix D1 - 192/17 > > C has prefix D2 - 192.128/17 > > > > B and C advertises these routes with loopback addresses. (next-hop-self) > > > > A synthesizes an aggregate, 192/16 using B and C's routes as contributors. > > A thus installs 192/16 in it's FIB as a reject route per accepted > > practice. > > We're doing "manual aggregation" by adding the 192/16 manually as a > discard route, and filtering out the more specifics when advertising > to peers, but the end result is the same. A, B and C are all within a given AS. Regardless of whether A propagates B and C's more specifics to peers outside of this AS isn't important to this particular scenario. To be clear, we may consider A, B and C to be egress routers for this AS and B and C will propagate the aggregate synthesized by A and learned via iBGP. Note that as has been mentioned multiple times, this is not common practice - C and B should be configured to synthesize the aggregate as well, but this will work "ok" without it. > > C is nuked from space in a green fireball. > > > > Prior to BGP figuring out that C has gone away, C's loopback is no longer > > advertised, leaving B to use the aggregate from A to calculate the > > resolved nexthop for D2. Thus, B has a route to D2 via A, which will > > eventually reach a reject route. > > > > Is this your scenario? > > Yep -- there two flavors here: > 1) looking from A's perspective -- the route to C is known to be a > reject route by A. We're fine here. > 2) looking from B's perspective -- the route to C goes to A, where > the packets are rejected. B does not, in BGP, know that the route is a > reject route at A. And thus packets that arrive at B will be propagated to A and be consumed by the reject route. And this is not fine how? The ideal scenario is that each core router within the AS knows all of the routes to networks within an AS. Once a packet hits one of these routers, that router will generate ICMP destination unreachable. In our scenario above, we provide a routing sink that attracts packets that otherwise would be generating ICMP further into the network, but the right thing continues to happen. If we're being clever, we may be doing this intentionally with a default sink as an attempt to collect statistics about packets being sent to hosts within our network that appear outside advertised aggregates for purposes of intrusion detection or something else. At no time does this break routing. What the above scenario indicates is that the network isn't being configured well. Ideally (and please feel to shoot this down based on operational experience): o Aggregation happens at your AS border routers. Every single one of them. o You do not inject your aggregates into your iBGP. o You do not advertised more specifics covered by an announced aggregate unless you are doing intentional traffic engineering. If you are, you're preferably working with your upstream ISPs to make sure those routes aren't propagated "too far" in attempt to keep the Internet routing table clean. One example is tagging the routes with the NO_EXPORT community. However, if you fail in one of the above, routing will still work. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 20:26:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19545 for ; Mon, 1 Mar 2004 20:26:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axyfj-0007Bf-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 20:26:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axyef-00071b-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 20:25:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axydj-0006sU-00; Mon, 01 Mar 2004 20:24:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axydd-00062b-J6; Mon, 01 Mar 2004 20:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axycm-0005xY-N9 for idr@optimus.ietf.org; Mon, 01 Mar 2004 20:23:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19239 for ; Mon, 1 Mar 2004 20:23:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axyck-0006dp-00 for idr@ietf.org; Mon, 01 Mar 2004 20:23:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axyb0-0006Hp-00 for idr@ietf.org; Mon, 01 Mar 2004 20:21:19 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyZB-0005mK-00 for idr@ietf.org; Mon, 01 Mar 2004 20:19:25 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i221IeS15962; Tue, 2 Mar 2004 03:18:40 +0200 From: Pekka Savola To: curtis@fictitious.org cc: Parantap Lahiri , "'John G. Scudder'" , Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <200403020106.i2216XRX077511@workhorse.fictitious.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 03:18:40 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 1 Mar 2004, Curtis Villamizar wrote: > Yes I was following. You just didn't read the paragraph that was > immediately above this one, which you also conveniently chopped off. > The paragraph you omitted said: > > Then the aggregate is locally generated and it is very easy to > exclude the parts of an aggregate that you generated but are not > covered by more specific from the reachability test and it makes > perfectly good sense to do so. If other prefixes in the AS match > that aggregate then the aggregate is generated but locally it is > installed as a discard route. > > I'm agreeing with the original point just mentioning that the original > point wasn't clear. It was (or _is_) not clear whether you consider this to be the status quo or not. My interpretation of the spec (and a vendor's, as well) is that this is not considered at all in the current spec. And if we disagree, it calls for EVEN MORE LOUDLY for a clarification! > > > No need to modify the spec. If you've installed a special type of > > > route in the kernel that is there explicitly to indicate > > > non-reachability, then that route should not be allowed to indicate > > > reachability. I dont' think we really need to say that. > > > > You would think so, but the current spec does not say so. > > The bgp3-23 test just mentions route. If you interpret that to > include discard routes you simply have a bug in your implementation. > It is quite easy to just look for something in the FIB radix trie and > if you find something declare that is satisfied the reachability > criteria without looking at what it was you found (a discard route). No -- the current spec is just looking up a route -- it takes no stance what kind of 'route' that is. This needs to be specified. Of course, it'd be nice to fix the implementation I'm having problems with. But being altruistic, and wanting to fix this problem for others as well, this needs to be specified, somehow, in the spec to avoid this issue being misinterpreted. My assumption is that the implementation must work properly, if implemented to the letter of the spec. That's not the case now. Anything that requires the implementor to "use non-obvious interpretation of the spec" is a potential missing (or badly written) item from the spec. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 20:26:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19629 for ; Mon, 1 Mar 2004 20:26:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axyfm-0006Tz-42 for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 20:26:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i221QE0F024918 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 20:26:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axyfl-0006Tp-UD for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 20:26:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19548 for ; Mon, 1 Mar 2004 20:26:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axyfj-0007Bl-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 20:26:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axyeg-00071j-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 20:25:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axydj-0006sU-00; Mon, 01 Mar 2004 20:24:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axydd-00062b-J6; Mon, 01 Mar 2004 20:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axycm-0005xY-N9 for idr@optimus.ietf.org; Mon, 01 Mar 2004 20:23:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19239 for ; Mon, 1 Mar 2004 20:23:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axyck-0006dp-00 for idr@ietf.org; Mon, 01 Mar 2004 20:23:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axyb0-0006Hp-00 for idr@ietf.org; Mon, 01 Mar 2004 20:21:19 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyZB-0005mK-00 for idr@ietf.org; Mon, 01 Mar 2004 20:19:25 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i221IeS15962; Tue, 2 Mar 2004 03:18:40 +0200 From: Pekka Savola To: curtis@fictitious.org cc: Parantap Lahiri , "'John G. Scudder'" , Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <200403020106.i2216XRX077511@workhorse.fictitious.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 03:18:40 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 1 Mar 2004, Curtis Villamizar wrote: > Yes I was following. You just didn't read the paragraph that was > immediately above this one, which you also conveniently chopped off. > The paragraph you omitted said: > > Then the aggregate is locally generated and it is very easy to > exclude the parts of an aggregate that you generated but are not > covered by more specific from the reachability test and it makes > perfectly good sense to do so. If other prefixes in the AS match > that aggregate then the aggregate is generated but locally it is > installed as a discard route. > > I'm agreeing with the original point just mentioning that the original > point wasn't clear. It was (or _is_) not clear whether you consider this to be the status quo or not. My interpretation of the spec (and a vendor's, as well) is that this is not considered at all in the current spec. And if we disagree, it calls for EVEN MORE LOUDLY for a clarification! > > > No need to modify the spec. If you've installed a special type of > > > route in the kernel that is there explicitly to indicate > > > non-reachability, then that route should not be allowed to indicate > > > reachability. I dont' think we really need to say that. > > > > You would think so, but the current spec does not say so. > > The bgp3-23 test just mentions route. If you interpret that to > include discard routes you simply have a bug in your implementation. > It is quite easy to just look for something in the FIB radix trie and > if you find something declare that is satisfied the reachability > criteria without looking at what it was you found (a discard route). No -- the current spec is just looking up a route -- it takes no stance what kind of 'route' that is. This needs to be specified. Of course, it'd be nice to fix the implementation I'm having problems with. But being altruistic, and wanting to fix this problem for others as well, this needs to be specified, somehow, in the spec to avoid this issue being misinterpreted. My assumption is that the implementation must work properly, if implemented to the letter of the spec. That's not the case now. Anything that requires the implementor to "use non-obvious interpretation of the spec" is a potential missing (or badly written) item from the spec. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 20:43:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20774 for ; Mon, 1 Mar 2004 20:43:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axyw9-0001fL-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 20:43:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxyvA-0001WJ-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 20:42:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxyuF-0001OU-00; Mon, 01 Mar 2004 20:41:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axyu7-0000n8-5H; Mon, 01 Mar 2004 20:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxytL-0000lG-Ps for idr@optimus.ietf.org; Mon, 01 Mar 2004 20:40:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20538 for ; Mon, 1 Mar 2004 20:40:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxytJ-0001GQ-00 for idr@ietf.org; Mon, 01 Mar 2004 20:40:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxysH-00019a-00 for idr@ietf.org; Mon, 01 Mar 2004 20:39:10 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyrH-0000xh-00 for idr@ietf.org; Mon, 01 Mar 2004 20:38:07 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i221bZp16232; Tue, 2 Mar 2004 03:37:36 +0200 From: Pekka Savola To: Jeffrey Haas cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <20040301200914.C16130@nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 03:37:35 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 1 Mar 2004, Jeffrey Haas wrote: > > Yep -- there two flavors here: > > 1) looking from A's perspective -- the route to C is known to be a > > reject route by A. > > We're fine here. We'll, not sure what you mean. I don't think "we're fine here" is a good choice of words, because that's the actual problem I was reporting -- one which is not covered by the specification! > > 2) looking from B's perspective -- the route to C goes to A, where > > the packets are rejected. B does not, in BGP, know that the route is a > > reject route at A. > > And thus packets that arrive at B will be propagated to A and be > consumed by the reject route. > > And this is not fine how? I can accept this behaviour, but 1), above is unacceptable. > The ideal scenario is that each core router within the AS knows all > of the routes to networks within an AS. Once a packet hits one of > these routers, that router will generate ICMP destination unreachable. Agreed. > In our scenario above, we provide a routing sink that attracts packets > that otherwise would be generating ICMP further into the network, > but the right thing continues to happen. If we're being clever, > we may be doing this intentionally with a default sink as an attempt > to collect statistics about packets being sent to hosts within our > network that appear outside advertised aggregates for purposes of > intrusion detection or something else. But such a packet sink breaks route resolvability -- all the routers which do not have the reject route -- assuming that problem 1) above will be fixed -- will continue to have their iBGP sessions up. This is, AFAICS, in conflict with two of your goals below. > At no time does this break routing. What the above scenario indicates > is that the network isn't being configured well. I think you're assuming that 1) is a non-problem. It is a real problem. But assuming it isn't.. > Ideally (and please feel to shoot this down based on operational > experience): > o Aggregation happens at your AS border routers. Every single one of them. > o You do not inject your aggregates into your iBGP. These are desirable goals, yes. Actually, they are just one goal, worded differently -- if you don't aggregate everywhere, you have to have the aggregates in your iBGP, no question about it. Excluding misconfigurations (such as unintentional aggregate advertisement to iBGP unnecesarily), practically, either you break zero or you break both. Practically, these are not always feasible. E.g., we use private ASns in access networks, so each core router connecting to an access network has EBGP and would have to aggregate (we're just advertising the default). This is "aggregation in all of the borders" is a bit cumbersome, but we could add it if that would make the network "more correct" and make it work better. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 20:43:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20871 for ; Mon, 1 Mar 2004 20:43:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxywD-0001Ss-2Z for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 20:43:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i221hDEq005624 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 20:43:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxywC-0001Sd-Ot for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 20:43:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20792 for ; Mon, 1 Mar 2004 20:43:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxywA-0001fS-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 20:43:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxyvB-0001WS-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 20:42:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxyuF-0001OU-00; Mon, 01 Mar 2004 20:41:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axyu7-0000n8-5H; Mon, 01 Mar 2004 20:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxytL-0000lG-Ps for idr@optimus.ietf.org; Mon, 01 Mar 2004 20:40:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20538 for ; Mon, 1 Mar 2004 20:40:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxytJ-0001GQ-00 for idr@ietf.org; Mon, 01 Mar 2004 20:40:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxysH-00019a-00 for idr@ietf.org; Mon, 01 Mar 2004 20:39:10 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyrH-0000xh-00 for idr@ietf.org; Mon, 01 Mar 2004 20:38:07 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i221bZp16232; Tue, 2 Mar 2004 03:37:36 +0200 From: Pekka Savola To: Jeffrey Haas cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <20040301200914.C16130@nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 03:37:35 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 1 Mar 2004, Jeffrey Haas wrote: > > Yep -- there two flavors here: > > 1) looking from A's perspective -- the route to C is known to be a > > reject route by A. > > We're fine here. We'll, not sure what you mean. I don't think "we're fine here" is a good choice of words, because that's the actual problem I was reporting -- one which is not covered by the specification! > > 2) looking from B's perspective -- the route to C goes to A, where > > the packets are rejected. B does not, in BGP, know that the route is a > > reject route at A. > > And thus packets that arrive at B will be propagated to A and be > consumed by the reject route. > > And this is not fine how? I can accept this behaviour, but 1), above is unacceptable. > The ideal scenario is that each core router within the AS knows all > of the routes to networks within an AS. Once a packet hits one of > these routers, that router will generate ICMP destination unreachable. Agreed. > In our scenario above, we provide a routing sink that attracts packets > that otherwise would be generating ICMP further into the network, > but the right thing continues to happen. If we're being clever, > we may be doing this intentionally with a default sink as an attempt > to collect statistics about packets being sent to hosts within our > network that appear outside advertised aggregates for purposes of > intrusion detection or something else. But such a packet sink breaks route resolvability -- all the routers which do not have the reject route -- assuming that problem 1) above will be fixed -- will continue to have their iBGP sessions up. This is, AFAICS, in conflict with two of your goals below. > At no time does this break routing. What the above scenario indicates > is that the network isn't being configured well. I think you're assuming that 1) is a non-problem. It is a real problem. But assuming it isn't.. > Ideally (and please feel to shoot this down based on operational > experience): > o Aggregation happens at your AS border routers. Every single one of them. > o You do not inject your aggregates into your iBGP. These are desirable goals, yes. Actually, they are just one goal, worded differently -- if you don't aggregate everywhere, you have to have the aggregates in your iBGP, no question about it. Excluding misconfigurations (such as unintentional aggregate advertisement to iBGP unnecesarily), practically, either you break zero or you break both. Practically, these are not always feasible. E.g., we use private ASns in access networks, so each core router connecting to an access network has EBGP and would have to aggregate (we're just advertising the default). This is "aggregation in all of the borders" is a bit cumbersome, but we could add it if that would make the network "more correct" and make it work better. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 21:01:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22169 for ; Mon, 1 Mar 2004 21:01:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxzDV-0004FF-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 21:01:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxzCU-00047W-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 21:00:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxzBY-0003z9-00; Mon, 01 Mar 2004 20:59:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzBV-0003Ro-5a; Mon, 01 Mar 2004 20:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzAn-0003Qc-T6 for idr@optimus.ietf.org; Mon, 01 Mar 2004 20:58:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22012 for ; Mon, 1 Mar 2004 20:58:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxzAl-0003sB-00 for idr@ietf.org; Mon, 01 Mar 2004 20:58:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axz9v-0003lI-00 for idr@ietf.org; Mon, 01 Mar 2004 20:57:23 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1Axz9D-0003aS-00 for idr@ietf.org; Mon, 01 Mar 2004 20:56:39 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i221uA1K050328; Mon, 1 Mar 2004 17:56:10 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i221u9jf050325; Mon, 1 Mar 2004 17:56:09 -0800 (PST) Message-Id: <200403020156.i221u9jf050325@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pekka Savola Cc: Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: References: <200403020106.i2216XRX077511@workhorse.fictitious.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 17:56:09 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Pekka Savola writes: > My interpretation of the spec (and a vendor's, as well) is that this > is not considered at all in the current spec. And if we disagree, > it calls for EVEN MORE LOUDLY for a clarification! [...] > No -- the current spec is just looking up a route -- it takes no > stance what kind of 'route' that is. By your own admission the spec doesn't require clarification. It is clear that it doesn't understand the next-hop type of a route. > This needs to be specified. What you mean by this is that you believe that the current behaviour should be modified... Even if we where to agree that the behaviour you and Curtis propose is more desirable than the current one, it isn't feasible to modify the behaviour of current systems. The modification you propose also isn't suficient to address the problem that you point out whenever your aggregate route has a reachable next-hop. Examples where this could happen: - User wants to forward all traffic that hits the default route to a remote box that analyzes traffic... i.e. 0/0 to an LSP to a traffic collector. - Network is divided in areas but has global IGP. Each area border generates a summary of address in the are that is propagated across the network. i.e. outside the area you see an aggregate via BGP and more specific /32s. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 21:01:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22244 for ; Mon, 1 Mar 2004 21:01:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzDY-0003dr-Tn for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 21:01:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22218VM013998 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 21:01:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzDY-0003dh-NY for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 21:01:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22187 for ; Mon, 1 Mar 2004 21:01:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxzDW-0004FM-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 21:01:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxzCV-00047d-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 21:00:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxzBY-0003z9-00; Mon, 01 Mar 2004 20:59:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzBV-0003Ro-5a; Mon, 01 Mar 2004 20:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzAn-0003Qc-T6 for idr@optimus.ietf.org; Mon, 01 Mar 2004 20:58:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22012 for ; Mon, 1 Mar 2004 20:58:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxzAl-0003sB-00 for idr@ietf.org; Mon, 01 Mar 2004 20:58:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axz9v-0003lI-00 for idr@ietf.org; Mon, 01 Mar 2004 20:57:23 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1Axz9D-0003aS-00 for idr@ietf.org; Mon, 01 Mar 2004 20:56:39 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i221uA1K050328; Mon, 1 Mar 2004 17:56:10 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i221u9jf050325; Mon, 1 Mar 2004 17:56:09 -0800 (PST) Message-Id: <200403020156.i221u9jf050325@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pekka Savola Cc: Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: References: <200403020106.i2216XRX077511@workhorse.fictitious.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 17:56:09 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola writes: > My interpretation of the spec (and a vendor's, as well) is that this > is not considered at all in the current spec. And if we disagree, > it calls for EVEN MORE LOUDLY for a clarification! [...] > No -- the current spec is just looking up a route -- it takes no > stance what kind of 'route' that is. By your own admission the spec doesn't require clarification. It is clear that it doesn't understand the next-hop type of a route. > This needs to be specified. What you mean by this is that you believe that the current behaviour should be modified... Even if we where to agree that the behaviour you and Curtis propose is more desirable than the current one, it isn't feasible to modify the behaviour of current systems. The modification you propose also isn't suficient to address the problem that you point out whenever your aggregate route has a reachable next-hop. Examples where this could happen: - User wants to forward all traffic that hits the default route to a remote box that analyzes traffic... i.e. 0/0 to an LSP to a traffic collector. - Network is divided in areas but has global IGP. Each area border generates a summary of address in the are that is propagated across the network. i.e. outside the area you see an aggregate via BGP and more specific /32s. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 21:47:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24845 for ; Mon, 1 Mar 2004 21:47:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axzwj-0002Vw-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 21:47:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axzvc-0002JF-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 21:46:41 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Axzux-00028H-00; Mon, 01 Mar 2004 21:45:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Axzhr-0007Uf-VO; Mon, 01 Mar 2004 21:32:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzhR-0007I1-Fr; Mon, 01 Mar 2004 21:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axzgj-0007F9-De for idr@optimus.ietf.org; Mon, 01 Mar 2004 21:31:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24322 for ; Mon, 1 Mar 2004 21:31:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axzgg-0000l2-00 for idr@ietf.org; Mon, 01 Mar 2004 21:31:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axzfl-0000bG-00 for idr@ietf.org; Mon, 01 Mar 2004 21:30:18 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Axzeu-0000Jm-00 for idr@ietf.org; Mon, 01 Mar 2004 21:29:24 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 01 Mar 2004 18:28:52 -0800 Received: from cisco.com (hkidc-vpn-client-234-14.cisco.com [10.75.234.14]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i222SjLB011026; Mon, 1 Mar 2004 18:28:46 -0800 (PST) Message-ID: <4043F15B.7000400@cisco.com> From: Gargi Nalawade Reply-To: gargi@cisco.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pedro Roque Marques CC: Pekka Savola , idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> <200403020034.i220Ytrh050157@roque-bsd.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 18:28:43 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Pedro, > The issue is "what are the drawbacks of advertising a route that is > not used for forwarding". I agree that BGP should not advertise a route not used for forwarding, to the extent that the route used for forwarding means same nexthop. If BGP is not the owner of the route, but the BGP nexthop matches the nexthop of the route in the forwarding table, there is no forwarding loop if BGP advertises the route. Things work perfectly fine. Pekka, Are you asking that BGP advertise a route even if the nexthop of the route in the forwarding table is different? If so, this definitely breaks routing. As long as the nexthop of the 2 routes are the same, there is no problem. -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 21:48:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25028 for ; Mon, 1 Mar 2004 21:48:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axzwn-0000VA-IT for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 21:47:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i222lrT7001922 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 21:47:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axzwn-0000Uv-Ed for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 21:47:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24865 for ; Mon, 1 Mar 2004 21:47:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axzwk-0002W2-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 21:47:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axzvd-0002JM-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 21:46:41 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Axzux-00028H-00; Mon, 01 Mar 2004 21:45:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Axzhr-0007Uf-VO; Mon, 01 Mar 2004 21:32:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzhR-0007I1-Fr; Mon, 01 Mar 2004 21:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axzgj-0007F9-De for idr@optimus.ietf.org; Mon, 01 Mar 2004 21:31:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24322 for ; Mon, 1 Mar 2004 21:31:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axzgg-0000l2-00 for idr@ietf.org; Mon, 01 Mar 2004 21:31:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axzfl-0000bG-00 for idr@ietf.org; Mon, 01 Mar 2004 21:30:18 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Axzeu-0000Jm-00 for idr@ietf.org; Mon, 01 Mar 2004 21:29:24 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 01 Mar 2004 18:28:52 -0800 Received: from cisco.com (hkidc-vpn-client-234-14.cisco.com [10.75.234.14]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i222SjLB011026; Mon, 1 Mar 2004 18:28:46 -0800 (PST) Message-ID: <4043F15B.7000400@cisco.com> From: Gargi Nalawade Reply-To: gargi@cisco.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pedro Roque Marques CC: Pekka Savola , idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> <200403020034.i220Ytrh050157@roque-bsd.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 18:28:43 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pedro, > The issue is "what are the drawbacks of advertising a route that is > not used for forwarding". I agree that BGP should not advertise a route not used for forwarding, to the extent that the route used for forwarding means same nexthop. If BGP is not the owner of the route, but the BGP nexthop matches the nexthop of the route in the forwarding table, there is no forwarding loop if BGP advertises the route. Things work perfectly fine. Pekka, Are you asking that BGP advertise a route even if the nexthop of the route in the forwarding table is different? If so, this definitely breaks routing. As long as the nexthop of the 2 routes are the same, there is no problem. -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 22:45:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26855 for ; Mon, 1 Mar 2004 22:45:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay0qF-0000nO-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 22:45:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay0pE-0000eO-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 22:44:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay0oK-0000Xb-00; Mon, 01 Mar 2004 22:43:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay0o9-0002qb-Cj; Mon, 01 Mar 2004 22:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay0nL-0002pd-Mz for idr@optimus.ietf.org; Mon, 01 Mar 2004 22:42:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26811 for ; Mon, 1 Mar 2004 22:42:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay0nI-0000RS-00 for idr@ietf.org; Mon, 01 Mar 2004 22:42:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay0mQ-0000M7-00 for idr@ietf.org; Mon, 01 Mar 2004 22:41:15 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay0m6-0000GM-00 for idr@ietf.org; Mon, 01 Mar 2004 22:40:54 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id CF2232D493F for ; Mon, 1 Mar 2004 22:40:24 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 45584-03-17 for ; Mon, 1 Mar 2004 22:40:23 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7D4BE2D4932 for ; Mon, 1 Mar 2004 22:40:23 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: IDR minutes Thread-Index: AcP/ZbUR5OkElLH7TN2Bea6gcoa+eQAjb2yw From: "Susan Hares" To: X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Subject: [Idr] FW: IDR minutes Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 22:40:23 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Minutes for 3/1/04 session -----Original Message----- From: Jake Khuon=20 Sent: Monday, March 01, 2004 3:18 AM To: Susan Hares; yakov@juniper.net Subject: IDR minutes Inter-Domain Routing WG (idr) Monday, March 1 at 1530-1730 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: Sue Hares (skh@nexthop.com) Yakov Rekhter (yakov@juniper.net) =20 AGENDA: 1) Agenda Bashing Agenda Slides 2) Document status [5 minutes] - Bundle went to IESG BGP-4 draft-23 draft-ietf-idr-bgp4-23.txt BGP-4 V1 MIB draft-ietf-idr-bgp4-mib-13.txt BGP-4 Protocol Analysis draft-ietf-idr-bgp-analysis-04.txt BGP Security Vulnerabilities Analysis draft-ietf-idr-bgp-vuln-00.txt Experience with the BGP-4 Protocol draft-ietf-idr-bgp4-experience-protocol-03.txt BGP 4 Implementation Report draft-ietf-idr-bgp-implementation-00.txt BGP-4 V1 MIB implementation report draft-ietf-idr-bgp-mibagent-survey-01.txt Presentation 3) Implementation Reports and FSM issues for current drafts [10 minutes] document: None, presentation only Presentation Sue Hares - Yakov: route-reflector update status? - Enke: route-reflector update (4 weeks) - Enke: prefix-orf was not added to charter - Sue: yes it was added, administrative error in listing 4) BGP Peer Restart Backoff Mechanisms [10 minutes] document: draft-hares-bgp-backoff-01.txt (ietf) (-02 Update) Author: Susan Hares Presentation Sue Hares - Alex: draft should say informational achieve functionality using existing states? - Sue: no... can't use existing states; already investigated that option 5) Deterministic Route Redistribution into BGP [10 minutes] document: draft-chen-bgp-redist-00.txt Authors: Jenny Yuan, Enke Chen Enke Chen - Andrew Lang: used to use configured localpref tweaking; not management intensive... unsure if this is needed - Enke: timing dependent non-deterministic problem so current knobs cannot be used reliably; does not break anything... backwards compatible - Andrew Lang: better to educate people about localpref - Barry Friedman: lacks generality too narrow a problem space... only addresses RIP/iBGP interaction - Enke: tweaking of admin distance defines a baseline - need per route granularity to solve for all cases?=20 Possibility of adding more configuration conflicts. - Alex: this problem only occurs if there's a consistancy issue between two places... May not be an issue for a single selection point. Introduction of new step will effect current edployment traffic selection? - Enke: This will happen regardless. Should not effect current deployments and if there's a change, the change will be for the better. - By definition, it does change behaviour. - Alex: Will this be applicable to only situations where there is a problem? - Yakov: Is this an implimentation method? - Alex: Is this informational or standards-track? - Enke: Either is fine - It can't be a local matter because it must be consistant throughout the entire system - Enke: Decision on redistributed routes is made locally in each router - Behaviour is changed because new code now uses admin distance over localpref? - Enke: If only localpref is used then things should not change - Cengiz: If route-reflector is used? - Enke: I need to think about it further 6) BGP based auto-discovery [Sue Hares, P. Unbehagen] [10 minutes] document: draft-hlmu-l2vpn-bgp-discovery-00.txt authors: P. Unbehagen, P. Muley, V. Radoaca, Susan Hares Presentation Sue Hares, P. Unbehagen - Already a L2VPN draft that addresses this in a defined NLRI with label information - Paul: This draft is meant to provide LDP pseudowire config information - Other spec can do same thing [autodiscovery] without label information - Kireeti: Would like to be able to use this AFI with different SAFI [65] and NLRI format - Would the two SAFIs be solving similar problems - Kireeti: My SAFI solves different problems 7) BGP Assignment of AFI/SAFI address [10 minutes] Document: draft-hares-bgp-assign-afisafi-00.txt=20 Author: Susan Hares Presentation Sue Hares 8) BGP Attribute Codes and Suggested Procedures Document: draft-kompella-zinin-early-allocation-00.txt Author: Alex Zinin, Kireeti Kompella Presentation Alex Zinin - Sharon: talking about protocols and not OIDs preallocation?=20 bad to preallocate in the MIB... different from what other WGs; exclude MIB OIDs - Kireeti: not suggesting that everyone use this - It would have been nicer to have had OIDs preallocated so as not to reimpliment the MIB =09 - Sharon: OIDs not allocated to drafts because if the drafts goes away then you've wasted numbers - Lou Berger: allocation with 1 year with 1 renewal is too short; alterntate policy: as long as draft or version is alive, expire in 3 to 6 months - Alex: that suggestion ties validity with ability of author to submit the draft; suggestion: once document is submitted to IESG then we freeze. Don't want to allocate codepoints too early. - Dave Meyer: Are you sure that IANA can time anything out - Alex: No - Dave Meyer: WG chair needs to manage this? - What happens if the allocation is not renewed and code is using it still? - Alex: Add provision to document to deprecate but not return - Kireeti: Deprecate for a period of time to give people time to remove. Formal process to do early allocations and if it goes through then stick with it but if it doesn't go through then people must take this out. - Dino: Allocate experimental codepoints and once standardised, then adopt standard codepoint for sending but accept both. - Sue: Good for SAFIs as well as AFIs? - Dino: All well known IANA values - Fenner: RFC already documents a process for transitioning codepoints 9) Charter Discussion [20 minutes] Thanks to all implementers who send in reports on the the base specification, we will be opening the charter. This section of the = meeting will discuss what items will be added to the charter. Presentation - Top three most important; maybe ECMP little higher than Fault = Isolation -- /*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D[ Jake Khuon = = ]=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Field App. Engineer http://www.nexthop.com/ /\ /~ E X T H O = P | | Ofc: +1 (425) 391-2262 Fax: +1 (425) 391-6772 / \/ Technologies, = Inc.| +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D[ 1911 Landings Drive, Mountain View, CA = 94043 USA ]=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 22:45:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26952 for ; Mon, 1 Mar 2004 22:45:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay0qK-000381-0H for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 22:45:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i223jF5p012019 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 22:45:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay0qJ-00037m-NR for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 22:45:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26870 for ; Mon, 1 Mar 2004 22:45:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay0qG-0000nT-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 22:45:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay0pF-0000eW-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 22:44:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay0oK-0000Xb-00; Mon, 01 Mar 2004 22:43:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay0o9-0002qb-Cj; Mon, 01 Mar 2004 22:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay0nL-0002pd-Mz for idr@optimus.ietf.org; Mon, 01 Mar 2004 22:42:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26811 for ; Mon, 1 Mar 2004 22:42:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay0nI-0000RS-00 for idr@ietf.org; Mon, 01 Mar 2004 22:42:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay0mQ-0000M7-00 for idr@ietf.org; Mon, 01 Mar 2004 22:41:15 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay0m6-0000GM-00 for idr@ietf.org; Mon, 01 Mar 2004 22:40:54 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id CF2232D493F for ; Mon, 1 Mar 2004 22:40:24 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 45584-03-17 for ; Mon, 1 Mar 2004 22:40:23 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7D4BE2D4932 for ; Mon, 1 Mar 2004 22:40:23 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: IDR minutes Thread-Index: AcP/ZbUR5OkElLH7TN2Bea6gcoa+eQAjb2yw From: "Susan Hares" To: X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Subject: [Idr] FW: IDR minutes Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 22:40:23 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Minutes for 3/1/04 session -----Original Message----- From: Jake Khuon=20 Sent: Monday, March 01, 2004 3:18 AM To: Susan Hares; yakov@juniper.net Subject: IDR minutes Inter-Domain Routing WG (idr) Monday, March 1 at 1530-1730 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: Sue Hares (skh@nexthop.com) Yakov Rekhter (yakov@juniper.net) =20 AGENDA: 1) Agenda Bashing Agenda Slides 2) Document status [5 minutes] - Bundle went to IESG BGP-4 draft-23 draft-ietf-idr-bgp4-23.txt BGP-4 V1 MIB draft-ietf-idr-bgp4-mib-13.txt BGP-4 Protocol Analysis draft-ietf-idr-bgp-analysis-04.txt BGP Security Vulnerabilities Analysis draft-ietf-idr-bgp-vuln-00.txt Experience with the BGP-4 Protocol draft-ietf-idr-bgp4-experience-protocol-03.txt BGP 4 Implementation Report draft-ietf-idr-bgp-implementation-00.txt BGP-4 V1 MIB implementation report draft-ietf-idr-bgp-mibagent-survey-01.txt Presentation 3) Implementation Reports and FSM issues for current drafts [10 minutes] document: None, presentation only Presentation Sue Hares - Yakov: route-reflector update status? - Enke: route-reflector update (4 weeks) - Enke: prefix-orf was not added to charter - Sue: yes it was added, administrative error in listing 4) BGP Peer Restart Backoff Mechanisms [10 minutes] document: draft-hares-bgp-backoff-01.txt (ietf) (-02 Update) Author: Susan Hares Presentation Sue Hares - Alex: draft should say informational achieve functionality using existing states? - Sue: no... can't use existing states; already investigated that option 5) Deterministic Route Redistribution into BGP [10 minutes] document: draft-chen-bgp-redist-00.txt Authors: Jenny Yuan, Enke Chen Enke Chen - Andrew Lang: used to use configured localpref tweaking; not management intensive... unsure if this is needed - Enke: timing dependent non-deterministic problem so current knobs cannot be used reliably; does not break anything... backwards compatible - Andrew Lang: better to educate people about localpref - Barry Friedman: lacks generality too narrow a problem space... only addresses RIP/iBGP interaction - Enke: tweaking of admin distance defines a baseline - need per route granularity to solve for all cases?=20 Possibility of adding more configuration conflicts. - Alex: this problem only occurs if there's a consistancy issue between two places... May not be an issue for a single selection point. Introduction of new step will effect current edployment traffic selection? - Enke: This will happen regardless. Should not effect current deployments and if there's a change, the change will be for the better. - By definition, it does change behaviour. - Alex: Will this be applicable to only situations where there is a problem? - Yakov: Is this an implimentation method? - Alex: Is this informational or standards-track? - Enke: Either is fine - It can't be a local matter because it must be consistant throughout the entire system - Enke: Decision on redistributed routes is made locally in each router - Behaviour is changed because new code now uses admin distance over localpref? - Enke: If only localpref is used then things should not change - Cengiz: If route-reflector is used? - Enke: I need to think about it further 6) BGP based auto-discovery [Sue Hares, P. Unbehagen] [10 minutes] document: draft-hlmu-l2vpn-bgp-discovery-00.txt authors: P. Unbehagen, P. Muley, V. Radoaca, Susan Hares Presentation Sue Hares, P. Unbehagen - Already a L2VPN draft that addresses this in a defined NLRI with label information - Paul: This draft is meant to provide LDP pseudowire config information - Other spec can do same thing [autodiscovery] without label information - Kireeti: Would like to be able to use this AFI with different SAFI [65] and NLRI format - Would the two SAFIs be solving similar problems - Kireeti: My SAFI solves different problems 7) BGP Assignment of AFI/SAFI address [10 minutes] Document: draft-hares-bgp-assign-afisafi-00.txt=20 Author: Susan Hares Presentation Sue Hares 8) BGP Attribute Codes and Suggested Procedures Document: draft-kompella-zinin-early-allocation-00.txt Author: Alex Zinin, Kireeti Kompella Presentation Alex Zinin - Sharon: talking about protocols and not OIDs preallocation?=20 bad to preallocate in the MIB... different from what other WGs; exclude MIB OIDs - Kireeti: not suggesting that everyone use this - It would have been nicer to have had OIDs preallocated so as not to reimpliment the MIB =09 - Sharon: OIDs not allocated to drafts because if the drafts goes away then you've wasted numbers - Lou Berger: allocation with 1 year with 1 renewal is too short; alterntate policy: as long as draft or version is alive, expire in 3 to 6 months - Alex: that suggestion ties validity with ability of author to submit the draft; suggestion: once document is submitted to IESG then we freeze. Don't want to allocate codepoints too early. - Dave Meyer: Are you sure that IANA can time anything out - Alex: No - Dave Meyer: WG chair needs to manage this? - What happens if the allocation is not renewed and code is using it still? - Alex: Add provision to document to deprecate but not return - Kireeti: Deprecate for a period of time to give people time to remove. Formal process to do early allocations and if it goes through then stick with it but if it doesn't go through then people must take this out. - Dino: Allocate experimental codepoints and once standardised, then adopt standard codepoint for sending but accept both. - Sue: Good for SAFIs as well as AFIs? - Dino: All well known IANA values - Fenner: RFC already documents a process for transitioning codepoints 9) Charter Discussion [20 minutes] Thanks to all implementers who send in reports on the the base specification, we will be opening the charter. This section of the = meeting will discuss what items will be added to the charter. Presentation - Top three most important; maybe ECMP little higher than Fault = Isolation -- /*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D[ Jake Khuon = = ]=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Field App. Engineer http://www.nexthop.com/ /\ /~ E X T H O = P | | Ofc: +1 (425) 391-2262 Fax: +1 (425) 391-6772 / \/ Technologies, = Inc.| +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D[ 1911 Landings Drive, Mountain View, CA = 94043 USA ]=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 23:19:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28879 for ; Mon, 1 Mar 2004 23:19:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1Np-0005Zg-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 23:19:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay1Mo-0005Nx-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 23:18:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay1M3-0005CL-02; Mon, 01 Mar 2004 23:18:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ay19b-0000Ae-6R; Mon, 01 Mar 2004 23:05:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay19X-0004MQ-6O; Mon, 01 Mar 2004 23:05:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay19O-0004LG-KB for idr@optimus.ietf.org; Mon, 01 Mar 2004 23:04:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28060 for ; Mon, 1 Mar 2004 23:04:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay19I-0003YX-00 for idr@ietf.org; Mon, 01 Mar 2004 23:04:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay17i-0003P5-00 for idr@ietf.org; Mon, 01 Mar 2004 23:03:14 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay16j-00037L-00 for idr@ietf.org; Mon, 01 Mar 2004 23:02:13 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2241WV18475; Tue, 2 Mar 2004 06:01:32 +0200 From: Pekka Savola To: Gargi Nalawade cc: Pedro Roque Marques , Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: <4043F15B.7000400@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 06:01:32 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 1 Mar 2004, Gargi Nalawade wrote: > Are you asking that BGP advertise a route even if the nexthop of the > route in the forwarding table is different? If so, this definitely > breaks routing. As long as the nexthop of the 2 routes are the same, > there is no problem. Thanks for asking for clarification; I think this is very useful, and a point which has not been spelled out clearly enough. I'm only interested of the case where the next-hop interface is the same for both protocols. (Obviously, there is no 1-to-1 mapping, because IGP gives an interface, but BGP an address.) But this is natural, as the BGP next-hop information is quite often, when it matters, calculated based on IGP :) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 23:20:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28976 for ; Mon, 1 Mar 2004 23:20:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1Ns-0005pm-Fn for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 23:19:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i224Jukx022425 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 23:19:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1Ns-0005pc-6B for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 23:19:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28898 for ; Mon, 1 Mar 2004 23:19:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1Nq-0005Zn-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 23:19:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay1Mo-0005O4-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 23:18:51 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay1M3-0005CL-02; Mon, 01 Mar 2004 23:18:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ay19b-0000Ae-6R; Mon, 01 Mar 2004 23:05:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay19X-0004MQ-6O; Mon, 01 Mar 2004 23:05:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay19O-0004LG-KB for idr@optimus.ietf.org; Mon, 01 Mar 2004 23:04:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28060 for ; Mon, 1 Mar 2004 23:04:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay19I-0003YX-00 for idr@ietf.org; Mon, 01 Mar 2004 23:04:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay17i-0003P5-00 for idr@ietf.org; Mon, 01 Mar 2004 23:03:14 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay16j-00037L-00 for idr@ietf.org; Mon, 01 Mar 2004 23:02:13 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2241WV18475; Tue, 2 Mar 2004 06:01:32 +0200 From: Pekka Savola To: Gargi Nalawade cc: Pedro Roque Marques , Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: <4043F15B.7000400@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 06:01:32 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 1 Mar 2004, Gargi Nalawade wrote: > Are you asking that BGP advertise a route even if the nexthop of the > route in the forwarding table is different? If so, this definitely > breaks routing. As long as the nexthop of the 2 routes are the same, > there is no problem. Thanks for asking for clarification; I think this is very useful, and a point which has not been spelled out clearly enough. I'm only interested of the case where the next-hop interface is the same for both protocols. (Obviously, there is no 1-to-1 mapping, because IGP gives an interface, but BGP an address.) But this is natural, as the BGP next-hop information is quite often, when it matters, calculated based on IGP :) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 23:21:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29005 for ; Mon, 1 Mar 2004 23:21:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1P3-0005oc-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 23:21:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay1O5-0005f6-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 23:20:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1N2-0005PA-00; Mon, 01 Mar 2004 23:19:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1Mz-0005hH-L0; Mon, 01 Mar 2004 23:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1MJ-0005b8-0o for idr@optimus.ietf.org; Mon, 01 Mar 2004 23:18:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28744 for ; Mon, 1 Mar 2004 23:18:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1MH-0005II-00 for idr@ietf.org; Mon, 01 Mar 2004 23:18:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay1LH-0005BZ-00 for idr@ietf.org; Mon, 01 Mar 2004 23:17:15 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1KR-0004z7-00 for idr@ietf.org; Mon, 01 Mar 2004 23:16:23 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i224FpM18674; Tue, 2 Mar 2004 06:15:51 +0200 From: Pekka Savola To: Pedro Roque Marques cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <200403020156.i221u9jf050325@roque-bsd.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 06:15:51 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 1 Mar 2004, Pedro Roque Marques wrote: > > > No -- the current spec is just looking up a route -- it takes no > > stance what kind of 'route' that is. > > By your own admission the spec doesn't require clarification. It is > clear that it doesn't understand the next-hop type of a route. Some people seem to disagree. I personally am of the opinion that the spec can be read both ways, but *seems* to indicate that the intent is to be "route -type agnostic". > What you mean by this is that you believe that the current behaviour > should be modified... Modified (if the WG thinks your interpretation is correct) is preferable. Clarified is required. > The modification you propose also isn't suficient to address the > problem that you point out whenever your aggregate route has a > reachable next-hop. As stated, that can be avoided by operational procedures (by putting the discard routes in every box). This really can't. > Examples where this could happen: > > - User wants to forward all traffic that hits the default route to a > remote box that analyzes traffic... i.e. 0/0 to an LSP to a traffic > collector. Of course, this can happen. Then the BGP nexthops matching the default remain 'resolvable'. But that seems quite obvious: if you have a "working" default route, it will be considered by the resolvability process. Of course, in the long run, there is a need to specify the resolvability in a more fine-grained manner, but the "discard route" scenario seems to be a non-obvious problem which must be fixed quickly. I don't have many preferences on the way it's solved, as long as it gets fixed soon. And if fixing would take time, and it's for any purpose delayed from the bgp4-xx spec for now, we must clearly specify the expected behaviour in the spec. > - Network is divided in areas but has global IGP. Each area border > generates a summary of address in the are that is propagated across > the network. i.e. outside the area you see an aggregate via BGP and > more specific /32s. "Don't do that". :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 23:21:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29092 for ; Mon, 1 Mar 2004 23:21:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1P7-0005vc-M9 for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 23:21:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i224LD7a022774 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 23:21:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1P6-0005v2-Hk for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 23:21:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29023 for ; Mon, 1 Mar 2004 23:21:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1P4-0005oi-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 23:21:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay1O6-0005fD-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 23:20:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1N2-0005PA-00; Mon, 01 Mar 2004 23:19:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1Mz-0005hH-L0; Mon, 01 Mar 2004 23:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1MJ-0005b8-0o for idr@optimus.ietf.org; Mon, 01 Mar 2004 23:18:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28744 for ; Mon, 1 Mar 2004 23:18:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1MH-0005II-00 for idr@ietf.org; Mon, 01 Mar 2004 23:18:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay1LH-0005BZ-00 for idr@ietf.org; Mon, 01 Mar 2004 23:17:15 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1KR-0004z7-00 for idr@ietf.org; Mon, 01 Mar 2004 23:16:23 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i224FpM18674; Tue, 2 Mar 2004 06:15:51 +0200 From: Pekka Savola To: Pedro Roque Marques cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <200403020156.i221u9jf050325@roque-bsd.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 06:15:51 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 1 Mar 2004, Pedro Roque Marques wrote: > > > No -- the current spec is just looking up a route -- it takes no > > stance what kind of 'route' that is. > > By your own admission the spec doesn't require clarification. It is > clear that it doesn't understand the next-hop type of a route. Some people seem to disagree. I personally am of the opinion that the spec can be read both ways, but *seems* to indicate that the intent is to be "route -type agnostic". > What you mean by this is that you believe that the current behaviour > should be modified... Modified (if the WG thinks your interpretation is correct) is preferable. Clarified is required. > The modification you propose also isn't suficient to address the > problem that you point out whenever your aggregate route has a > reachable next-hop. As stated, that can be avoided by operational procedures (by putting the discard routes in every box). This really can't. > Examples where this could happen: > > - User wants to forward all traffic that hits the default route to a > remote box that analyzes traffic... i.e. 0/0 to an LSP to a traffic > collector. Of course, this can happen. Then the BGP nexthops matching the default remain 'resolvable'. But that seems quite obvious: if you have a "working" default route, it will be considered by the resolvability process. Of course, in the long run, there is a need to specify the resolvability in a more fine-grained manner, but the "discard route" scenario seems to be a non-obvious problem which must be fixed quickly. I don't have many preferences on the way it's solved, as long as it gets fixed soon. And if fixing would take time, and it's for any purpose delayed from the bgp4-xx spec for now, we must clearly specify the expected behaviour in the spec. > - Network is divided in areas but has global IGP. Each area border > generates a summary of address in the are that is propagated across > the network. i.e. outside the area you see an aggregate via BGP and > more specific /32s. "Don't do that". :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 1 23:41:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00172 for ; Mon, 1 Mar 2004 23:41:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1iP-0000YE-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 23:41:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay1hP-0000QQ-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 23:40:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1gS-0000I6-00; Mon, 01 Mar 2004 23:39:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1gL-0007xO-0F; Mon, 01 Mar 2004 23:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1fb-0007k5-Lc for idr@optimus.ietf.org; Mon, 01 Mar 2004 23:38:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29984 for ; Mon, 1 Mar 2004 23:38:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1fZ-0000Ah-00 for idr@ietf.org; Mon, 01 Mar 2004 23:38:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay1ed-000031-00 for idr@ietf.org; Mon, 01 Mar 2004 23:37:16 -0500 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1dq-0007jA-00 for idr@ietf.org; Mon, 01 Mar 2004 23:36:26 -0500 Received: (qmail 16232 invoked by uid 1021); 2 Mar 2004 04:36:27 -0000 From: vijay gill To: Pedro Roque Marques Cc: Pekka Savola , idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) Message-ID: <20040302043627.GA16188@vijaygill.com> References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> <200403020025.i220PI9P050138@roque-bsd.juniper.net> <20040302003314.GA6255@vijaygill.com> <200403020041.i220fwFm050173@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403020041.i220fwFm050173@roque-bsd.juniper.net> User-Agent: Mutt/1.3.28i Organization: vijay gill global logistics Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 04:36:27 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --On Monday, March 1, 2004 16:41 -0800 Pedro Roque Marques wrote: > vijay gill writes: > >> On Mon, Mar 01, 2004 at 04:25:18PM -0800, Pedro Roque Marques wrote: >>> Pekka Savola writes: >>> >>> i'll repeat it: - How can you prove that a given path that is >>> learned by BGP is loop free ? - That can only be done if >>> forwarding follows routing. > >> I feel that BGP should only be concerned about creating loop free >> topologies. If the user then has a mechanism where the forwarding >> does not follow the routing properly and causes a loop (this is an >> important distinction), then this is their problem. I can always >> point a static back up a link if I so want and nothing bgp can do >> about it. > > Your argument assumes that the user always knows that is configuring a > situation that may create forwarding loops... > > That may not be the case. It may come from a configuration > mistake... > > imho, the default approach for the protocol spec is to choose the most > graceful failure model possible torwards loop-free forwarding... >imho, the default approach for the protocol spec is to choose the most >graceful failure model possible torwards loop-free forwarding... Pedro, I still don't understand why BGP must care about statics or other protocols that may or may not be misconfigured. For some reason I may want to create a forwarding loop (for example, in my lab) to see what the router does. Actually, to be more specific, there are valid operational reasons for sometimes routing information away from where BGP points you, load balancing on congested peerings for example. Not very elegant, but these cases do exist. If a vendors BGP implementation does not allow me to have the final say as to where I want to place traffic, I _will_ be extremely irate. If you only consider BGP, then it should do loop-free routing, absolutely. I just do not want BGP to be looking into static configurations and trying to do my thinking for me. This leads to anger and anger leads to the dark side. etc etc. > >>> Proof: configure a static route for a given prefix in a border >>>router that points to a BGP neighbor that selects this router as >>>best path... watch permanent forwarding loops. > >>Yes, and this is a not a matter for BGP to worry about. > >I respectfully disagree. that is fine. but as we all know, the final arbiter of features is the account team, backed up by P.O.s no matter what the IETF would like to believe. /vijay > > Pedro. > >_______________________________________________ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 1 23:41:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00226 for ; Mon, 1 Mar 2004 23:41:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1iX-0002NW-E0 for idr-archive@odin.ietf.org; Mon, 01 Mar 2004 23:41:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i224fHAO009136 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 23:41:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1iX-0002NH-98 for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 23:41:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00192 for ; Mon, 1 Mar 2004 23:41:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1iV-0000Yg-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 23:41:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay1hQ-0000QZ-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 23:40:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1gS-0000I6-00; Mon, 01 Mar 2004 23:39:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1gL-0007xO-0F; Mon, 01 Mar 2004 23:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1fb-0007k5-Lc for idr@optimus.ietf.org; Mon, 01 Mar 2004 23:38:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29984 for ; Mon, 1 Mar 2004 23:38:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1fZ-0000Ah-00 for idr@ietf.org; Mon, 01 Mar 2004 23:38:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay1ed-000031-00 for idr@ietf.org; Mon, 01 Mar 2004 23:37:16 -0500 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1dq-0007jA-00 for idr@ietf.org; Mon, 01 Mar 2004 23:36:26 -0500 Received: (qmail 16232 invoked by uid 1021); 2 Mar 2004 04:36:27 -0000 From: vijay gill To: Pedro Roque Marques Cc: Pekka Savola , idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) Message-ID: <20040302043627.GA16188@vijaygill.com> References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> <200403020025.i220PI9P050138@roque-bsd.juniper.net> <20040302003314.GA6255@vijaygill.com> <200403020041.i220fwFm050173@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403020041.i220fwFm050173@roque-bsd.juniper.net> User-Agent: Mutt/1.3.28i Organization: vijay gill global logistics Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 04:36:27 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --On Monday, March 1, 2004 16:41 -0800 Pedro Roque Marques wrote: > vijay gill writes: > >> On Mon, Mar 01, 2004 at 04:25:18PM -0800, Pedro Roque Marques wrote: >>> Pekka Savola writes: >>> >>> i'll repeat it: - How can you prove that a given path that is >>> learned by BGP is loop free ? - That can only be done if >>> forwarding follows routing. > >> I feel that BGP should only be concerned about creating loop free >> topologies. If the user then has a mechanism where the forwarding >> does not follow the routing properly and causes a loop (this is an >> important distinction), then this is their problem. I can always >> point a static back up a link if I so want and nothing bgp can do >> about it. > > Your argument assumes that the user always knows that is configuring a > situation that may create forwarding loops... > > That may not be the case. It may come from a configuration > mistake... > > imho, the default approach for the protocol spec is to choose the most > graceful failure model possible torwards loop-free forwarding... >imho, the default approach for the protocol spec is to choose the most >graceful failure model possible torwards loop-free forwarding... Pedro, I still don't understand why BGP must care about statics or other protocols that may or may not be misconfigured. For some reason I may want to create a forwarding loop (for example, in my lab) to see what the router does. Actually, to be more specific, there are valid operational reasons for sometimes routing information away from where BGP points you, load balancing on congested peerings for example. Not very elegant, but these cases do exist. If a vendors BGP implementation does not allow me to have the final say as to where I want to place traffic, I _will_ be extremely irate. If you only consider BGP, then it should do loop-free routing, absolutely. I just do not want BGP to be looking into static configurations and trying to do my thinking for me. This leads to anger and anger leads to the dark side. etc etc. > >>> Proof: configure a static route for a given prefix in a border >>>router that points to a BGP neighbor that selects this router as >>>best path... watch permanent forwarding loops. > >>Yes, and this is a not a matter for BGP to worry about. > >I respectfully disagree. that is fine. but as we all know, the final arbiter of features is the account team, backed up by P.O.s no matter what the IETF would like to believe. /vijay > > Pedro. > >_______________________________________________ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 2 00:18:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02414 for ; Tue, 2 Mar 2004 00:18:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2II-0004zO-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 00:18:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2HK-0004sL-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 00:17:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2GQ-0004lJ-00; Tue, 02 Mar 2004 00:16:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2G9-0005Ed-Pu; Tue, 02 Mar 2004 00:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2FU-0005CP-6d for idr@optimus.ietf.org; Tue, 02 Mar 2004 00:15:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02311 for ; Tue, 2 Mar 2004 00:15:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2FR-0004dk-00 for idr@ietf.org; Tue, 02 Mar 2004 00:15:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2EZ-0004XT-00 for idr@ietf.org; Tue, 02 Mar 2004 00:14:23 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2Dx-0004Od-00 for idr@ietf.org; Tue, 02 Mar 2004 00:13:45 -0500 Received: from cisco.com (hkidc-vpn-client-234-19.cisco.com [10.75.234.19]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i225ClLM006725; Mon, 1 Mar 2004 21:12:48 -0800 (PST) Message-ID: <404417CE.2020901@cisco.com> From: Gargi Nalawade Reply-To: gargi@cisco.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Pedro Roque Marques , idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 21:12:46 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Mon, 1 Mar 2004, Gargi Nalawade wrote: > >>Are you asking that BGP advertise a route even if the nexthop of the >>route in the forwarding table is different? If so, this definitely >>breaks routing. As long as the nexthop of the 2 routes are the same, >>there is no problem. > > > Thanks for asking for clarification; I think this is very useful, and > a point which has not been spelled out clearly enough. > > I'm only interested of the case where the next-hop interface is the > same for both protocols. (Obviously, there is no 1-to-1 mapping, > because IGP gives an interface, but BGP an address.) For this case - there is no problem. Some implementations can already do this. But again there are operators who want the opposite behavior as well. i.e. BGP should not advertise a route if it is not the owner even if the BGP nexthop is the same as that of the route in the forwarding table. Both behaviors are achieved today by various imple- mentations even though the default may vary from vendor to vendor. Again - time for a clarification. :) Are you asking for that the behavior be present or that the spec be changed to describe both behaviors? -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 2 00:18:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02472 for ; Tue, 2 Mar 2004 00:18:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2IM-0005ff-T2 for idr-archive@odin.ietf.org; Tue, 02 Mar 2004 00:18:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i225IIVH021799 for idr-archive@odin.ietf.org; Tue, 2 Mar 2004 00:18:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2IM-0005fW-OZ for idr-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 00:18:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02432 for ; Tue, 2 Mar 2004 00:18:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2IK-0004zg-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 00:18:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2HL-0004sS-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 00:17:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2GQ-0004lJ-00; Tue, 02 Mar 2004 00:16:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2G9-0005Ed-Pu; Tue, 02 Mar 2004 00:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2FU-0005CP-6d for idr@optimus.ietf.org; Tue, 02 Mar 2004 00:15:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02311 for ; Tue, 2 Mar 2004 00:15:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2FR-0004dk-00 for idr@ietf.org; Tue, 02 Mar 2004 00:15:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2EZ-0004XT-00 for idr@ietf.org; Tue, 02 Mar 2004 00:14:23 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2Dx-0004Od-00 for idr@ietf.org; Tue, 02 Mar 2004 00:13:45 -0500 Received: from cisco.com (hkidc-vpn-client-234-19.cisco.com [10.75.234.19]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i225ClLM006725; Mon, 1 Mar 2004 21:12:48 -0800 (PST) Message-ID: <404417CE.2020901@cisco.com> From: Gargi Nalawade Reply-To: gargi@cisco.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Pedro Roque Marques , idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 21:12:46 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Mon, 1 Mar 2004, Gargi Nalawade wrote: > >>Are you asking that BGP advertise a route even if the nexthop of the >>route in the forwarding table is different? If so, this definitely >>breaks routing. As long as the nexthop of the 2 routes are the same, >>there is no problem. > > > Thanks for asking for clarification; I think this is very useful, and > a point which has not been spelled out clearly enough. > > I'm only interested of the case where the next-hop interface is the > same for both protocols. (Obviously, there is no 1-to-1 mapping, > because IGP gives an interface, but BGP an address.) For this case - there is no problem. Some implementations can already do this. But again there are operators who want the opposite behavior as well. i.e. BGP should not advertise a route if it is not the owner even if the BGP nexthop is the same as that of the route in the forwarding table. Both behaviors are achieved today by various imple- mentations even though the default may vary from vendor to vendor. Again - time for a clarification. :) Are you asking for that the behavior be present or that the spec be changed to describe both behaviors? -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 2 00:50:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04133 for ; Tue, 2 Mar 2004 00:50:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2nG-0000u7-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 00:50:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2mI-0000oL-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 00:49:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2m8-0000j0-00; Tue, 02 Mar 2004 00:49:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2m6-0001oA-2x; Tue, 02 Mar 2004 00:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2lL-0001lc-EF for idr@optimus.ietf.org; Tue, 02 Mar 2004 00:48:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04054 for ; Tue, 2 Mar 2004 00:48:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2lI-0000i4-00 for idr@ietf.org; Tue, 02 Mar 2004 00:48:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2kN-0000cY-00 for idr@ietf.org; Tue, 02 Mar 2004 00:47:15 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2k0-0000Wy-00 for idr@ietf.org; Tue, 02 Mar 2004 00:46:52 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i225kCd19705; Tue, 2 Mar 2004 07:46:12 +0200 From: Pekka Savola To: Gargi Nalawade cc: Pedro Roque Marques , Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: <404417CE.2020901@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 07:46:12 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 1 Mar 2004, Gargi Nalawade wrote: > For this case - there is no problem. Some implementations can already > do this. But again there are operators who want the opposite behavior > as well. i.e. BGP should not advertise a route if it is not the owner > even if the BGP nexthop is the same as that of the route in the > forwarding table. Really? I'm having problems figuring out where this would be desired behaviour. > Both behaviors are achieved today by various imple- > mentations even though the default may vary from vendor to vendor. Yep. > Again - time for a clarification. :) Are you asking for that the > behavior be present or that the spec be changed to describe both > behaviors? I think the specification should, very clearly, state just one recommended behaviour, and possibly describe an optional other behaviour. I think the recommended behaviour should be what I proposed, and you also described. Because that's actually what happens very often. But if there is strong objection to this very clear statement of behaviour (or "modification"), also spelling out the alternative is important. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 2 00:50:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04158 for ; Tue, 2 Mar 2004 00:50:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2nL-0001x2-1v for idr-archive@odin.ietf.org; Tue, 02 Mar 2004 00:50:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i225oJpx007500 for idr-archive@odin.ietf.org; Tue, 2 Mar 2004 00:50:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2nK-0001wt-Ti for idr-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 00:50:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04151 for ; Tue, 2 Mar 2004 00:50:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2nI-0000uN-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 00:50:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2mJ-0000oV-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 00:49:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2m8-0000j0-00; Tue, 02 Mar 2004 00:49:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2m6-0001oA-2x; Tue, 02 Mar 2004 00:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2lL-0001lc-EF for idr@optimus.ietf.org; Tue, 02 Mar 2004 00:48:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04054 for ; Tue, 2 Mar 2004 00:48:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2lI-0000i4-00 for idr@ietf.org; Tue, 02 Mar 2004 00:48:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2kN-0000cY-00 for idr@ietf.org; Tue, 02 Mar 2004 00:47:15 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2k0-0000Wy-00 for idr@ietf.org; Tue, 02 Mar 2004 00:46:52 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i225kCd19705; Tue, 2 Mar 2004 07:46:12 +0200 From: Pekka Savola To: Gargi Nalawade cc: Pedro Roque Marques , Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: <404417CE.2020901@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 07:46:12 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 1 Mar 2004, Gargi Nalawade wrote: > For this case - there is no problem. Some implementations can already > do this. But again there are operators who want the opposite behavior > as well. i.e. BGP should not advertise a route if it is not the owner > even if the BGP nexthop is the same as that of the route in the > forwarding table. Really? I'm having problems figuring out where this would be desired behaviour. > Both behaviors are achieved today by various imple- > mentations even though the default may vary from vendor to vendor. Yep. > Again - time for a clarification. :) Are you asking for that the > behavior be present or that the spec be changed to describe both > behaviors? I think the specification should, very clearly, state just one recommended behaviour, and possibly describe an optional other behaviour. I think the recommended behaviour should be what I proposed, and you also described. Because that's actually what happens very often. But if there is strong objection to this very clear statement of behaviour (or "modification"), also spelling out the alternative is important. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 2 01:01:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04629 for ; Tue, 2 Mar 2004 01:01:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2y0-0002Hn-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 01:01:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2wu-00025P-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 01:00:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2vt-0001tM-00; Tue, 02 Mar 2004 00:59:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2vn-0002x6-6J; Tue, 02 Mar 2004 00:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2vL-0002vq-6Q for idr@optimus.ietf.org; Tue, 02 Mar 2004 00:58:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04447 for ; Tue, 2 Mar 2004 00:58:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2vI-0001oe-00 for idr@ietf.org; Tue, 02 Mar 2004 00:58:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2uO-0001gJ-00 for idr@ietf.org; Tue, 02 Mar 2004 00:57:37 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2tr-0001YT-00 for idr@ietf.org; Tue, 02 Mar 2004 00:57:03 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 01 Mar 2004 21:56:30 -0800 Received: from cisco.com (hkidc-vpn-client-234-19.cisco.com [10.75.234.19]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i225uID1027841; Mon, 1 Mar 2004 21:56:19 -0800 (PST) Message-ID: <40442200.3030904@cisco.com> From: Gargi Nalawade Reply-To: gargi@cisco.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Pedro Roque Marques , idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 21:56:16 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Mon, 1 Mar 2004, Gargi Nalawade wrote: > >>For this case - there is no problem. Some implementations can already >>do this. But again there are operators who want the opposite behavior >>as well. i.e. BGP should not advertise a route if it is not the owner >>even if the BGP nexthop is the same as that of the route in the >>forwarding table. > > > Really? I'm having problems figuring out where this would be desired > behaviour. Im trying to hunt for the usage if this as well. So if anyone knows of a reason, let us know. I have only heard 3rd & 4th hand requirements so far where the source has either moved on or no longer exists. >>Both behaviors are achieved today by various imple- >>mentations even though the default may vary from vendor to vendor. > > > Yep. > > >>Again - time for a clarification. :) Are you asking for that the >>behavior be present or that the spec be changed to describe both >>behaviors? > > > I think the specification should, very clearly, state just one > recommended behaviour, and possibly describe an optional other > behaviour. I think the recommended behaviour should be what I > proposed, and you also described. Because that's actually what > happens very often. > > But if there is strong objection to this very clear statement of > behaviour (or "modification"), also spelling out the alternative is > important. Now that I understand your request for modification & clarification better, I think it makes sense. It would be good to clarify in the spec. If there is no operator here who can think of a reason why they may want to explicitly prohibit BGP from advertising a route it doesnt own, even when the nexthop matches that in the forwarding table, we should make the other behavior (i.e. advertise even if BGP doesnt own the route when the nexthop matches) the recommended one, stating the currently stated but least used behavior as an optional alternative. -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 2 01:01:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04708 for ; Tue, 2 Mar 2004 01:01:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2y5-0003Nf-EH for idr-archive@odin.ietf.org; Tue, 02 Mar 2004 01:01:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2261PWV012989 for idr-archive@odin.ietf.org; Tue, 2 Mar 2004 01:01:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2y5-0003NQ-9W for idr-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 01:01:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04647 for ; Tue, 2 Mar 2004 01:01:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2y2-0002I1-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 01:01:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2wv-00025Z-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 01:00:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2vt-0001tM-00; Tue, 02 Mar 2004 00:59:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2vn-0002x6-6J; Tue, 02 Mar 2004 00:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2vL-0002vq-6Q for idr@optimus.ietf.org; Tue, 02 Mar 2004 00:58:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04447 for ; Tue, 2 Mar 2004 00:58:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2vI-0001oe-00 for idr@ietf.org; Tue, 02 Mar 2004 00:58:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2uO-0001gJ-00 for idr@ietf.org; Tue, 02 Mar 2004 00:57:37 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2tr-0001YT-00 for idr@ietf.org; Tue, 02 Mar 2004 00:57:03 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 01 Mar 2004 21:56:30 -0800 Received: from cisco.com (hkidc-vpn-client-234-19.cisco.com [10.75.234.19]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i225uID1027841; Mon, 1 Mar 2004 21:56:19 -0800 (PST) Message-ID: <40442200.3030904@cisco.com> From: Gargi Nalawade Reply-To: gargi@cisco.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Pedro Roque Marques , idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 21:56:16 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Mon, 1 Mar 2004, Gargi Nalawade wrote: > >>For this case - there is no problem. Some implementations can already >>do this. But again there are operators who want the opposite behavior >>as well. i.e. BGP should not advertise a route if it is not the owner >>even if the BGP nexthop is the same as that of the route in the >>forwarding table. > > > Really? I'm having problems figuring out where this would be desired > behaviour. Im trying to hunt for the usage if this as well. So if anyone knows of a reason, let us know. I have only heard 3rd & 4th hand requirements so far where the source has either moved on or no longer exists. >>Both behaviors are achieved today by various imple- >>mentations even though the default may vary from vendor to vendor. > > > Yep. > > >>Again - time for a clarification. :) Are you asking for that the >>behavior be present or that the spec be changed to describe both >>behaviors? > > > I think the specification should, very clearly, state just one > recommended behaviour, and possibly describe an optional other > behaviour. I think the recommended behaviour should be what I > proposed, and you also described. Because that's actually what > happens very often. > > But if there is strong objection to this very clear statement of > behaviour (or "modification"), also spelling out the alternative is > important. Now that I understand your request for modification & clarification better, I think it makes sense. It would be good to clarify in the spec. If there is no operator here who can think of a reason why they may want to explicitly prohibit BGP from advertising a route it doesnt own, even when the nexthop matches that in the forwarding table, we should make the other behavior (i.e. advertise even if BGP doesnt own the route when the nexthop matches) the recommended one, stating the currently stated but least used behavior as an optional alternative. -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 2 01:51:22 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06917 for ; Tue, 2 Mar 2004 01:51:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3kO-0000U9-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 01:51:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay3jW-0000NF-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 01:50:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3iu-0000GM-00; Tue, 02 Mar 2004 01:49:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3iA-0001Ta-BQ; Tue, 02 Mar 2004 01:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3hV-0001Jb-Ex for idr@optimus.ietf.org; Tue, 02 Mar 2004 01:48:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06743 for ; Tue, 2 Mar 2004 01:48:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3hS-00006n-00 for idr@ietf.org; Tue, 02 Mar 2004 01:48:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay3gT-0007mp-00 for idr@ietf.org; Tue, 02 Mar 2004 01:47:18 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1Ay3fY-0007aH-00 for idr@ietf.org; Tue, 02 Mar 2004 01:46:20 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i226ji1K050965; Mon, 1 Mar 2004 22:45:44 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i226jiF4050962; Mon, 1 Mar 2004 22:45:44 -0800 (PST) Message-Id: <200403020645.i226jiF4050962@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: gargi@cisco.com Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: <40442200.3030904@cisco.com> References: <40442200.3030904@cisco.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 22:45:44 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Gargi Nalawade writes: > Now that I understand your request for modification & clarification > better, I think it makes sense. It would be good to clarify in the > spec. > If there is no operator here who can think of a reason why they may > want to explicitly prohibit BGP from advertising a route it doesnt own, > even when the nexthop matches that in the forwarding table, we should > make the other behavior (i.e. advertise even if BGP doesnt own the route > when the nexthop matches) the recommended one, stating the currently > stated but least used behavior as an optional alternative. My time to ask for a clarification... It seems that you are saying that: 1) when the nexthop of a BGP route doesn't match the forwarding nexthop selected in the routing table that BGP should not advertise the route. In your words "it breaks routing", or it has the potential to do so. 2) If the next-hop does match, BGP should advertise its route, even if less preferred. A second question would be how do you define 'next-hop matching' in the context of an iBGP route vs an IGP route. regards, Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 2 01:51:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06950 for ; Tue, 2 Mar 2004 01:51:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3kT-00026k-8z for idr-archive@odin.ietf.org; Tue, 02 Mar 2004 01:51:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i226pPsx008094 for idr-archive@odin.ietf.org; Tue, 2 Mar 2004 01:51:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3kT-00026T-1S for idr-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 01:51:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06934 for ; Tue, 2 Mar 2004 01:51:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3kP-0000UE-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 01:51:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay3jX-0000NM-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 01:50:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3iu-0000GM-00; Tue, 02 Mar 2004 01:49:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3iA-0001Ta-BQ; Tue, 02 Mar 2004 01:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3hV-0001Jb-Ex for idr@optimus.ietf.org; Tue, 02 Mar 2004 01:48:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06743 for ; Tue, 2 Mar 2004 01:48:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3hS-00006n-00 for idr@ietf.org; Tue, 02 Mar 2004 01:48:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay3gT-0007mp-00 for idr@ietf.org; Tue, 02 Mar 2004 01:47:18 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1Ay3fY-0007aH-00 for idr@ietf.org; Tue, 02 Mar 2004 01:46:20 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i226ji1K050965; Mon, 1 Mar 2004 22:45:44 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i226jiF4050962; Mon, 1 Mar 2004 22:45:44 -0800 (PST) Message-Id: <200403020645.i226jiF4050962@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: gargi@cisco.com Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: <40442200.3030904@cisco.com> References: <40442200.3030904@cisco.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 22:45:44 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Gargi Nalawade writes: > Now that I understand your request for modification & clarification > better, I think it makes sense. It would be good to clarify in the > spec. > If there is no operator here who can think of a reason why they may > want to explicitly prohibit BGP from advertising a route it doesnt own, > even when the nexthop matches that in the forwarding table, we should > make the other behavior (i.e. advertise even if BGP doesnt own the route > when the nexthop matches) the recommended one, stating the currently > stated but least used behavior as an optional alternative. My time to ask for a clarification... It seems that you are saying that: 1) when the nexthop of a BGP route doesn't match the forwarding nexthop selected in the routing table that BGP should not advertise the route. In your words "it breaks routing", or it has the potential to do so. 2) If the next-hop does match, BGP should advertise its route, even if less preferred. A second question would be how do you define 'next-hop matching' in the context of an iBGP route vs an IGP route. regards, Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 2 03:02:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24285 for ; Tue, 2 Mar 2004 03:02:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4rN-0002Qh-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 03:02:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4pz-00024Q-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 03:01:12 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay4oj-0001po-00; Tue, 02 Mar 2004 02:59:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ay4bY-0002mX-TL; Tue, 02 Mar 2004 02:46:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4bK-00014a-10; Tue, 02 Mar 2004 02:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4b3-00013J-91 for idr@optimus.ietf.org; Tue, 02 Mar 2004 02:45:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23477 for ; Tue, 2 Mar 2004 02:45:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4az-0000IB-00 for idr@ietf.org; Tue, 02 Mar 2004 02:45:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4Zo-00001I-00 for idr@ietf.org; Tue, 02 Mar 2004 02:44:30 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4Xz-0007BN-00 for idr@ietf.org; Tue, 02 Mar 2004 02:42:35 -0500 Received: from cisco.com (hkidc-vpn-client-234-5.cisco.com [10.75.234.5]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i227fSD1017579; Mon, 1 Mar 2004 23:41:29 -0800 (PST) Message-ID: <40443AA7.2010804@cisco.com> From: Gargi Nalawade Reply-To: gargi@cisco.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pedro Roque Marques CC: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) References: <40442200.3030904@cisco.com> <200403020645.i226jiF4050962@roque-bsd.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 23:41:27 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Pedro Roque Marques wrote: > Gargi Nalawade writes: > > >>Now that I understand your request for modification & clarification >>better, I think it makes sense. It would be good to clarify in the >>spec. > > >>If there is no operator here who can think of a reason why they may >>want to explicitly prohibit BGP from advertising a route it doesnt own, >>even when the nexthop matches that in the forwarding table, we should >>make the other behavior (i.e. advertise even if BGP doesnt own the route >>when the nexthop matches) the recommended one, stating the currently >>stated but least used behavior as an optional alternative. > > > My time to ask for a clarification... > > It seems that you are saying that: > > 1) when the nexthop of a BGP route doesn't match the forwarding > nexthop selected in the routing table that BGP should not advertise > the route. In your words "it breaks routing", or it has the potential > to do so. > > 2) If the next-hop does match, BGP should advertise its route, even if > less preferred. yes & yes. > A second question would be how do you define 'next-hop matching' in > the context of an iBGP route vs an IGP route. Why should iBGP vs IGP come into play? The BGP bestpath calculation would have already given us the best BGP route. If this BGP route (BGP's bestpath) loses to an IGP route with a lower admin-distance then BGP decides whether or not advertise this BGP route. But a BGP bestpath cannot lose to an iBGP route in the routing-table. Because that iBGP route wont be the BGP bestpath. Then why does losing to an iBGP route come into play when it comes to advertising a BGP bestpath? Am I missing what you are trying to say? -Gargi > > regards, > Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 2 03:03:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24445 for ; Tue, 2 Mar 2004 03:03:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4rS-0003DW-Rb for idr-archive@odin.ietf.org; Tue, 02 Mar 2004 03:02:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2282gZa012360 for idr-archive@odin.ietf.org; Tue, 2 Mar 2004 03:02:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4rS-0003DF-F0 for idr-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 03:02:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24302 for ; Tue, 2 Mar 2004 03:02:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4rO-0002Qn-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 03:02:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4q0-00024e-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 03:01:13 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay4oj-0001po-00; Tue, 02 Mar 2004 02:59:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ay4bY-0002mX-TL; Tue, 02 Mar 2004 02:46:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4bK-00014a-10; Tue, 02 Mar 2004 02:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4b3-00013J-91 for idr@optimus.ietf.org; Tue, 02 Mar 2004 02:45:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23477 for ; Tue, 2 Mar 2004 02:45:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4az-0000IB-00 for idr@ietf.org; Tue, 02 Mar 2004 02:45:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4Zo-00001I-00 for idr@ietf.org; Tue, 02 Mar 2004 02:44:30 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4Xz-0007BN-00 for idr@ietf.org; Tue, 02 Mar 2004 02:42:35 -0500 Received: from cisco.com (hkidc-vpn-client-234-5.cisco.com [10.75.234.5]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i227fSD1017579; Mon, 1 Mar 2004 23:41:29 -0800 (PST) Message-ID: <40443AA7.2010804@cisco.com> From: Gargi Nalawade Reply-To: gargi@cisco.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pedro Roque Marques CC: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) References: <40442200.3030904@cisco.com> <200403020645.i226jiF4050962@roque-bsd.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 23:41:27 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pedro Roque Marques wrote: > Gargi Nalawade writes: > > >>Now that I understand your request for modification & clarification >>better, I think it makes sense. It would be good to clarify in the >>spec. > > >>If there is no operator here who can think of a reason why they may >>want to explicitly prohibit BGP from advertising a route it doesnt own, >>even when the nexthop matches that in the forwarding table, we should >>make the other behavior (i.e. advertise even if BGP doesnt own the route >>when the nexthop matches) the recommended one, stating the currently >>stated but least used behavior as an optional alternative. > > > My time to ask for a clarification... > > It seems that you are saying that: > > 1) when the nexthop of a BGP route doesn't match the forwarding > nexthop selected in the routing table that BGP should not advertise > the route. In your words "it breaks routing", or it has the potential > to do so. > > 2) If the next-hop does match, BGP should advertise its route, even if > less preferred. yes & yes. > A second question would be how do you define 'next-hop matching' in > the context of an iBGP route vs an IGP route. Why should iBGP vs IGP come into play? The BGP bestpath calculation would have already given us the best BGP route. If this BGP route (BGP's bestpath) loses to an IGP route with a lower admin-distance then BGP decides whether or not advertise this BGP route. But a BGP bestpath cannot lose to an iBGP route in the routing-table. Because that iBGP route wont be the BGP bestpath. Then why does losing to an iBGP route come into play when it comes to advertising a BGP bestpath? Am I missing what you are trying to say? -Gargi > > regards, > Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 2 10:20:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14659 for ; Tue, 2 Mar 2004 10:20:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBhP-0005CQ-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 10:20:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBgb-00054F-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 10:19:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyBfy-0004vo-00; Tue, 02 Mar 2004 10:19:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBej-0004q1-6b; Tue, 02 Mar 2004 10:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBeJ-0004jo-R6 for idr@optimus.ietf.org; Tue, 02 Mar 2004 10:17:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14381 for ; Tue, 2 Mar 2004 10:17:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBeH-0004ll-00 for idr@ietf.org; Tue, 02 Mar 2004 10:17:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBdK-0004g4-00 for idr@ietf.org; Tue, 02 Mar 2004 10:16:35 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AyBd2-0004Zi-00 for idr@ietf.org; Tue, 02 Mar 2004 10:16:16 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 88A8C2D4957; Tue, 2 Mar 2004 10:15:45 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 57139-01-96; Tue, 2 Mar 2004 10:15:44 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 8A35F2D4965; Tue, 2 Mar 2004 10:15:44 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i22FFiw03346; Tue, 2 Mar 2004 10:15:44 -0500 (EST) From: Jeffrey Haas To: curtis@fictitious.org Cc: Pekka Savola , idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes Message-ID: <20040302101544.A3266@nexthop.com> References: <20040301192732.A21492@nexthop.com> <200403020140.i221eqRX077993@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200403020140.i221eqRX077993@workhorse.fictitious.org>; from curtis@workhorse.fictitious.org on Mon, Mar 01, 2004 at 08:40:52PM -0500 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 10:15:44 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, Mar 01, 2004 at 08:40:52PM -0500, Curtis Villamizar wrote: > If A installs the discard route but not both components, then A's > implementation of aggregation is broken. The installation of the more specifics was presumed. I was talking about BGP aggregation. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 2 10:21:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14687 for ; Tue, 2 Mar 2004 10:21:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBhT-0005oM-HC for idr-archive@odin.ietf.org; Tue, 02 Mar 2004 10:20:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22FKp43022335 for idr-archive@odin.ietf.org; Tue, 2 Mar 2004 10:20:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBhS-0005oA-Bl for idr-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 10:20:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14674 for ; Tue, 2 Mar 2004 10:20:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBhQ-0005CV-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 10:20:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBgc-00054M-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 10:19:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyBfy-0004vo-00; Tue, 02 Mar 2004 10:19:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBej-0004q1-6b; Tue, 02 Mar 2004 10:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBeJ-0004jo-R6 for idr@optimus.ietf.org; Tue, 02 Mar 2004 10:17:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14381 for ; Tue, 2 Mar 2004 10:17:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBeH-0004ll-00 for idr@ietf.org; Tue, 02 Mar 2004 10:17:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBdK-0004g4-00 for idr@ietf.org; Tue, 02 Mar 2004 10:16:35 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AyBd2-0004Zi-00 for idr@ietf.org; Tue, 02 Mar 2004 10:16:16 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 88A8C2D4957; Tue, 2 Mar 2004 10:15:45 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 57139-01-96; Tue, 2 Mar 2004 10:15:44 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 8A35F2D4965; Tue, 2 Mar 2004 10:15:44 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i22FFiw03346; Tue, 2 Mar 2004 10:15:44 -0500 (EST) From: Jeffrey Haas To: curtis@fictitious.org Cc: Pekka Savola , idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes Message-ID: <20040302101544.A3266@nexthop.com> References: <20040301192732.A21492@nexthop.com> <200403020140.i221eqRX077993@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200403020140.i221eqRX077993@workhorse.fictitious.org>; from curtis@workhorse.fictitious.org on Mon, Mar 01, 2004 at 08:40:52PM -0500 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 10:15:44 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, Mar 01, 2004 at 08:40:52PM -0500, Curtis Villamizar wrote: > If A installs the discard route but not both components, then A's > implementation of aggregation is broken. The installation of the more specifics was presumed. I was talking about BGP aggregation. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 2 10:37:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15477 for ; Tue, 2 Mar 2004 10:37:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBxo-0007ON-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 10:37:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBwo-0007G1-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 10:36:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyBwP-00078I-00; Tue, 02 Mar 2004 10:36:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBwB-0006ly-6r; Tue, 02 Mar 2004 10:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBvl-0006kt-8x for idr@optimus.ietf.org; Tue, 02 Mar 2004 10:35:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15409 for ; Tue, 2 Mar 2004 10:35:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBvi-00076a-00 for idr@ietf.org; Tue, 02 Mar 2004 10:35:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBun-00070T-00 for idr@ietf.org; Tue, 02 Mar 2004 10:34:38 -0500 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx with esmtp (Exim 4.12) id 1AyBuR-0006uE-00 for idr@ietf.org; Tue, 02 Mar 2004 10:34:15 -0500 Received: (qmail 6547 invoked by uid 1021); 2 Mar 2004 15:34:06 -0000 From: vijay gill To: Pedro Roque Marques Cc: gargi@cisco.com, idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) Message-ID: <20040302153406.GA5590@vijaygill.com> References: <40442200.3030904@cisco.com> <200403020645.i226jiF4050962@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403020645.i226jiF4050962@roque-bsd.juniper.net> User-Agent: Mutt/1.3.28i Organization: vijay gill global logistics Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 15:34:06 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 What BGP does should be separate from anything else. You have the bgp database, operate on the BGP database. Pick routes, only look to see if you have a valid next-hop, and then continue on. If you have an identical route that is more preferred by whatever mechanism that does the 'pick what route to install in the forwarding table' why does this affect bgp. This leads to things like advertise-inactive and each time there is a new install of a juniper box, you have to write a paragraph on advertise-inactive and why it is needed. I've done this for too many jnx qual docs and it is starting to annoy the @#$# out of me. I am fully willing to change my opinion but I've long maintained that each routing protocol should have its own tables and it is up to the user to ensure that they are topologically sane. /vijay _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 2 10:38:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15513 for ; Tue, 2 Mar 2004 10:38:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBxs-0007MQ-Fa for idr-archive@odin.ietf.org; Tue, 02 Mar 2004 10:37:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22Fbm3L028275 for idr-archive@odin.ietf.org; Tue, 2 Mar 2004 10:37:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBxr-0007Lu-Ix for idr-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 10:37:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15495 for ; Tue, 2 Mar 2004 10:37:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBxp-0007OS-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 10:37:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBwp-0007G8-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 10:36:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyBwP-00078I-00; Tue, 02 Mar 2004 10:36:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBwB-0006ly-6r; Tue, 02 Mar 2004 10:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBvl-0006kt-8x for idr@optimus.ietf.org; Tue, 02 Mar 2004 10:35:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15409 for ; Tue, 2 Mar 2004 10:35:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBvi-00076a-00 for idr@ietf.org; Tue, 02 Mar 2004 10:35:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBun-00070T-00 for idr@ietf.org; Tue, 02 Mar 2004 10:34:38 -0500 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx with esmtp (Exim 4.12) id 1AyBuR-0006uE-00 for idr@ietf.org; Tue, 02 Mar 2004 10:34:15 -0500 Received: (qmail 6547 invoked by uid 1021); 2 Mar 2004 15:34:06 -0000 From: vijay gill To: Pedro Roque Marques Cc: gargi@cisco.com, idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) Message-ID: <20040302153406.GA5590@vijaygill.com> References: <40442200.3030904@cisco.com> <200403020645.i226jiF4050962@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403020645.i226jiF4050962@roque-bsd.juniper.net> User-Agent: Mutt/1.3.28i Organization: vijay gill global logistics Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 15:34:06 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 What BGP does should be separate from anything else. You have the bgp database, operate on the BGP database. Pick routes, only look to see if you have a valid next-hop, and then continue on. If you have an identical route that is more preferred by whatever mechanism that does the 'pick what route to install in the forwarding table' why does this affect bgp. This leads to things like advertise-inactive and each time there is a new install of a juniper box, you have to write a paragraph on advertise-inactive and why it is needed. I've done this for too many jnx qual docs and it is starting to annoy the @#$# out of me. I am fully willing to change my opinion but I've long maintained that each routing protocol should have its own tables and it is up to the user to ensure that they are topologically sane. /vijay _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 2 12:59:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21275 for ; Tue, 2 Mar 2004 12:59:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyEBK-0002wS-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 12:59:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyEAN-0002n7-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 12:58:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyE9o-0002eg-00; Tue, 02 Mar 2004 12:58:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyE9b-0005mU-5A; Tue, 02 Mar 2004 12:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyE9I-0005hL-KG for idr@optimus.ietf.org; Tue, 02 Mar 2004 12:57:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21205 for ; Tue, 2 Mar 2004 12:57:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyE9G-0002d7-00 for idr@ietf.org; Tue, 02 Mar 2004 12:57:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyE8P-0002WK-00 for idr@ietf.org; Tue, 02 Mar 2004 12:56:49 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AyE87-0002OO-00 for idr@ietf.org; Tue, 02 Mar 2004 12:56:32 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i22Hts1K052101; Tue, 2 Mar 2004 09:55:54 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i22HtsCp052098; Tue, 2 Mar 2004 09:55:54 -0800 (PST) Message-Id: <200403021755.i22HtsCp052098@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: gargi@cisco.com Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: <40443AA7.2010804@cisco.com> References: <40442200.3030904@cisco.com> <200403020645.i226jiF4050962@roque-bsd.juniper.net> <40443AA7.2010804@cisco.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 09:55:54 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Gargi Nalawade writes: >> >> My time to ask for a clarification... >> >> It seems that you are saying that: >> >> 1) when the nexthop of a BGP route doesn't match the forwarding >> nexthop selected in the routing table that BGP should not advertise >> the route. In your words "it breaks routing", or it has the >> potential to do so. >> >> 2) If the next-hop does match, BGP should advertise its route, even >> if less preferred. > yes & yes. Thanks. You should probably write an Internet-Draft that describes that behaviour then. >> A second question would be how do you define 'next-hop matching' in >> the context of an iBGP route vs an IGP route. > Am I missing what you are trying to say? You have two routes for the same prefix. i.e. 10.0.1/24 OSPF nexthop 1 10.0.1/24 iBGP nexthop 2 What do you consider nexthop to be... i.e. in terms of iBGP is 'next-hop' the NEXT_HOP BGP attribute as advertised by the remote peer ? Or is this a directly connected next-hop obtained via route resolution. It would be nice to have the answer to that question, in case you do decide to write an I-D. regards, Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 2 13:00:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21335 for ; Tue, 2 Mar 2004 13:00:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyEBN-0006Ij-TT for idr-archive@odin.ietf.org; Tue, 02 Mar 2004 12:59:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22HxrF1024214 for idr-archive@odin.ietf.org; Tue, 2 Mar 2004 12:59:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyEBN-0006IF-Lm for idr-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 12:59:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21293 for ; Tue, 2 Mar 2004 12:59:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyEBL-0002wZ-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 12:59:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyEAO-0002nF-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 12:58:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyE9o-0002eg-00; Tue, 02 Mar 2004 12:58:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyE9b-0005mU-5A; Tue, 02 Mar 2004 12:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyE9I-0005hL-KG for idr@optimus.ietf.org; Tue, 02 Mar 2004 12:57:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21205 for ; Tue, 2 Mar 2004 12:57:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyE9G-0002d7-00 for idr@ietf.org; Tue, 02 Mar 2004 12:57:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyE8P-0002WK-00 for idr@ietf.org; Tue, 02 Mar 2004 12:56:49 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AyE87-0002OO-00 for idr@ietf.org; Tue, 02 Mar 2004 12:56:32 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i22Hts1K052101; Tue, 2 Mar 2004 09:55:54 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i22HtsCp052098; Tue, 2 Mar 2004 09:55:54 -0800 (PST) Message-Id: <200403021755.i22HtsCp052098@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: gargi@cisco.com Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: <40443AA7.2010804@cisco.com> References: <40442200.3030904@cisco.com> <200403020645.i226jiF4050962@roque-bsd.juniper.net> <40443AA7.2010804@cisco.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 09:55:54 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Gargi Nalawade writes: >> >> My time to ask for a clarification... >> >> It seems that you are saying that: >> >> 1) when the nexthop of a BGP route doesn't match the forwarding >> nexthop selected in the routing table that BGP should not advertise >> the route. In your words "it breaks routing", or it has the >> potential to do so. >> >> 2) If the next-hop does match, BGP should advertise its route, even >> if less preferred. > yes & yes. Thanks. You should probably write an Internet-Draft that describes that behaviour then. >> A second question would be how do you define 'next-hop matching' in >> the context of an iBGP route vs an IGP route. > Am I missing what you are trying to say? You have two routes for the same prefix. i.e. 10.0.1/24 OSPF nexthop 1 10.0.1/24 iBGP nexthop 2 What do you consider nexthop to be... i.e. in terms of iBGP is 'next-hop' the NEXT_HOP BGP attribute as advertised by the remote peer ? Or is this a directly connected next-hop obtained via route resolution. It would be nice to have the answer to that question, in case you do decide to write an I-D. regards, Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 2 15:45:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00109 for ; Tue, 2 Mar 2004 15:45:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyGly-0003Mz-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 15:45:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyGlA-0003El-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 15:45:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyGkc-00035w-00; Tue, 02 Mar 2004 15:44:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyGkC-0008FA-Ua; Tue, 02 Mar 2004 15:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyC5O-0007z5-Qp for idr@optimus.ietf.org; Tue, 02 Mar 2004 10:45:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16029 for ; Tue, 2 Mar 2004 10:45:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyC5K-0000bc-00 for idr@ietf.org; Tue, 02 Mar 2004 10:45:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyC4M-0000Uk-00 for idr@ietf.org; Tue, 02 Mar 2004 10:44:30 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AyC3M-0000JQ-00 for idr@ietf.org; Tue, 02 Mar 2004 10:43:29 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i22Fg3kL083856; Tue, 2 Mar 2004 10:42:03 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403021542.i22Fg3kL083856@workhorse.fictitious.org> To: Pedro Roque Marques cc: Pekka Savola , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: Your message of "Mon, 01 Mar 2004 17:56:09 PST." <200403020156.i221u9jf050325@roque-bsd.juniper.net> From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Mar 2004 10:42:03 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <200403020156.i221u9jf050325@roque-bsd.juniper.net>, Pedro Roque Mar ques writes: > Pekka Savola writes: > > > My interpretation of the spec (and a vendor's, as well) is that this > > is not considered at all in the current spec. And if we disagree, > > it calls for EVEN MORE LOUDLY for a clarification! > > [...] > > > No -- the current spec is just looking up a route -- it takes no > > stance what kind of 'route' that is. > > By your own admission the spec doesn't require clarification. It is > clear that it doesn't understand the next-hop type of a route. > > > This needs to be specified. > > What you mean by this is that you believe that the current behaviour > should be modified... > > Even if we where to agree that the behaviour you and Curtis propose is > more desirable than the current one, it isn't feasible to modify the > behaviour of current systems. > > The modification you propose also isn't suficient to address the > problem that you point out whenever your aggregate route has a > reachable next-hop. > > Examples where this could happen: > > - User wants to forward all traffic that hits the default route to a > remote box that analyzes traffic... i.e. 0/0 to an LSP to a traffic > collector. That's a default route that forwards traffic, not a discard route. > - Network is divided in areas but has global IGP. Each area border > generates a summary of address in the are that is propagated across > the network. i.e. outside the area you see an aggregate via BGP and > more specific /32s. That route also forwards traffic. It is not a discard route. On the aggregator itself, there had better be a more specific route or if not the routes should be considered infeasible. If the aggregator which also happens to be an EIBGP router where confederations are used then the aggregator is also passing the BGP routes from the border router that went down. When the hole in the aggregate occurs if the discard route is allowed to pass the reachability test, then the BGP routes remain in the rest of the AS until the BGP session times out - a very long time. This quite obviously is bad for SLAs and if some of those routes had alternates there might be some unhappy customers (you could also argue that if they didn't have alternates they'd be even more unhappy). If the discard does not cause the reachability test to pass, then the BGP routes advertised by the border router that went down go down in IGP time (seconds and possibly sub-second - YMMV). An occasional fault and recovery in seconds doesn't violate most SLAs and customers also don't see substantial impact. If the IGP aggregates, as it does in OSPF areas, but the aggregators are not either RRs or confed boundaries, then the test for reachability does not occur on the aggregator and that can be a problem. The only current solution is to not aggregate the addresses used for the infrastructure within the AS, but aggregate those prefixes outside the AS. There really is not alternative. Once the aggregate is formed information is lost that is needed to quickly withdraw the routes due to the reachability change. This is certainly a topic for a BCP but we don't need to put anything in the BGP spec. ... that said, I think I'll go back and check our implementation. > Pedro. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 2 15:46:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00159 for ; Tue, 2 Mar 2004 15:46:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyGm1-00007f-5o for idr-archive@odin.ietf.org; Tue, 02 Mar 2004 15:45:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22Kjrv3000465 for idr-archive@odin.ietf.org; Tue, 2 Mar 2004 15:45:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyGm1-00007Q-1R for idr-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 15:45:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00129 for ; Tue, 2 Mar 2004 15:45:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyGlz-0003N4-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 15:45:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyGlB-0003Es-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 15:45:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyGkc-00035w-00; Tue, 02 Mar 2004 15:44:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyGkC-0008FA-Ua; Tue, 02 Mar 2004 15:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyC5O-0007z5-Qp for idr@optimus.ietf.org; Tue, 02 Mar 2004 10:45:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16029 for ; Tue, 2 Mar 2004 10:45:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyC5K-0000bc-00 for idr@ietf.org; Tue, 02 Mar 2004 10:45:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyC4M-0000Uk-00 for idr@ietf.org; Tue, 02 Mar 2004 10:44:30 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AyC3M-0000JQ-00 for idr@ietf.org; Tue, 02 Mar 2004 10:43:29 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i22Fg3kL083856; Tue, 2 Mar 2004 10:42:03 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403021542.i22Fg3kL083856@workhorse.fictitious.org> To: Pedro Roque Marques cc: Pekka Savola , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: Your message of "Mon, 01 Mar 2004 17:56:09 PST." <200403020156.i221u9jf050325@roque-bsd.juniper.net> From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Mar 2004 10:42:03 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <200403020156.i221u9jf050325@roque-bsd.juniper.net>, Pedro Roque Mar ques writes: > Pekka Savola writes: > > > My interpretation of the spec (and a vendor's, as well) is that this > > is not considered at all in the current spec. And if we disagree, > > it calls for EVEN MORE LOUDLY for a clarification! > > [...] > > > No -- the current spec is just looking up a route -- it takes no > > stance what kind of 'route' that is. > > By your own admission the spec doesn't require clarification. It is > clear that it doesn't understand the next-hop type of a route. > > > This needs to be specified. > > What you mean by this is that you believe that the current behaviour > should be modified... > > Even if we where to agree that the behaviour you and Curtis propose is > more desirable than the current one, it isn't feasible to modify the > behaviour of current systems. > > The modification you propose also isn't suficient to address the > problem that you point out whenever your aggregate route has a > reachable next-hop. > > Examples where this could happen: > > - User wants to forward all traffic that hits the default route to a > remote box that analyzes traffic... i.e. 0/0 to an LSP to a traffic > collector. That's a default route that forwards traffic, not a discard route. > - Network is divided in areas but has global IGP. Each area border > generates a summary of address in the are that is propagated across > the network. i.e. outside the area you see an aggregate via BGP and > more specific /32s. That route also forwards traffic. It is not a discard route. On the aggregator itself, there had better be a more specific route or if not the routes should be considered infeasible. If the aggregator which also happens to be an EIBGP router where confederations are used then the aggregator is also passing the BGP routes from the border router that went down. When the hole in the aggregate occurs if the discard route is allowed to pass the reachability test, then the BGP routes remain in the rest of the AS until the BGP session times out - a very long time. This quite obviously is bad for SLAs and if some of those routes had alternates there might be some unhappy customers (you could also argue that if they didn't have alternates they'd be even more unhappy). If the discard does not cause the reachability test to pass, then the BGP routes advertised by the border router that went down go down in IGP time (seconds and possibly sub-second - YMMV). An occasional fault and recovery in seconds doesn't violate most SLAs and customers also don't see substantial impact. If the IGP aggregates, as it does in OSPF areas, but the aggregators are not either RRs or confed boundaries, then the test for reachability does not occur on the aggregator and that can be a problem. The only current solution is to not aggregate the addresses used for the infrastructure within the AS, but aggregate those prefixes outside the AS. There really is not alternative. Once the aggregate is formed information is lost that is needed to quickly withdraw the routes due to the reachability change. This is certainly a topic for a BCP but we don't need to put anything in the BGP spec. ... that said, I think I'll go back and check our implementation. > Pedro. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 2 17:51:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05732 for ; Tue, 2 Mar 2004 17:51:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyIju-0005Gq-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 17:51:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyIj2-00058v-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 17:50:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyIiN-00051j-00; Tue, 02 Mar 2004 17:50:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyIiA-000447-TR; Tue, 02 Mar 2004 17:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyIhw-00043g-D1 for idr@optimus.ietf.org; Tue, 02 Mar 2004 17:49:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05703 for ; Tue, 2 Mar 2004 17:49:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyIht-0004zq-00 for idr@ietf.org; Tue, 02 Mar 2004 17:49:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyIgv-0004tH-00 for idr@ietf.org; Tue, 02 Mar 2004 17:48:46 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AyIg1-0004gy-00 for idr@ietf.org; Tue, 02 Mar 2004 17:47:49 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i22MlJ1K052564; Tue, 2 Mar 2004 14:47:19 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i22MlJXN052561; Tue, 2 Mar 2004 14:47:19 -0800 (PST) Message-Id: <200403022247.i22MlJXN052561@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: vijay gill Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: <20040302153406.GA5590@vijaygill.com> References: <40442200.3030904@cisco.com> <200403020645.i226jiF4050962@roque-bsd.juniper.net> <20040302153406.GA5590@vijaygill.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 14:47:19 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit vijay gill writes: > What BGP does should be separate from anything else. You have the > bgp database, operate on the BGP database. Pick routes, only look to > see if you have a valid next-hop, and then continue on. Vijay, I'm sure that your view as its merits... but we also need to consider the question the other way around. When you receive a BGP advertisement from a neighbor, do you expect traffic sent to that neighbor to follow the ASes that are present in the corresponding routing advertisement ? Do you make any assumptions based on the contents of such as-path attribute ? Is it a 'feature' or a 'bug' if traffic doesn't follow the path advertised by routing... This is an issue that exists today... and not strictly related to the advertisement of inactive paths. I believe CAIDA has made measurements of such inconsistencies. But while it is easy for all of us to say "i'd like to be able to do whatever i want" a more interesting question is "what i would like others to contrain themselfs to"... Disabling the advertisement of inactive routes is not a panacea that will address all inconsistencies, assuming one does care about those... Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 2 17:52:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05762 for ; Tue, 2 Mar 2004 17:52:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyIk0-0004Ds-1T for idr-archive@odin.ietf.org; Tue, 02 Mar 2004 17:51:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22MpuMf016226 for idr-archive@odin.ietf.org; Tue, 2 Mar 2004 17:51:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyIjz-0004Dd-Sy for idr-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 17:51:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05750 for ; Tue, 2 Mar 2004 17:51:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyIjx-0005HB-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 17:51:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyIj3-000597-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 17:50:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyIiN-00051j-00; Tue, 02 Mar 2004 17:50:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyIiA-000447-TR; Tue, 02 Mar 2004 17:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyIhw-00043g-D1 for idr@optimus.ietf.org; Tue, 02 Mar 2004 17:49:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05703 for ; Tue, 2 Mar 2004 17:49:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyIht-0004zq-00 for idr@ietf.org; Tue, 02 Mar 2004 17:49:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyIgv-0004tH-00 for idr@ietf.org; Tue, 02 Mar 2004 17:48:46 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AyIg1-0004gy-00 for idr@ietf.org; Tue, 02 Mar 2004 17:47:49 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i22MlJ1K052564; Tue, 2 Mar 2004 14:47:19 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i22MlJXN052561; Tue, 2 Mar 2004 14:47:19 -0800 (PST) Message-Id: <200403022247.i22MlJXN052561@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: vijay gill Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: <20040302153406.GA5590@vijaygill.com> References: <40442200.3030904@cisco.com> <200403020645.i226jiF4050962@roque-bsd.juniper.net> <20040302153406.GA5590@vijaygill.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 14:47:19 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit vijay gill writes: > What BGP does should be separate from anything else. You have the > bgp database, operate on the BGP database. Pick routes, only look to > see if you have a valid next-hop, and then continue on. Vijay, I'm sure that your view as its merits... but we also need to consider the question the other way around. When you receive a BGP advertisement from a neighbor, do you expect traffic sent to that neighbor to follow the ASes that are present in the corresponding routing advertisement ? Do you make any assumptions based on the contents of such as-path attribute ? Is it a 'feature' or a 'bug' if traffic doesn't follow the path advertised by routing... This is an issue that exists today... and not strictly related to the advertisement of inactive paths. I believe CAIDA has made measurements of such inconsistencies. But while it is easy for all of us to say "i'd like to be able to do whatever i want" a more interesting question is "what i would like others to contrain themselfs to"... Disabling the advertisement of inactive routes is not a panacea that will address all inconsistencies, assuming one does care about those... Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 2 18:21:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08328 for ; Tue, 2 Mar 2004 18:21:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyJD2-0001eV-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 18:21:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyJC5-0001W3-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 18:20:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyJBN-0001O6-00; Tue, 02 Mar 2004 18:20:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJBE-0005WZ-BF; Tue, 02 Mar 2004 18:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJAR-0005HS-6L for idr@optimus.ietf.org; Tue, 02 Mar 2004 18:19:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08114 for ; Tue, 2 Mar 2004 18:19:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyJAN-0001D1-00 for idr@ietf.org; Tue, 02 Mar 2004 18:19:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyJ9L-00011a-00 for idr@ietf.org; Tue, 02 Mar 2004 18:18:08 -0500 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx with esmtp (Exim 4.12) id 1AyJ8a-0000rs-00 for idr@ietf.org; Tue, 02 Mar 2004 18:17:20 -0500 Received: (qmail 27420 invoked by uid 1021); 2 Mar 2004 23:17:11 -0000 From: vijay gill To: Pedro Roque Marques Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) Message-ID: <20040302231711.GC21017@vijaygill.com> References: <40442200.3030904@cisco.com> <200403020645.i226jiF4050962@roque-bsd.juniper.net> <20040302153406.GA5590@vijaygill.com> <200403022247.i22MlJXN052561@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403022247.i22MlJXN052561@roque-bsd.juniper.net> User-Agent: Mutt/1.3.28i Organization: vijay gill global logistics Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 23:17:11 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Tue, Mar 02, 2004 at 02:47:19PM -0800, Pedro Roque Marques wrote: > When you receive a BGP advertisement from a neighbor, do you expect > traffic sent to that neighbor to follow the ASes that are present in > the corresponding routing advertisement ? Yes, but right now, nothing prevents that person from putting a static up that points any traffic I send to that AS right back out the current pipe. I am saying is that you are trying to solve a problem which a) isn't a huge thing in practice and b) _cannot_ be solved. > Is it a 'feature' or a 'bug' if traffic doesn't follow the path > advertised by routing... it is a bug obviously, but insofar as BGP knows, it is setting up a correct loop-free graph and it really should restrict itself to doing that, as opposed to trying to figure out all the myriad ways traffic can go wrong. > This is an issue that exists today... and not strictly related to the > advertisement of inactive paths. I believe CAIDA has made measurements > of such inconsistencies. I think we need more results from randy's happy packets research. > But while it is easy for all of us to say "i'd like to be able to do > whatever i want" a more interesting question is "what i would like > others to contrain themselfs to"... But I don't worry how say, my bgp peers AS routes traffic internally. It is not within my bailiwick to worry about it, they could be using statics for all I care. my concern is that they send me an accurate prefix set that they are transiting and I give them traffic for that prefix set. I think we are starting to loop here. /vijay _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 2 18:22:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08360 for ; Tue, 2 Mar 2004 18:22:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJD6-0006Au-On for idr-archive@odin.ietf.org; Tue, 02 Mar 2004 18:22:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22NM0vt023730 for idr-archive@odin.ietf.org; Tue, 2 Mar 2004 18:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJD6-0006Ac-1t for idr-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 18:22:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08339 for ; Tue, 2 Mar 2004 18:21:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyJD3-0001ea-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 18:21:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyJC6-0001WA-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 18:20:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyJBN-0001O6-00; Tue, 02 Mar 2004 18:20:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJBE-0005WZ-BF; Tue, 02 Mar 2004 18:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJAR-0005HS-6L for idr@optimus.ietf.org; Tue, 02 Mar 2004 18:19:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08114 for ; Tue, 2 Mar 2004 18:19:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyJAN-0001D1-00 for idr@ietf.org; Tue, 02 Mar 2004 18:19:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyJ9L-00011a-00 for idr@ietf.org; Tue, 02 Mar 2004 18:18:08 -0500 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx with esmtp (Exim 4.12) id 1AyJ8a-0000rs-00 for idr@ietf.org; Tue, 02 Mar 2004 18:17:20 -0500 Received: (qmail 27420 invoked by uid 1021); 2 Mar 2004 23:17:11 -0000 From: vijay gill To: Pedro Roque Marques Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) Message-ID: <20040302231711.GC21017@vijaygill.com> References: <40442200.3030904@cisco.com> <200403020645.i226jiF4050962@roque-bsd.juniper.net> <20040302153406.GA5590@vijaygill.com> <200403022247.i22MlJXN052561@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403022247.i22MlJXN052561@roque-bsd.juniper.net> User-Agent: Mutt/1.3.28i Organization: vijay gill global logistics Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 23:17:11 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Tue, Mar 02, 2004 at 02:47:19PM -0800, Pedro Roque Marques wrote: > When you receive a BGP advertisement from a neighbor, do you expect > traffic sent to that neighbor to follow the ASes that are present in > the corresponding routing advertisement ? Yes, but right now, nothing prevents that person from putting a static up that points any traffic I send to that AS right back out the current pipe. I am saying is that you are trying to solve a problem which a) isn't a huge thing in practice and b) _cannot_ be solved. > Is it a 'feature' or a 'bug' if traffic doesn't follow the path > advertised by routing... it is a bug obviously, but insofar as BGP knows, it is setting up a correct loop-free graph and it really should restrict itself to doing that, as opposed to trying to figure out all the myriad ways traffic can go wrong. > This is an issue that exists today... and not strictly related to the > advertisement of inactive paths. I believe CAIDA has made measurements > of such inconsistencies. I think we need more results from randy's happy packets research. > But while it is easy for all of us to say "i'd like to be able to do > whatever i want" a more interesting question is "what i would like > others to contrain themselfs to"... But I don't worry how say, my bgp peers AS routes traffic internally. It is not within my bailiwick to worry about it, they could be using statics for all I care. my concern is that they send me an accurate prefix set that they are transiting and I give them traffic for that prefix set. I think we are starting to loop here. /vijay _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 2 20:38:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18855 for ; Tue, 2 Mar 2004 20:38:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLKk-0000ae-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 20:38:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLK0-0000Rd-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 20:37:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyLJ3-0000HC-00; Tue, 02 Mar 2004 20:36:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLHs-0001YS-EE; Tue, 02 Mar 2004 20:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLGz-0001SD-SL for idr@optimus.ietf.org; Tue, 02 Mar 2004 20:34:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18462 for ; Tue, 2 Mar 2004 20:34:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLGx-0007lq-00 for idr@ietf.org; Tue, 02 Mar 2004 20:34:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLGD-0007Zf-00 for idr@ietf.org; Tue, 02 Mar 2004 20:33:22 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AyLEl-00074K-00 for idr@ietf.org; Tue, 02 Mar 2004 20:31:51 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i231VFi13770 for ; Tue, 2 Mar 2004 20:31:15 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Mar 2004 20:31:15 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A5AECCB@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: idr@ietf.org Subject: RE: [Idr] FW: IDR minutes MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 20:31:14 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 hi I believe we also briefly discussed setting up a call to discuss the v2 MIB and that interested parties should contact either Sue or myself. Sharon -----Original Message----- From: Susan Hares [mailto:shares@nexthop.com] Sent: Monday, March 01, 2004 10:40 PM To: idr@ietf.org Subject: [Idr] FW: IDR minutes Minutes for 3/1/04 session -----Original Message----- From: Jake Khuon Sent: Monday, March 01, 2004 3:18 AM To: Susan Hares; yakov@juniper.net Subject: IDR minutes Inter-Domain Routing WG (idr) Monday, March 1 at 1530-1730 ================================== CHAIRS: Sue Hares (skh@nexthop.com) Yakov Rekhter (yakov@juniper.net) AGENDA: 1) Agenda Bashing Agenda Slides 2) Document status [5 minutes] - Bundle went to IESG BGP-4 draft-23 draft-ietf-idr-bgp4-23.txt BGP-4 V1 MIB draft-ietf-idr-bgp4-mib-13.txt BGP-4 Protocol Analysis draft-ietf-idr-bgp-analysis-04.txt BGP Security Vulnerabilities Analysis draft-ietf-idr-bgp-vuln-00.txt Experience with the BGP-4 Protocol draft-ietf-idr-bgp4-experience-protocol-03.txt BGP 4 Implementation Report draft-ietf-idr-bgp-implementation-00.txt BGP-4 V1 MIB implementation report draft-ietf-idr-bgp-mibagent-survey-01.txt Presentation 3) Implementation Reports and FSM issues for current drafts [10 minutes] document: None, presentation only Presentation Sue Hares - Yakov: route-reflector update status? - Enke: route-reflector update (4 weeks) - Enke: prefix-orf was not added to charter - Sue: yes it was added, administrative error in listing 4) BGP Peer Restart Backoff Mechanisms [10 minutes] document: draft-hares-bgp-backoff-01.txt (ietf) (-02 Update) Author: Susan Hares Presentation Sue Hares - Alex: draft should say informational achieve functionality using existing states? - Sue: no... can't use existing states; already investigated that option 5) Deterministic Route Redistribution into BGP [10 minutes] document: draft-chen-bgp-redist-00.txt Authors: Jenny Yuan, Enke Chen Enke Chen - Andrew Lang: used to use configured localpref tweaking; not management intensive... unsure if this is needed - Enke: timing dependent non-deterministic problem so current knobs cannot be used reliably; does not break anything... backwards compatible - Andrew Lang: better to educate people about localpref - Barry Friedman: lacks generality too narrow a problem space... only addresses RIP/iBGP interaction - Enke: tweaking of admin distance defines a baseline - need per route granularity to solve for all cases? Possibility of adding more configuration conflicts. - Alex: this problem only occurs if there's a consistancy issue between two places... May not be an issue for a single selection point. Introduction of new step will effect current edployment traffic selection? - Enke: This will happen regardless. Should not effect current deployments and if there's a change, the change will be for the better. - By definition, it does change behaviour. - Alex: Will this be applicable to only situations where there is a problem? - Yakov: Is this an implimentation method? - Alex: Is this informational or standards-track? - Enke: Either is fine - It can't be a local matter because it must be consistant throughout the entire system - Enke: Decision on redistributed routes is made locally in each router - Behaviour is changed because new code now uses admin distance over localpref? - Enke: If only localpref is used then things should not change - Cengiz: If route-reflector is used? - Enke: I need to think about it further 6) BGP based auto-discovery [Sue Hares, P. Unbehagen] [10 minutes] document: draft-hlmu-l2vpn-bgp-discovery-00.txt authors: P. Unbehagen, P. Muley, V. Radoaca, Susan Hares Presentation Sue Hares, P. Unbehagen - Already a L2VPN draft that addresses this in a defined NLRI with label information - Paul: This draft is meant to provide LDP pseudowire config information - Other spec can do same thing [autodiscovery] without label information - Kireeti: Would like to be able to use this AFI with different SAFI [65] and NLRI format - Would the two SAFIs be solving similar problems - Kireeti: My SAFI solves different problems 7) BGP Assignment of AFI/SAFI address [10 minutes] Document: draft-hares-bgp-assign-afisafi-00.txt Author: Susan Hares Presentation Sue Hares 8) BGP Attribute Codes and Suggested Procedures Document: draft-kompella-zinin-early-allocation-00.txt Author: Alex Zinin, Kireeti Kompella Presentation Alex Zinin - Sharon: talking about protocols and not OIDs preallocation? bad to preallocate in the MIB... different from what other WGs; exclude MIB OIDs - Kireeti: not suggesting that everyone use this - It would have been nicer to have had OIDs preallocated so as not to reimpliment the MIB - Sharon: OIDs not allocated to drafts because if the drafts goes away then you've wasted numbers - Lou Berger: allocation with 1 year with 1 renewal is too short; alterntate policy: as long as draft or version is alive, expire in 3 to 6 months - Alex: that suggestion ties validity with ability of author to submit the draft; suggestion: once document is submitted to IESG then we freeze. Don't want to allocate codepoints too early. - Dave Meyer: Are you sure that IANA can time anything out - Alex: No - Dave Meyer: WG chair needs to manage this? - What happens if the allocation is not renewed and code is using it still? - Alex: Add provision to document to deprecate but not return - Kireeti: Deprecate for a period of time to give people time to remove. Formal process to do early allocations and if it goes through then stick with it but if it doesn't go through then people must take this out. - Dino: Allocate experimental codepoints and once standardised, then adopt standard codepoint for sending but accept both. - Sue: Good for SAFIs as well as AFIs? - Dino: All well known IANA values - Fenner: RFC already documents a process for transitioning codepoints 9) Charter Discussion [20 minutes] Thanks to all implementers who send in reports on the the base specification, we will be opening the charter. This section of the meeting will discuss what items will be added to the charter. Presentation - Top three most important; maybe ECMP little higher than Fault Isolation -- /*==================[ Jake Khuon ]=====================+ | Field App. Engineer http://www.nexthop.com/ /\ /~ E X T H O P | | Ofc: +1 (425) 391-2262 Fax: +1 (425) 391-6772 / \/ Technologies, Inc.| +==========[ 1911 Landings Drive, Mountain View, CA 94043 USA ]===========*/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 2 20:38:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18912 for ; Tue, 2 Mar 2004 20:38:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLKo-0002YS-ES for idr-archive@odin.ietf.org; Tue, 02 Mar 2004 20:38:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i231c6m8009819 for idr-archive@odin.ietf.org; Tue, 2 Mar 2004 20:38:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLKo-0002YA-0j for idr-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 20:38:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18870 for ; Tue, 2 Mar 2004 20:38:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLKl-0000al-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 20:38:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLK1-0000Rk-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 20:37:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyLJ3-0000HC-00; Tue, 02 Mar 2004 20:36:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLHs-0001YS-EE; Tue, 02 Mar 2004 20:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLGz-0001SD-SL for idr@optimus.ietf.org; Tue, 02 Mar 2004 20:34:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18462 for ; Tue, 2 Mar 2004 20:34:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLGx-0007lq-00 for idr@ietf.org; Tue, 02 Mar 2004 20:34:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLGD-0007Zf-00 for idr@ietf.org; Tue, 02 Mar 2004 20:33:22 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AyLEl-00074K-00 for idr@ietf.org; Tue, 02 Mar 2004 20:31:51 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i231VFi13770 for ; Tue, 2 Mar 2004 20:31:15 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Mar 2004 20:31:15 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A5AECCB@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: idr@ietf.org Subject: RE: [Idr] FW: IDR minutes MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 20:31:14 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 hi I believe we also briefly discussed setting up a call to discuss the v2 MIB and that interested parties should contact either Sue or myself. Sharon -----Original Message----- From: Susan Hares [mailto:shares@nexthop.com] Sent: Monday, March 01, 2004 10:40 PM To: idr@ietf.org Subject: [Idr] FW: IDR minutes Minutes for 3/1/04 session -----Original Message----- From: Jake Khuon Sent: Monday, March 01, 2004 3:18 AM To: Susan Hares; yakov@juniper.net Subject: IDR minutes Inter-Domain Routing WG (idr) Monday, March 1 at 1530-1730 ================================== CHAIRS: Sue Hares (skh@nexthop.com) Yakov Rekhter (yakov@juniper.net) AGENDA: 1) Agenda Bashing Agenda Slides 2) Document status [5 minutes] - Bundle went to IESG BGP-4 draft-23 draft-ietf-idr-bgp4-23.txt BGP-4 V1 MIB draft-ietf-idr-bgp4-mib-13.txt BGP-4 Protocol Analysis draft-ietf-idr-bgp-analysis-04.txt BGP Security Vulnerabilities Analysis draft-ietf-idr-bgp-vuln-00.txt Experience with the BGP-4 Protocol draft-ietf-idr-bgp4-experience-protocol-03.txt BGP 4 Implementation Report draft-ietf-idr-bgp-implementation-00.txt BGP-4 V1 MIB implementation report draft-ietf-idr-bgp-mibagent-survey-01.txt Presentation 3) Implementation Reports and FSM issues for current drafts [10 minutes] document: None, presentation only Presentation Sue Hares - Yakov: route-reflector update status? - Enke: route-reflector update (4 weeks) - Enke: prefix-orf was not added to charter - Sue: yes it was added, administrative error in listing 4) BGP Peer Restart Backoff Mechanisms [10 minutes] document: draft-hares-bgp-backoff-01.txt (ietf) (-02 Update) Author: Susan Hares Presentation Sue Hares - Alex: draft should say informational achieve functionality using existing states? - Sue: no... can't use existing states; already investigated that option 5) Deterministic Route Redistribution into BGP [10 minutes] document: draft-chen-bgp-redist-00.txt Authors: Jenny Yuan, Enke Chen Enke Chen - Andrew Lang: used to use configured localpref tweaking; not management intensive... unsure if this is needed - Enke: timing dependent non-deterministic problem so current knobs cannot be used reliably; does not break anything... backwards compatible - Andrew Lang: better to educate people about localpref - Barry Friedman: lacks generality too narrow a problem space... only addresses RIP/iBGP interaction - Enke: tweaking of admin distance defines a baseline - need per route granularity to solve for all cases? Possibility of adding more configuration conflicts. - Alex: this problem only occurs if there's a consistancy issue between two places... May not be an issue for a single selection point. Introduction of new step will effect current edployment traffic selection? - Enke: This will happen regardless. Should not effect current deployments and if there's a change, the change will be for the better. - By definition, it does change behaviour. - Alex: Will this be applicable to only situations where there is a problem? - Yakov: Is this an implimentation method? - Alex: Is this informational or standards-track? - Enke: Either is fine - It can't be a local matter because it must be consistant throughout the entire system - Enke: Decision on redistributed routes is made locally in each router - Behaviour is changed because new code now uses admin distance over localpref? - Enke: If only localpref is used then things should not change - Cengiz: If route-reflector is used? - Enke: I need to think about it further 6) BGP based auto-discovery [Sue Hares, P. Unbehagen] [10 minutes] document: draft-hlmu-l2vpn-bgp-discovery-00.txt authors: P. Unbehagen, P. Muley, V. Radoaca, Susan Hares Presentation Sue Hares, P. Unbehagen - Already a L2VPN draft that addresses this in a defined NLRI with label information - Paul: This draft is meant to provide LDP pseudowire config information - Other spec can do same thing [autodiscovery] without label information - Kireeti: Would like to be able to use this AFI with different SAFI [65] and NLRI format - Would the two SAFIs be solving similar problems - Kireeti: My SAFI solves different problems 7) BGP Assignment of AFI/SAFI address [10 minutes] Document: draft-hares-bgp-assign-afisafi-00.txt Author: Susan Hares Presentation Sue Hares 8) BGP Attribute Codes and Suggested Procedures Document: draft-kompella-zinin-early-allocation-00.txt Author: Alex Zinin, Kireeti Kompella Presentation Alex Zinin - Sharon: talking about protocols and not OIDs preallocation? bad to preallocate in the MIB... different from what other WGs; exclude MIB OIDs - Kireeti: not suggesting that everyone use this - It would have been nicer to have had OIDs preallocated so as not to reimpliment the MIB - Sharon: OIDs not allocated to drafts because if the drafts goes away then you've wasted numbers - Lou Berger: allocation with 1 year with 1 renewal is too short; alterntate policy: as long as draft or version is alive, expire in 3 to 6 months - Alex: that suggestion ties validity with ability of author to submit the draft; suggestion: once document is submitted to IESG then we freeze. Don't want to allocate codepoints too early. - Dave Meyer: Are you sure that IANA can time anything out - Alex: No - Dave Meyer: WG chair needs to manage this? - What happens if the allocation is not renewed and code is using it still? - Alex: Add provision to document to deprecate but not return - Kireeti: Deprecate for a period of time to give people time to remove. Formal process to do early allocations and if it goes through then stick with it but if it doesn't go through then people must take this out. - Dino: Allocate experimental codepoints and once standardised, then adopt standard codepoint for sending but accept both. - Sue: Good for SAFIs as well as AFIs? - Dino: All well known IANA values - Fenner: RFC already documents a process for transitioning codepoints 9) Charter Discussion [20 minutes] Thanks to all implementers who send in reports on the the base specification, we will be opening the charter. This section of the meeting will discuss what items will be added to the charter. Presentation - Top three most important; maybe ECMP little higher than Fault Isolation -- /*==================[ Jake Khuon ]=====================+ | Field App. Engineer http://www.nexthop.com/ /\ /~ E X T H O P | | Ofc: +1 (425) 391-2262 Fax: +1 (425) 391-6772 / \/ Technologies, Inc.| +==========[ 1911 Landings Drive, Mountain View, CA 94043 USA ]===========*/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 2 22:56:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27118 for ; Tue, 2 Mar 2004 22:56:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyNUL-0006dK-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 22:56:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyNTP-0006Uh-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 22:55:07 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyNSg-0006My-00; Tue, 02 Mar 2004 22:54:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyNSh-0001d2-1d; Tue, 02 Mar 2004 22:54:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNSL-0001z2-CL; Tue, 02 Mar 2004 22:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNRO-0001xi-11 for idr@optimus.ietf.org; Tue, 02 Mar 2004 22:53:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27038 for ; Tue, 2 Mar 2004 22:52:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyNRK-0006Cd-00 for idr@ietf.org; Tue, 02 Mar 2004 22:52:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyNQL-00063d-00 for idr@ietf.org; Tue, 02 Mar 2004 22:51:58 -0500 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx with esmtp (Exim 4.12) id 1AyNPQ-0005nH-00 for idr@ietf.org; Tue, 02 Mar 2004 22:51:00 -0500 Received: (qmail 6411 invoked by uid 211); 3 Mar 2004 03:50:44 -0000 Received: from 166-205-011-063.mobile.attwireless.net (HELO ?10.120.130.82?) (vgill@166.205.11.63) by challah.msrl.com with DES-CBC3-SHA encrypted SMTP; 3 Mar 2004 03:50:44 -0000 From: vijay gill To: Pedro Roque Marques cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) Message-ID: <2147483647.1078182303@[10.88.104.252]> In-Reply-To: <200403020041.i220fwFm050173@roque-bsd.juniper.net> References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> <200403020025.i220PI9P050138@roque-bsd.juniper.net> <20040302003314.GA6255@vijaygill.com> <200403020041.i220fwFm050173@roque-bsd.juniper.net> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 23:05:03 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit --On Monday, March 1, 2004 16:41 -0800 Pedro Roque Marques wrote: > vijay gill writes: > >> On Mon, Mar 01, 2004 at 04:25:18PM -0800, Pedro Roque Marques wrote: >>> Pekka Savola writes: >>> >>> i'll repeat it: - How can you prove that a given path that is >>> learned by BGP is loop free ? - That can only be done if >>> forwarding follows routing. > >> I feel that BGP should only be concerned about creating loop free >> topologies. If the user then has a mechanism where the forwarding >> does not follow the routing properly and causes a loop (this is an >> important distinction), then this is their problem. I can always >> point a static back up a link if I so want and nothing bgp can do >> about it. > > Your argument assumes that the user always knows that is configuring a > situation that may create forwarding loops... > > That may not be the case. It may come from a configuration > mistake... > > imho, the default approach for the protocol spec is to choose the most > graceful failure model possible torwards loop-free forwarding... Pedro, I still don't understand why BGP must care about statics or other protocols that may or may not be misconfigured. For some reason I may want to create a forwarding loop (for example, in my lab) to see what the router does. Actually, to be more specific, there are valid operational reasons for sometimes routing information away from where BGP points you, load balancing on congested peerings for example. Not very elegant, but these cases do exist. If a vendors BGP implementation does not allow me to have the final say as to where I want to place traffic, I _will_ be extremely irate. > >>> Proof: configure a static route for a given prefix in a border >>> router that points to a BGP neighbor that selects this router as >>> best path... watch permanent forwarding loops. > >> Yes, and this is a not a matter for BGP to worry about. > > I respectfully disagree. that is fine. but as we all know, the final arbiter of features is the account team, back up by P.O.s /vijay > > Pedro. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 2 22:56:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27141 for ; Tue, 2 Mar 2004 22:56:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyNUN-0006dU-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 22:56:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyNTQ-0006Uy-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 22:55:09 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyNSh-0006N0-00; Tue, 02 Mar 2004 22:54:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyNSh-0001d3-2I; Tue, 02 Mar 2004 22:54:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNSL-0001zB-Vq; Tue, 02 Mar 2004 22:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNRO-0001xp-KY for idr@optimus.ietf.org; Tue, 02 Mar 2004 22:53:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27041 for ; Tue, 2 Mar 2004 22:52:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyNRL-0006Ci-00 for idr@ietf.org; Tue, 02 Mar 2004 22:52:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyNQM-00063l-00 for idr@ietf.org; Tue, 02 Mar 2004 22:51:59 -0500 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx with esmtp (Exim 4.12) id 1AyNPQ-0005tB-00 for idr@ietf.org; Tue, 02 Mar 2004 22:51:00 -0500 Received: (qmail 6414 invoked by uid 211); 3 Mar 2004 03:50:54 -0000 Received: from 166-205-011-063.mobile.attwireless.net (HELO ?10.120.130.82?) (vgill@166.205.11.63) by challah.msrl.com with DES-CBC3-SHA encrypted SMTP; 3 Mar 2004 03:50:54 -0000 From: vijay gill To: Pedro Roque Marques cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) Message-ID: <2147483647.1078183926@[10.88.104.252]> In-Reply-To: <200403020041.i220fwFm050173@roque-bsd.juniper.net> References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> <200403020025.i220PI9P050138@roque-bsd.juniper.net> <20040302003314.GA6255@vijaygill.com> <200403020041.i220fwFm050173@roque-bsd.juniper.net> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 23:32:08 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit --On Monday, March 1, 2004 16:41 -0800 Pedro Roque Marques wrote: > vijay gill writes: > >> On Mon, Mar 01, 2004 at 04:25:18PM -0800, Pedro Roque Marques wrote: >>> Pekka Savola writes: >>> >>> i'll repeat it: - How can you prove that a given path that is >>> learned by BGP is loop free ? - That can only be done if >>> forwarding follows routing. > >> I feel that BGP should only be concerned about creating loop free >> topologies. If the user then has a mechanism where the forwarding >> does not follow the routing properly and causes a loop (this is an >> important distinction), then this is their problem. I can always >> point a static back up a link if I so want and nothing bgp can do >> about it. > > Your argument assumes that the user always knows that is configuring a > situation that may create forwarding loops... > > That may not be the case. It may come from a configuration > mistake... > > imho, the default approach for the protocol spec is to choose the most > graceful failure model possible torwards loop-free forwarding... >imho, the default approach for the protocol spec is to choose the most >graceful failure model possible torwards loop-free forwarding... Pedro, I still don't understand why BGP must care about statics or other protocols that may or may not be misconfigured. For some reason I may want to create a forwarding loop (for example, in my lab) to see what the router does. Actually, to be more specific, there are valid operational reasons for sometimes routing information away from where BGP points you, load balancing on congested peerings for example. Not very elegant, but these cases do exist. If a vendors BGP implementation does not allow me to have the final say as to where I want to place traffic, I _will_ be extremely irate. If you only consider BGP, then it should do loop-free routing, absolutely. I just do not want BGP to be looking into static configurations and trying to do my thinking for me. This leads to anger and anger leads to the dark side. etc etc. > >>> Proof: configure a static route for a given prefix in a border >>>router that points to a BGP neighbor that selects this router as >>>best path... watch permanent forwarding loops. > >>Yes, and this is a not a matter for BGP to worry about. > >I respectfully disagree. that is fine. but as we all know, the final arbiter of features is the account team, backed up by P.O.s no matter what the IETF would like to believe. /vijay > > Pedro. > >_______________________________________________ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 2 22:56:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27197 for ; Tue, 2 Mar 2004 22:56:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNUQ-0002XC-G9 for idr-archive@odin.ietf.org; Tue, 02 Mar 2004 22:56:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i233uA40009736 for idr-archive@odin.ietf.org; Tue, 2 Mar 2004 22:56:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNUQ-0002Wx-9c for idr-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 22:56:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27135 for ; Tue, 2 Mar 2004 22:56:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyNUM-0006dP-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 22:56:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyNTQ-0006Uq-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 22:55:08 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyNSg-0006My-00; Tue, 02 Mar 2004 22:54:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyNSh-0001d2-1d; Tue, 02 Mar 2004 22:54:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNSL-0001z2-CL; Tue, 02 Mar 2004 22:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNRO-0001xi-11 for idr@optimus.ietf.org; Tue, 02 Mar 2004 22:53:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27038 for ; Tue, 2 Mar 2004 22:52:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyNRK-0006Cd-00 for idr@ietf.org; Tue, 02 Mar 2004 22:52:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyNQL-00063d-00 for idr@ietf.org; Tue, 02 Mar 2004 22:51:58 -0500 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx with esmtp (Exim 4.12) id 1AyNPQ-0005nH-00 for idr@ietf.org; Tue, 02 Mar 2004 22:51:00 -0500 Received: (qmail 6411 invoked by uid 211); 3 Mar 2004 03:50:44 -0000 Received: from 166-205-011-063.mobile.attwireless.net (HELO ?10.120.130.82?) (vgill@166.205.11.63) by challah.msrl.com with DES-CBC3-SHA encrypted SMTP; 3 Mar 2004 03:50:44 -0000 From: vijay gill To: Pedro Roque Marques cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) Message-ID: <2147483647.1078182303@[10.88.104.252]> In-Reply-To: <200403020041.i220fwFm050173@roque-bsd.juniper.net> References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> <200403020025.i220PI9P050138@roque-bsd.juniper.net> <20040302003314.GA6255@vijaygill.com> <200403020041.i220fwFm050173@roque-bsd.juniper.net> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 23:05:03 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On Monday, March 1, 2004 16:41 -0800 Pedro Roque Marques wrote: > vijay gill writes: > >> On Mon, Mar 01, 2004 at 04:25:18PM -0800, Pedro Roque Marques wrote: >>> Pekka Savola writes: >>> >>> i'll repeat it: - How can you prove that a given path that is >>> learned by BGP is loop free ? - That can only be done if >>> forwarding follows routing. > >> I feel that BGP should only be concerned about creating loop free >> topologies. If the user then has a mechanism where the forwarding >> does not follow the routing properly and causes a loop (this is an >> important distinction), then this is their problem. I can always >> point a static back up a link if I so want and nothing bgp can do >> about it. > > Your argument assumes that the user always knows that is configuring a > situation that may create forwarding loops... > > That may not be the case. It may come from a configuration > mistake... > > imho, the default approach for the protocol spec is to choose the most > graceful failure model possible torwards loop-free forwarding... Pedro, I still don't understand why BGP must care about statics or other protocols that may or may not be misconfigured. For some reason I may want to create a forwarding loop (for example, in my lab) to see what the router does. Actually, to be more specific, there are valid operational reasons for sometimes routing information away from where BGP points you, load balancing on congested peerings for example. Not very elegant, but these cases do exist. If a vendors BGP implementation does not allow me to have the final say as to where I want to place traffic, I _will_ be extremely irate. > >>> Proof: configure a static route for a given prefix in a border >>> router that points to a BGP neighbor that selects this router as >>> best path... watch permanent forwarding loops. > >> Yes, and this is a not a matter for BGP to worry about. > > I respectfully disagree. that is fine. but as we all know, the final arbiter of features is the account team, back up by P.O.s /vijay > > Pedro. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 2 22:56:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27214 for ; Tue, 2 Mar 2004 22:56:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNUS-0002XU-JH for idr-archive@odin.ietf.org; Tue, 02 Mar 2004 22:56:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i233uCKU009754 for idr-archive@odin.ietf.org; Tue, 2 Mar 2004 22:56:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNUS-0002XF-Fs for idr-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 22:56:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27160 for ; Tue, 2 Mar 2004 22:56:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyNUP-0006di-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 22:56:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyNTR-0006V6-00 for idr-web-archive@ietf.org; Tue, 02 Mar 2004 22:55:10 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyNSh-0006N0-00; Tue, 02 Mar 2004 22:54:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyNSh-0001d3-2I; Tue, 02 Mar 2004 22:54:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNSL-0001zB-Vq; Tue, 02 Mar 2004 22:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNRO-0001xp-KY for idr@optimus.ietf.org; Tue, 02 Mar 2004 22:53:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27041 for ; Tue, 2 Mar 2004 22:52:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyNRL-0006Ci-00 for idr@ietf.org; Tue, 02 Mar 2004 22:52:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyNQM-00063l-00 for idr@ietf.org; Tue, 02 Mar 2004 22:51:59 -0500 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx with esmtp (Exim 4.12) id 1AyNPQ-0005tB-00 for idr@ietf.org; Tue, 02 Mar 2004 22:51:00 -0500 Received: (qmail 6414 invoked by uid 211); 3 Mar 2004 03:50:54 -0000 Received: from 166-205-011-063.mobile.attwireless.net (HELO ?10.120.130.82?) (vgill@166.205.11.63) by challah.msrl.com with DES-CBC3-SHA encrypted SMTP; 3 Mar 2004 03:50:54 -0000 From: vijay gill To: Pedro Roque Marques cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) Message-ID: <2147483647.1078183926@[10.88.104.252]> In-Reply-To: <200403020041.i220fwFm050173@roque-bsd.juniper.net> References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> <200403020025.i220PI9P050138@roque-bsd.juniper.net> <20040302003314.GA6255@vijaygill.com> <200403020041.i220fwFm050173@roque-bsd.juniper.net> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 23:32:08 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On Monday, March 1, 2004 16:41 -0800 Pedro Roque Marques wrote: > vijay gill writes: > >> On Mon, Mar 01, 2004 at 04:25:18PM -0800, Pedro Roque Marques wrote: >>> Pekka Savola writes: >>> >>> i'll repeat it: - How can you prove that a given path that is >>> learned by BGP is loop free ? - That can only be done if >>> forwarding follows routing. > >> I feel that BGP should only be concerned about creating loop free >> topologies. If the user then has a mechanism where the forwarding >> does not follow the routing properly and causes a loop (this is an >> important distinction), then this is their problem. I can always >> point a static back up a link if I so want and nothing bgp can do >> about it. > > Your argument assumes that the user always knows that is configuring a > situation that may create forwarding loops... > > That may not be the case. It may come from a configuration > mistake... > > imho, the default approach for the protocol spec is to choose the most > graceful failure model possible torwards loop-free forwarding... >imho, the default approach for the protocol spec is to choose the most >graceful failure model possible torwards loop-free forwarding... Pedro, I still don't understand why BGP must care about statics or other protocols that may or may not be misconfigured. For some reason I may want to create a forwarding loop (for example, in my lab) to see what the router does. Actually, to be more specific, there are valid operational reasons for sometimes routing information away from where BGP points you, load balancing on congested peerings for example. Not very elegant, but these cases do exist. If a vendors BGP implementation does not allow me to have the final say as to where I want to place traffic, I _will_ be extremely irate. If you only consider BGP, then it should do loop-free routing, absolutely. I just do not want BGP to be looking into static configurations and trying to do my thinking for me. This leads to anger and anger leads to the dark side. etc etc. > >>> Proof: configure a static route for a given prefix in a border >>>router that points to a BGP neighbor that selects this router as >>>best path... watch permanent forwarding loops. > >>Yes, and this is a not a matter for BGP to worry about. > >I respectfully disagree. that is fine. but as we all know, the final arbiter of features is the account team, backed up by P.O.s no matter what the IETF would like to believe. /vijay > > Pedro. > >_______________________________________________ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Mar 3 02:28:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02992 for ; Wed, 3 Mar 2004 02:28:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQnY-0000vL-00 for idr-archive@ietf.org; Wed, 03 Mar 2004 02:28:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQlp-0000cu-00 for idr-archive@ietf.org; Wed, 03 Mar 2004 02:26:24 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyQlT-0000UW-00; Wed, 03 Mar 2004 02:25:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyQiD-00050r-Tx; Wed, 03 Mar 2004 02:22:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQhf-0005rl-Gs; Wed, 03 Mar 2004 02:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQgt-0005iO-TU for idr@optimus.ietf.org; Wed, 03 Mar 2004 02:21:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26251 for ; Wed, 3 Mar 2004 02:21:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQgq-0007jb-00 for idr@ietf.org; Wed, 03 Mar 2004 02:21:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQfu-0007be-00 for idr@ietf.org; Wed, 03 Mar 2004 02:20:17 -0500 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 1AyQfC-0007MP-00 for idr@ietf.org; Wed, 03 Mar 2004 02:19:30 -0500 Received: from A1VVMQ21.wireless.ietf59.or.kr (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i237Is8d001414 for ; Wed, 3 Mar 2004 01:18:55 -0600 (CST) From: Andrew Lange To: idr@ietf.org Message-ID: <11588263.1078269532@A1VVMQ21.wireless.ietf59.or.kr> X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========F9F1C055D554AA970B14==========" Subject: [Idr] Charter Add - Flexible BGP Communities Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Mar 2004 23:18:52 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --==========F9F1C055D554AA970B14========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit Hello all, I'd like to add the attached BGP Flexible Communities draft as a wg draft (it should show up in the drafts repository after the meeting). I presented on this at both Yokohama and San Francisco. The feedback was generally that this was an idea that should be adopted by the wg and considered further. Thanks, Andrew --==========F9F1C055D554AA970B14========== Content-Type: text/plain; charset=us-ascii; name="draft-lange-flexible-bgp-communities-02.txt" Content-Disposition: attachment; filename="draft-lange-flexible-bgp-communities-02.txt"; size=36430 Content-Transfer-Encoding: 7bit Internet Engineering Task Force A. Lange INTERNET DRAFT Alcatel March 2004 Expires September 2004 Flexible BGP Communities Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines a new attribute for BGP called the Flexible Community attribute. Flexible Communities build on the experience and utility of the standard BGP community, and the extended BGP community attributes. This attribute allows operators to associate structured information with a route or set of routes. This information can be then be used to execute routing policy. An enhanced version of communities is necessary to accommodate IPv6, 4-byte ASN's, and introduce a more extensible and flexible policy expression. This document also introduces the concept of Neighbor Classes. A Neighbor Class is applied to a group of BGP neighbors who share certain attributes. For example, the PEER Neighbor Class could be applied to BGP sessions between ASN X and other networks with which ASN X has a non-transit peering relationship. Lange [Page 1] INTERNET DRAFT December 2002 Table of Contents Status of this Memo......................................... 1 Abstract.................................................... 1 1. Introduction............................................ 2 2. The BGP Flexible Community Attribute.................... 3 2.1 Transitivity Field..................................... 4 2.2 Structure Field........................................ 4 2.3 Type Field............................................. 5 2.4 Originating ASN Field.................................. 5 2.5 Length Field........................................... 6 3. Locally Defined Structures and Types.................... 6 4. Neighbor Classes........................................ 6 4.1 Locally Defined Neighbor Classes....................... 7 4.2 Defined Neighbor Classes............................... 8 5. Defined Flexible BGP Community Structures............... 9 6. Base BGP Flexible Community Type (Opaque Type).......... 10 7. Defined Flexible BGP Community Types.................... 10 7.1 NO_EXPORT.............................................. 10 7.2 ONLY_EXPORT............................................ 11 7.3 ANNOUNCE_WITH.......................................... 12 7.4 PREPEND................................................ 13 7.5 The BGP VPN Communities................................ 13 8. New Capability Code for Flexible Communities............ 14 9. Aggregation............................................. 14 10. Operations.............................................. 15 11. Security Considerations................................. 15 12. IANA Considerations..................................... 16 13. References.............................................. 16 14. Acknowledgements........................................ 17 15. Author's Address........................................ 17 Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1. Introduction This attribute represents the third generation of the BGP community attribute. The first generation is documented in RFC1997 [RFC1997]. The second generation, the extended community, is documented in EX- COMM [EX-COMM]. The Flexible Community Attribute provides a number of important enhancements over the existing BGP Community Attribute and BGP Extended Community Attribute. These enhancements are: Lange [Page 2] INTERNET DRAFT December 2002 - Support for IPv6. - More efficient encoding of lists of data, for example, a list of ASN's. - Clean support for a broad range of future data field structures and interpretations. - Support for locally defined community structures, and interpretations. - Easy extensibility for a range of future applications. The continuation and expansion of the structure introduced with Extended Communities allows for policy based on the application where the community is being used. The separation of structure and interpretation allows for easier machine and human parsing of community types which do the same thing with slightly different input. This attribute continues the use of the Transitivity community bit, first introduced in the Extended Community Attribute. We also define a set of well-known values for this attribute which can be used to replicate and extend the functionality of the existing well-known community values. The concept of Neighbor Classes is introduced. A Neighbor Class is defined on a BGP peering session. It allows neighbors that share a set of administrative attributes to be easily grouped together. Policy can then be defined through Flexible Communities in reference to these groupings. 2. The BGP Flexible Community Attribute The Flexible Community Attribute is a transitive optional BGP attribute with a Type Code of . The attribute consists of a list of "flexible communities." Each Flexible Community is encoded as a variable length quantity. The encoding scheme is: - Transitivity Field: 1 bit - Structure Field: 7 bits - Type Field: 2 octets - Length Field: 1 octet - Value Field: 0-255 octets 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T| Struct. | Type | Originating | Lange [Page 3] INTERNET DRAFT December 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASN | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value Field (0-255 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.1. Transitivity Field: The Transitivity Field is one bit. It can take the following values: Value 0: The community is transitive across ASes Value 1: The community is non-transitive across ASes It is important to note that the transitivity defined by this field is different from the general transitivity of a BGP attribute. A single Flexible Community Attribute, can contain multiple Flexible Communities, each of which may or may not be transitive. If a route originates in an AS with the transitivity bit set, indicating that the community is non-transitive, then that AS MUST NOT propagate that community to its peers. However, if a community with the transitive bit set is applied on an outbound policy expression (e.g., a route- map), the community will be conveyed to the immediately adjacent peer. That peer, in turn, will NOT propagate the community to its peers. The one exception to this is as-confederations. For the purposes of this attribute, confederation boundaries should be treated the same as IBGP. In other words, non-transitive flexible communities should be propagated to other members of the as- confederation, unless overridden by local policy. If the community is transitive, then the Value Field MUST contain the originating ASN. This ASN is encoded as a 4-octet value, occupying the first 4 octets of the Value Field. Two-octet ASN numbers are padded out to 4 octets. Any additional information in the Value Field comes after this origin ASN data. 2.2. Structure Field: The Structure Field's contents modify the Type Field. For example, a Flexible Community which specifies SPECIFIC_NO_EXPORT in its Type Field, can be modified by the contents of the Structure Field to let the receiver know if the list of data on which it must act is a list of 2 octet or 4 octet ASNs. A set of commonly used Structure values is defined later in this document. The Structure field is the latter 7 bits of the first octet. It is split into two sub-fields. Lange [Page 4] INTERNET DRAFT December 2002 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |T|L| Struct. | +-+-+-+-+-+-+-+-+ L - Local bit The Local bit can take two values: Value 0: The Structure is Locally Defined. Value 1: The Structure is Well Known. 2.3. Type Field: The Type Field is two octets. This contents of this field are used to define an action for the recipient to take on the route, or to define and attribute that is related to that route. An example of the former would be a Type which requests that a route be ONLY_EXPORTed to a specific set of peers. An example of the latter would be a Type that defines the LINK_BANDWIDTH associated with a certain NLRI. Like the Structure Field the Type Field is split into two Sub-Fields: 1 2 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Local bit can take two values: Value 0: The Type is Locally Defined. Value 1: The Type is Well Known. An implementation MUST allow an operator to filter out entire Types of Flexible Communities from their peering sessions if they so choose. 2.4 Originating ASN Field: This field contains the ASN that added the flexible community to the route. It is 4 octets long. In the case of a 2-byte ASN, the first 2 octets are set to zero, as padding. Lange [Page 5] INTERNET DRAFT December 2002 2.5. Length Field: The Length Field specifies the length, in octets, of the Value Field. 3. Locally Defined Structures and Types The Local bit allows the operator of the network to define Structures and Types that are relevant only within that ASN's boundaries. The definition the term "local" used throughout this document is: "A value used by ad hoc agreement or convention outside the scope of standardization, which has meaning only between the parties using the Flexible Community in question." This typically means that the Local value only has meaning within an AS or set of ASes controlled by a single entity. A Locally Defined Structure or Type will have a syntax for interpretation defined on the routers that need to interpret it. If a router receives a community with a Locally Defined Structure or Type that it does not recognize, then it should ignore the contents and process the route based on the information in the route that it does understand. This includes obeying the transitivity bit, in the Flexible Community. If the community is set to non-transitive, even if the router does not understand the rest of the Structure or Type of the community, that community should not be forwarded outside the AS. In order to prevent collisions with other operators' Locally Defined values, Flexible Communities containing Locally Defined Structures or Types MUST be non-transitive (have their Transitivity Field set to 1). 4. Neighbor Classes A Neighbor Class is a value which represents a certain class, or group, of BGP neighbors. Each BGP peering session can be configured with zero or more Neighbor Classes. This value will allow a general classification of what sort of relationship the BGP session represents. With the sort of session defined, it becomes easier to apply policy to only that class of neighbors. Neighbor Classes make the expression of policy through flexible communities much easier. There are a number of examples in the sections on defined values. Neighbor Classes can be used in two main ways. First they can be used in a passive manner, where the configuration acts as a policy expression for communities matching it. An example of this would be configuring a neighbor with the PEER neighbor class, and having a community that, say is set to NO_EXPORT for the NEIGHBOR CLASS PEER. In this configuration, all the neighbors that are configured as PEERs Lange [Page 6] INTERNET DRAFT December 2002 would match and filter out the route carrying the NO_EXPORT, NEIGHBOR CLASS PEER community. This is the standard way of using neighbor classes. A second, optional, way to use Neighbor Classes would be to allow inbound community tagging. In this usage, routes traversing the session would be automatically tagged with a flexible community with the appropriate neighbor class value. This eases configuration. To extend the example above, our neighbor designated PEER would add a community with NEIGHBOR CLASS PEER to routes traversing the BGP session. This community could then be used further down the line to just announce PEER routes to a particular customer. This usage is configurable on a per-neighbor basis. A Neighbor Class is encoded as a 2-octet value with 2 parts: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Neighbor Class | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Local bit can take two values: Value 0: The Neighbor Class is Locally Defined. Value 1: The Neighbor Class is Well Known. 4.1. Locally Defined Neighbor Classes If a router receives a Flexible Community containing a Neighbor Class that it does not recognize, then it should ignore the contents and process the route based on the information in the route that it does understand. If the Transitivity Field of the Flexible Community with the Locally Defined Structure or Type is set to 1 (the community is non-transitive) then the router MUST NOT forward the Flexible Community. Similarly, if the Transitivity Field is set to 0 (the community is transitive) the router MUST forward the community along with the NLRI. Using Locally Defined Neighbor Classes an operator could easily define a set that is locally useful. This set could be used in a flat name space, for example, one could say that "31" would be "Asian Public Peers", and "34" would be European Private Peers. Also, a given BGP Neighbor can be part of multiple Neighbor Classes. This would allow for a hierarchical or additive name space. For example, a neighbor could be part of both "PEER", and locally defined Lange [Page 7] INTERNET DRAFT December 2002 "ASIAN" and "PUBLIC PEER" Classes. The logical matching functionality available is left implementation-dependent. However, the default in such as case is logical OR functionality for matching this neighbor class. In the case where routes are being tagged inbound, then by default a single community with all configured neighbor classes in a list is added. Implementation dependent knobs are suggested to allow more fine grained control. 4.2. Defined Neighbor Classes This document defines Neighbor Class values for common BGP neighbor groupings: ALL NEIGHBORS This class is the default Neighbor Class for all BGP peers. This class is represented by a value of 0 (0x8000). PEER This class is typically applied to sessions where a transit-free relationship exists between the two providers. This class is represented by a value of 1 (0x8001). CUSTOMER This class is typically applied to sessions where the remote end of the session is operated by a customer. This class is represented by a value of 2 (0x8002). UPSTREAM This class is typically applied to sessions where the remote end of the session is operated by a network from which you receive transit routes. This class is represented by a value of 3 (0x8003). CONFEDERATION PEER This class is typically applied to sessions where the remote end of the session is part of a confederation. This class is represented by a value of 4 (0x8004). Lange [Page 8] INTERNET DRAFT December 2002 5. Defined Flexible BGP Community Structures This section defines a number of Structure values which different Type values can inherit. Summary of the Defined Values: - opaque/variable (0x40 or 0xC0) - list of ASN's (0x41 or 0xC1) - list of IPv4 addresses (0x42 or 0xC2) - list of IPv6 addresses (0x43 or OxC3) - list of neighbor_classes (0x44 or 0xC4) Defined Structure can be transitive or non-transitive, they are well known. Opaque/Variable Structure This sort of structure defers interpretation of the community and value field to the Type value. Typically this structure value will be used when the Type value does not have a lot of variations, but rather one structure for the Value Field. This structure is represented by the value 0x00. List of ASN's This structure value means that the Type Field's action is qualified by a list of ASN's, contained in the Value Field. In the case of 2 byte ASN's the value is padded to 4 bytes by inserting 2 octets worth of zeros in the leftmost portion of the value. This structure is represented by the value 0x01. List of IPv4 Addresses This structure value means that the Type Field's action is qualified by a list of IPv4 addresses, contained in the Value Field. This structure is represented by the value 0x02. List of IPv6 Addresses This structure value means that the Type Field's action is qualified by a list of IPv6 addresses, contained in the Value Field. Lange [Page 9] INTERNET DRAFT December 2002 This structure is represented by the value 0x03. List of Neighbor Classes This structure value means that the Type Field's action is qualified by a list of neighbor classes, contained in the Value Field. This structure is represented by the value 0x04. 6. Base BGP Flexible Community Type (Opaque Type) This section defines the base BGP community specification. Since the root value of communities is the ability to tag a route with arbitrary information, and then create a system to give that information meaning, the base flexible community type (type 0), is very simple. This base type could also be described as the "opaque type." All actions can be replicated with a well-thought out, provider dependent, implementation of a scheme using this opaque type. Like all flexible communities, this type can be transitive or non- transitive. This is a well known type. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00,0xC0 | 0x0000 | Originating | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASN | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value Field (0-255 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7. Defined Flexible BGP Community Types The Type Field specifies the subgroup that a set of communities belongs to. Typically this subgroup represents an action to be taken on the data. A variety of well-known Type Values follow. 7.1. NO_EXPORT This grouping of well-known communities specify a list of ASNs, Peer IPs, or Neighbor Classes NOT to announce a route to. Name: NO_EXPORT Type Code: 0x0001 Lange [Page 10] INTERNET DRAFT December 2002 Can Take Structures: Ox01 (ASN), 0x02 (IPv4), 0x03 (IPv6), 0x04 (neighbor-class) Transitive: Non-Transitive Min Length of Value Field: 2 octets Max Length of Value Field: 254 octets Behavior: All routes received with this community MUST NOT be advertised to the list of ASNs, Peer IPs, or Neighbor Classes contained in the Value Field. Notes: GLOBAL_NO_EXPORT is accomplished by sending a NO_EXPORT Flexible Community with the Neighbor Class of 0x00 (ALL NEIGHBORS). GLOBAL_NO_EXPORT's NO_EXPORT behavior is defined as: All routes received with this community 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.) [RFC1997] This is analogous to the NO_EXPORT community defined in [RFC1997]. 7.2. ONLY_EXPORT This grouping of well-known communities specify a list of ASNs, Peer IPs, or Neighbor Classes to announce a route to. Name: ONLY_EXPORT Type Code: 0x0002 Can Take Structures: Ox01 (ASN), 0x02 (IPv4), 0x03 (IPv6), 0x04 (neighbor-class) Transitive: Non-Transitive Min Length of Value Field: 0 octets Max Length of Value Field: 254 octets Behavior: The Value Field contains a list of ASNs, neighbor IP addresses, or Neighbor Classes to which the route should be advertised. The default behavior of a route carrying this community is the same as the GLOBAL_NO_EXPORT behavior, except for the ASNs, IPs, or Neighbor Classes listed in the Value Field. Notes: This community can be used to replicate the NO_ADVERTISE functionality from [RFC1997]. To do so, simply announce ONLY_EXPORT with a Structure of 0x03 or 0x04 (one of the IP address Structures), but with no IP address in the list. This will tell the receiving router that you wish to ONLY_EXPORT this route to NO peer IPs. Lange [Page 11] INTERNET DRAFT December 2002 This community can also be use to replicate the NO_EXPORT_SUBCONFED functionality from [RFC1997]. To do so, simply announce ONLY_EXPORT with a Neighbor Class of CONFEDERATION PEER (4, 0x8004). This will tell the receiving router that you wish to ONLY_EXPORT this route to Confederation Peers. 7.3. ANNOUNCE_WITH This group of well-known communities allows a network to announce a community to an ASN beyond those that it directly peers with, assuming its direct peers allow it to transit the community value. This community group has a lot of flexibility, and could be used to nest another ANNOUNCE_WITH community to gain reach greater than 2 ASN-hops away. If this is a good idea or not is unknown and is left to further study. The only theoretical restriction to the amount of nesting is that the community cannot exceed the maximum size for the Value Field. Since true transitivity can be obtained by simply setting a bit, this community is mainly useful for propagating NO_EXPORT or ONLY_EXPORT (which are non-transitive) to your neighbor's neighbors. In effect, this community, if allowed by the BGP neighbors in the chain, can be used for an originating network to very specifically control the distribution of its routes. This community type does contain a LOT of rope, and should be used with care. In the end, though, a mistake should only effect the person originating the route. Name: ANNOUNCE_WITH Type Code: 0x0003 Can Take Structures: Ox01 (ASN), 0x02 (IPv4), 0x03 (IPv6), 0x04 (neighbor-class) Transitive: Non-Transitive Min Length of Value Field: 8 octets Max Length of Value Field: 254 octets Behavior: This community's Value Field is split into two sections. - The first section is a variable length field that contains the full community value that you wish to announce. - The second section is a variable length field that contains the list of, ASN's, IP addresses, or neighbor_classes you wish to propagate this community to. If you wish to propagate to all peers, use the ALL NEIGHBORS neighbor class. When a router receives this community value, it should strip the ANNOUNCE_WITH community and announce the underlying community value to its neighbor. Lange [Page 12] INTERNET DRAFT December 2002 7.4. PREPEND This community can be used to ask a BGP peer to prepend its own ASN to its peers. Name: PREPEND Type Code: 0x0004 Can Take Structures: Ox01 (ASN), 0x02 (IPv4), 0x03 (IPv6), 0x04 (neighbor-class) Transitive: Non-Transitive Min Length of Value Field: 3 octets Max Length of Value Field: 254 octets Behavior: This community has 2 sections: The first section: Is a one-octet value which specifies the number of times that the ASN should prepend its ASN. It is recommended that operators constrain this value to no more than 3. Implementations MUST offer the ability for an operator to set a maximum bound for this field. The suggested default is also 3. The second section: Contains a list of ASNs, peer IPs, or Neighbor Classes to which the originator of this community wishes its peer to prepend its ASN. 7.5. The BGP VPN Communities These communities are used mostly for BGP MPLS VPN's. Please see RFC2547 [RFC2547] for more detail on how these VPNs are constructed. Name: ROUTE_TARGET Type Code: 0x0005 Can Take Structures: 0x02 (IPv4), 0x03 (IPv6) Transitive: Transitive or Non-Transitive Min Length of Value Field: 4 octets Max Length of Value Field: 254 octets Behavior: The Value Field of this community represents a list of the IP addresses where this route is to be announced. Name: ROUTE_ORIGIN Type Code: 0x0006 Can Take Structures: 0x02 (IPv4), 0x03 (IPv6) Transitive: Transitive or Non-Transitive Min Length of Value Field: 4 octets Max Length of Value Field: 16 octets Lange [Page 13] INTERNET DRAFT December 2002 Behavior: The Value Field of this community represents a list of the IP address where this route is originated. This community can only contain one IP address. Name: LINK_BANDWIDTH Type Code: 0x0007 Can Take Structures: 0x00 (opaque), Ox01 (ASN) Transitive: Transitive or Non-Transitive Min Length of Value Field: 4 octets Max Length of Value Field: 6 octets Behavior: This community consists of two parts: The first part represents the bandwidth of the link in bits-per- second, encoded in IEEE floating point format. This part is 4 octets long. The second part consists of a list of ASNs of the peer whose link bandwidth you wish to propagate. 8. New Capability Code for Flexible Communities To ensure compatibility between implementations that may or may not implement this protocol extension, this document defines a new capability. Capability Code: TBD Capability Length: 1 Capability Value: 0x00 for unsupported 0x01 for supported Capability negotiation is especially important for this attribute because we are creating a transitivity action within an optional, transitive attribute. If an implementation sends a flexible community with the non-transitive bit set within the community to a router that does not support flexible communities, that router will send the community on to its peers when it should not do so. 9. Aggregation Aggregation behaves the same as with other community types. By default if a range of routes is to be aggregated and the resultant aggregates path attributes do not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate should have an Flexible Communities path attribute which contains the set union of all the Flexible Communities from all of the aggregated routes. The default Lange [Page 14] INTERNET DRAFT December 2002 behavior could be overridden via local configuration, in which case handling the Flexible Communities attribute in the presence of route aggregation becomes a matter of the local policy of the BGP speaker that performs the aggregation. 10. Operations Flexible Communities are handled operationally in a manner very similar to other community values. A BGP speaker may use the Flexible Communities attribute to control which routing information it accepts or distributes to its peers. The Flexible Community attribute MUST NOT be used to modify the BGP best path selection algorithm in a way that leads to forwarding loops. A BGP speaker receiving a route that doesn't have the Flexible Commu- nities attribute MAY append this attribute to the route when propagating it to its peers. A BGP speaker receiving a route with the Flexible Communities attribute MAY modify this attribute according to the local policy. If a route has a non-transitivity flexible community, then before advertising the route across the Autonomous system boundary the community SHOULD be removed from the route. However, the community SHOULD NOT be removed when advertising the route across the BGP Confederation boundary. A route may carry the BGP Communities attribute as defined in [RFC1997]), the Extended BGP Communities attribute as defined in [EX- COMM], and the Flexible Communities attribute. In this case the BGP Communities attribute is handled as specified in [RFC1997], the Extended BGP Communities attribute is handled as specified in [EX- COMM], and the Flexible Communities attribute is handled as specified in this document. If older community types are present in addition to the flexible community there is the possibility that the information contained may be redundant. Although effort should be made to avoid this situation, if it does occur the BGP Speaker shall prefer the flexible community first, then the extended community second and then the base community. 11. Security Considerations This extension to BGP does not change the underlying security issues. Lange [Page 15] INTERNET DRAFT December 2002 12. IANA Considerations The values for the Transitivity Field (1 or 0) are completely defined in this document. The assignment policy for the Structure Field is: o The "L" bit's usage is completely defined in this document. o Values of the Structure Field where the "L" bit is "0" are to be assigned in accordance with the Private Use policy outlined in RFC2434 [RFC2434]. o Values of the Structure Field where the "L" bit is "1" defined in this document are: 0-4 (0x40-0x44 and 0xC1-0xC4). Remaining values in this range are to be assigned using the IETF Consensus policy outlined in RFC2434 [RFC2434]. The assignment policy for the Type Field is: o The "L" bit's usage is completely defined in this document. o Values of the Type Field where the "L" bit is "0" are to be assigned in accordance with the Private Use policy outlined in RFC2434 [RFC2434]. o Values of the Type Field where the "L" but is "1" defined in this document are: 0-7 (0x0000-0x0007). Remaining values in this range are to be assigned using the IETF Consensus policy outlined in RFC2434 [RFC2434]. The assignment policy for Neighbor Classes is: o The "L" bit's usage is completely defined in this document. o Values of the Type Field where the "L" bit is "0" are to be assigned in accordance with the Private Use policy outlined in RFC2434 [RFC2434]. o Values of the Type Field where the "L" but is "1" defined in this document are: 0-4 (0x8000-0x8004). Remaining values in this range are to be assigned using the IETF Consensus policy outlined in RFC2434 [RFC2434]. 13. References [RFC1771] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC1997] Chandra, R., Traina, P., Li, T., "BGP Communities Attribute", RFC 1997, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998 Lange [Page 16] INTERNET DRAFT December 2002 [RFC2547] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March 1999. [RFC2842] Chandra, R., Scudder, J., "Capabilities Advertisement with BGP-4", RFC 2842, May 2000. [EX-COMM] Sangli, S., Tappan, D., Rekhter, Y., "BGP Extended Communities Attribute", draft-ietf-idr-bgp-ext-communities-05.txt, work-in-progress, expires November, 2002. [NOPEER] Huston, G., "NOPEER community for BGP route scope control", draft-ietf-ptomaine-nopeer-00.txt, work-in-progress, expires October, 2002. [REDIST] Bonaventure, O., et. al., "Controlling the redistribution of BGP routes", draft-ietf-ptomaine-redistribution-01.txt, work-in- progress, expires February, 2003. 14. Acknowledgements I would like to thank Tom Barron, Dave Ward and especially Hal Peterson for their valuable comments and feedback. 15. Author's Address: Andrew Lange Alcatel 274 Ferguson Drive Mountain View, CA 94043 andrew.lange@alcatel.com Lange [Page 17] --==========F9F1C055D554AA970B14==========-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Mar 3 02:28:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03646 for ; Wed, 3 Mar 2004 02:28:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQnq-0007ZQ-BK for idr-archive@odin.ietf.org; Wed, 03 Mar 2004 02:28:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i237SQf6029083 for idr-archive@odin.ietf.org; Wed, 3 Mar 2004 02:28:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQno-0007Yn-3d for idr-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 02:28:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03108 for ; Wed, 3 Mar 2004 02:28:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQnk-0000ys-00 for idr-web-archive@ietf.org; Wed, 03 Mar 2004 02:28:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQls-0000d1-00 for idr-web-archive@ietf.org; Wed, 03 Mar 2004 02:26:27 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyQlT-0000UW-00; Wed, 03 Mar 2004 02:25:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyQiD-00050r-Tx; Wed, 03 Mar 2004 02:22:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQhf-0005rl-Gs; Wed, 03 Mar 2004 02:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQgt-0005iO-TU for idr@optimus.ietf.org; Wed, 03 Mar 2004 02:21:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26251 for ; Wed, 3 Mar 2004 02:21:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQgq-0007jb-00 for idr@ietf.org; Wed, 03 Mar 2004 02:21:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQfu-0007be-00 for idr@ietf.org; Wed, 03 Mar 2004 02:20:17 -0500 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 1AyQfC-0007MP-00 for idr@ietf.org; Wed, 03 Mar 2004 02:19:30 -0500 Received: from A1VVMQ21.wireless.ietf59.or.kr (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i237Is8d001414 for ; Wed, 3 Mar 2004 01:18:55 -0600 (CST) From: Andrew Lange To: idr@ietf.org Message-ID: <11588263.1078269532@A1VVMQ21.wireless.ietf59.or.kr> X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========F9F1C055D554AA970B14==========" Subject: [Idr] Charter Add - Flexible BGP Communities Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Mar 2004 23:18:52 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --==========F9F1C055D554AA970B14========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit Hello all, I'd like to add the attached BGP Flexible Communities draft as a wg draft (it should show up in the drafts repository after the meeting). I presented on this at both Yokohama and San Francisco. The feedback was generally that this was an idea that should be adopted by the wg and considered further. Thanks, Andrew --==========F9F1C055D554AA970B14========== Content-Type: text/plain; charset=us-ascii; name="draft-lange-flexible-bgp-communities-02.txt" Content-Disposition: attachment; filename="draft-lange-flexible-bgp-communities-02.txt"; size=36430 Content-Transfer-Encoding: 7bit Internet Engineering Task Force A. Lange INTERNET DRAFT Alcatel March 2004 Expires September 2004 Flexible BGP Communities Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines a new attribute for BGP called the Flexible Community attribute. Flexible Communities build on the experience and utility of the standard BGP community, and the extended BGP community attributes. This attribute allows operators to associate structured information with a route or set of routes. This information can be then be used to execute routing policy. An enhanced version of communities is necessary to accommodate IPv6, 4-byte ASN's, and introduce a more extensible and flexible policy expression. This document also introduces the concept of Neighbor Classes. A Neighbor Class is applied to a group of BGP neighbors who share certain attributes. For example, the PEER Neighbor Class could be applied to BGP sessions between ASN X and other networks with which ASN X has a non-transit peering relationship. Lange [Page 1] INTERNET DRAFT December 2002 Table of Contents Status of this Memo......................................... 1 Abstract.................................................... 1 1. Introduction............................................ 2 2. The BGP Flexible Community Attribute.................... 3 2.1 Transitivity Field..................................... 4 2.2 Structure Field........................................ 4 2.3 Type Field............................................. 5 2.4 Originating ASN Field.................................. 5 2.5 Length Field........................................... 6 3. Locally Defined Structures and Types.................... 6 4. Neighbor Classes........................................ 6 4.1 Locally Defined Neighbor Classes....................... 7 4.2 Defined Neighbor Classes............................... 8 5. Defined Flexible BGP Community Structures............... 9 6. Base BGP Flexible Community Type (Opaque Type).......... 10 7. Defined Flexible BGP Community Types.................... 10 7.1 NO_EXPORT.............................................. 10 7.2 ONLY_EXPORT............................................ 11 7.3 ANNOUNCE_WITH.......................................... 12 7.4 PREPEND................................................ 13 7.5 The BGP VPN Communities................................ 13 8. New Capability Code for Flexible Communities............ 14 9. Aggregation............................................. 14 10. Operations.............................................. 15 11. Security Considerations................................. 15 12. IANA Considerations..................................... 16 13. References.............................................. 16 14. Acknowledgements........................................ 17 15. Author's Address........................................ 17 Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1. Introduction This attribute represents the third generation of the BGP community attribute. The first generation is documented in RFC1997 [RFC1997]. The second generation, the extended community, is documented in EX- COMM [EX-COMM]. The Flexible Community Attribute provides a number of important enhancements over the existing BGP Community Attribute and BGP Extended Community Attribute. These enhancements are: Lange [Page 2] INTERNET DRAFT December 2002 - Support for IPv6. - More efficient encoding of lists of data, for example, a list of ASN's. - Clean support for a broad range of future data field structures and interpretations. - Support for locally defined community structures, and interpretations. - Easy extensibility for a range of future applications. The continuation and expansion of the structure introduced with Extended Communities allows for policy based on the application where the community is being used. The separation of structure and interpretation allows for easier machine and human parsing of community types which do the same thing with slightly different input. This attribute continues the use of the Transitivity community bit, first introduced in the Extended Community Attribute. We also define a set of well-known values for this attribute which can be used to replicate and extend the functionality of the existing well-known community values. The concept of Neighbor Classes is introduced. A Neighbor Class is defined on a BGP peering session. It allows neighbors that share a set of administrative attributes to be easily grouped together. Policy can then be defined through Flexible Communities in reference to these groupings. 2. The BGP Flexible Community Attribute The Flexible Community Attribute is a transitive optional BGP attribute with a Type Code of . The attribute consists of a list of "flexible communities." Each Flexible Community is encoded as a variable length quantity. The encoding scheme is: - Transitivity Field: 1 bit - Structure Field: 7 bits - Type Field: 2 octets - Length Field: 1 octet - Value Field: 0-255 octets 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T| Struct. | Type | Originating | Lange [Page 3] INTERNET DRAFT December 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASN | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value Field (0-255 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.1. Transitivity Field: The Transitivity Field is one bit. It can take the following values: Value 0: The community is transitive across ASes Value 1: The community is non-transitive across ASes It is important to note that the transitivity defined by this field is different from the general transitivity of a BGP attribute. A single Flexible Community Attribute, can contain multiple Flexible Communities, each of which may or may not be transitive. If a route originates in an AS with the transitivity bit set, indicating that the community is non-transitive, then that AS MUST NOT propagate that community to its peers. However, if a community with the transitive bit set is applied on an outbound policy expression (e.g., a route- map), the community will be conveyed to the immediately adjacent peer. That peer, in turn, will NOT propagate the community to its peers. The one exception to this is as-confederations. For the purposes of this attribute, confederation boundaries should be treated the same as IBGP. In other words, non-transitive flexible communities should be propagated to other members of the as- confederation, unless overridden by local policy. If the community is transitive, then the Value Field MUST contain the originating ASN. This ASN is encoded as a 4-octet value, occupying the first 4 octets of the Value Field. Two-octet ASN numbers are padded out to 4 octets. Any additional information in the Value Field comes after this origin ASN data. 2.2. Structure Field: The Structure Field's contents modify the Type Field. For example, a Flexible Community which specifies SPECIFIC_NO_EXPORT in its Type Field, can be modified by the contents of the Structure Field to let the receiver know if the list of data on which it must act is a list of 2 octet or 4 octet ASNs. A set of commonly used Structure values is defined later in this document. The Structure field is the latter 7 bits of the first octet. It is split into two sub-fields. Lange [Page 4] INTERNET DRAFT December 2002 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |T|L| Struct. | +-+-+-+-+-+-+-+-+ L - Local bit The Local bit can take two values: Value 0: The Structure is Locally Defined. Value 1: The Structure is Well Known. 2.3. Type Field: The Type Field is two octets. This contents of this field are used to define an action for the recipient to take on the route, or to define and attribute that is related to that route. An example of the former would be a Type which requests that a route be ONLY_EXPORTed to a specific set of peers. An example of the latter would be a Type that defines the LINK_BANDWIDTH associated with a certain NLRI. Like the Structure Field the Type Field is split into two Sub-Fields: 1 2 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Local bit can take two values: Value 0: The Type is Locally Defined. Value 1: The Type is Well Known. An implementation MUST allow an operator to filter out entire Types of Flexible Communities from their peering sessions if they so choose. 2.4 Originating ASN Field: This field contains the ASN that added the flexible community to the route. It is 4 octets long. In the case of a 2-byte ASN, the first 2 octets are set to zero, as padding. Lange [Page 5] INTERNET DRAFT December 2002 2.5. Length Field: The Length Field specifies the length, in octets, of the Value Field. 3. Locally Defined Structures and Types The Local bit allows the operator of the network to define Structures and Types that are relevant only within that ASN's boundaries. The definition the term "local" used throughout this document is: "A value used by ad hoc agreement or convention outside the scope of standardization, which has meaning only between the parties using the Flexible Community in question." This typically means that the Local value only has meaning within an AS or set of ASes controlled by a single entity. A Locally Defined Structure or Type will have a syntax for interpretation defined on the routers that need to interpret it. If a router receives a community with a Locally Defined Structure or Type that it does not recognize, then it should ignore the contents and process the route based on the information in the route that it does understand. This includes obeying the transitivity bit, in the Flexible Community. If the community is set to non-transitive, even if the router does not understand the rest of the Structure or Type of the community, that community should not be forwarded outside the AS. In order to prevent collisions with other operators' Locally Defined values, Flexible Communities containing Locally Defined Structures or Types MUST be non-transitive (have their Transitivity Field set to 1). 4. Neighbor Classes A Neighbor Class is a value which represents a certain class, or group, of BGP neighbors. Each BGP peering session can be configured with zero or more Neighbor Classes. This value will allow a general classification of what sort of relationship the BGP session represents. With the sort of session defined, it becomes easier to apply policy to only that class of neighbors. Neighbor Classes make the expression of policy through flexible communities much easier. There are a number of examples in the sections on defined values. Neighbor Classes can be used in two main ways. First they can be used in a passive manner, where the configuration acts as a policy expression for communities matching it. An example of this would be configuring a neighbor with the PEER neighbor class, and having a community that, say is set to NO_EXPORT for the NEIGHBOR CLASS PEER. In this configuration, all the neighbors that are configured as PEERs Lange [Page 6] INTERNET DRAFT December 2002 would match and filter out the route carrying the NO_EXPORT, NEIGHBOR CLASS PEER community. This is the standard way of using neighbor classes. A second, optional, way to use Neighbor Classes would be to allow inbound community tagging. In this usage, routes traversing the session would be automatically tagged with a flexible community with the appropriate neighbor class value. This eases configuration. To extend the example above, our neighbor designated PEER would add a community with NEIGHBOR CLASS PEER to routes traversing the BGP session. This community could then be used further down the line to just announce PEER routes to a particular customer. This usage is configurable on a per-neighbor basis. A Neighbor Class is encoded as a 2-octet value with 2 parts: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Neighbor Class | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Local bit can take two values: Value 0: The Neighbor Class is Locally Defined. Value 1: The Neighbor Class is Well Known. 4.1. Locally Defined Neighbor Classes If a router receives a Flexible Community containing a Neighbor Class that it does not recognize, then it should ignore the contents and process the route based on the information in the route that it does understand. If the Transitivity Field of the Flexible Community with the Locally Defined Structure or Type is set to 1 (the community is non-transitive) then the router MUST NOT forward the Flexible Community. Similarly, if the Transitivity Field is set to 0 (the community is transitive) the router MUST forward the community along with the NLRI. Using Locally Defined Neighbor Classes an operator could easily define a set that is locally useful. This set could be used in a flat name space, for example, one could say that "31" would be "Asian Public Peers", and "34" would be European Private Peers. Also, a given BGP Neighbor can be part of multiple Neighbor Classes. This would allow for a hierarchical or additive name space. For example, a neighbor could be part of both "PEER", and locally defined Lange [Page 7] INTERNET DRAFT December 2002 "ASIAN" and "PUBLIC PEER" Classes. The logical matching functionality available is left implementation-dependent. However, the default in such as case is logical OR functionality for matching this neighbor class. In the case where routes are being tagged inbound, then by default a single community with all configured neighbor classes in a list is added. Implementation dependent knobs are suggested to allow more fine grained control. 4.2. Defined Neighbor Classes This document defines Neighbor Class values for common BGP neighbor groupings: ALL NEIGHBORS This class is the default Neighbor Class for all BGP peers. This class is represented by a value of 0 (0x8000). PEER This class is typically applied to sessions where a transit-free relationship exists between the two providers. This class is represented by a value of 1 (0x8001). CUSTOMER This class is typically applied to sessions where the remote end of the session is operated by a customer. This class is represented by a value of 2 (0x8002). UPSTREAM This class is typically applied to sessions where the remote end of the session is operated by a network from which you receive transit routes. This class is represented by a value of 3 (0x8003). CONFEDERATION PEER This class is typically applied to sessions where the remote end of the session is part of a confederation. This class is represented by a value of 4 (0x8004). Lange [Page 8] INTERNET DRAFT December 2002 5. Defined Flexible BGP Community Structures This section defines a number of Structure values which different Type values can inherit. Summary of the Defined Values: - opaque/variable (0x40 or 0xC0) - list of ASN's (0x41 or 0xC1) - list of IPv4 addresses (0x42 or 0xC2) - list of IPv6 addresses (0x43 or OxC3) - list of neighbor_classes (0x44 or 0xC4) Defined Structure can be transitive or non-transitive, they are well known. Opaque/Variable Structure This sort of structure defers interpretation of the community and value field to the Type value. Typically this structure value will be used when the Type value does not have a lot of variations, but rather one structure for the Value Field. This structure is represented by the value 0x00. List of ASN's This structure value means that the Type Field's action is qualified by a list of ASN's, contained in the Value Field. In the case of 2 byte ASN's the value is padded to 4 bytes by inserting 2 octets worth of zeros in the leftmost portion of the value. This structure is represented by the value 0x01. List of IPv4 Addresses This structure value means that the Type Field's action is qualified by a list of IPv4 addresses, contained in the Value Field. This structure is represented by the value 0x02. List of IPv6 Addresses This structure value means that the Type Field's action is qualified by a list of IPv6 addresses, contained in the Value Field. Lange [Page 9] INTERNET DRAFT December 2002 This structure is represented by the value 0x03. List of Neighbor Classes This structure value means that the Type Field's action is qualified by a list of neighbor classes, contained in the Value Field. This structure is represented by the value 0x04. 6. Base BGP Flexible Community Type (Opaque Type) This section defines the base BGP community specification. Since the root value of communities is the ability to tag a route with arbitrary information, and then create a system to give that information meaning, the base flexible community type (type 0), is very simple. This base type could also be described as the "opaque type." All actions can be replicated with a well-thought out, provider dependent, implementation of a scheme using this opaque type. Like all flexible communities, this type can be transitive or non- transitive. This is a well known type. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00,0xC0 | 0x0000 | Originating | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASN | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value Field (0-255 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7. Defined Flexible BGP Community Types The Type Field specifies the subgroup that a set of communities belongs to. Typically this subgroup represents an action to be taken on the data. A variety of well-known Type Values follow. 7.1. NO_EXPORT This grouping of well-known communities specify a list of ASNs, Peer IPs, or Neighbor Classes NOT to announce a route to. Name: NO_EXPORT Type Code: 0x0001 Lange [Page 10] INTERNET DRAFT December 2002 Can Take Structures: Ox01 (ASN), 0x02 (IPv4), 0x03 (IPv6), 0x04 (neighbor-class) Transitive: Non-Transitive Min Length of Value Field: 2 octets Max Length of Value Field: 254 octets Behavior: All routes received with this community MUST NOT be advertised to the list of ASNs, Peer IPs, or Neighbor Classes contained in the Value Field. Notes: GLOBAL_NO_EXPORT is accomplished by sending a NO_EXPORT Flexible Community with the Neighbor Class of 0x00 (ALL NEIGHBORS). GLOBAL_NO_EXPORT's NO_EXPORT behavior is defined as: All routes received with this community 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.) [RFC1997] This is analogous to the NO_EXPORT community defined in [RFC1997]. 7.2. ONLY_EXPORT This grouping of well-known communities specify a list of ASNs, Peer IPs, or Neighbor Classes to announce a route to. Name: ONLY_EXPORT Type Code: 0x0002 Can Take Structures: Ox01 (ASN), 0x02 (IPv4), 0x03 (IPv6), 0x04 (neighbor-class) Transitive: Non-Transitive Min Length of Value Field: 0 octets Max Length of Value Field: 254 octets Behavior: The Value Field contains a list of ASNs, neighbor IP addresses, or Neighbor Classes to which the route should be advertised. The default behavior of a route carrying this community is the same as the GLOBAL_NO_EXPORT behavior, except for the ASNs, IPs, or Neighbor Classes listed in the Value Field. Notes: This community can be used to replicate the NO_ADVERTISE functionality from [RFC1997]. To do so, simply announce ONLY_EXPORT with a Structure of 0x03 or 0x04 (one of the IP address Structures), but with no IP address in the list. This will tell the receiving router that you wish to ONLY_EXPORT this route to NO peer IPs. Lange [Page 11] INTERNET DRAFT December 2002 This community can also be use to replicate the NO_EXPORT_SUBCONFED functionality from [RFC1997]. To do so, simply announce ONLY_EXPORT with a Neighbor Class of CONFEDERATION PEER (4, 0x8004). This will tell the receiving router that you wish to ONLY_EXPORT this route to Confederation Peers. 7.3. ANNOUNCE_WITH This group of well-known communities allows a network to announce a community to an ASN beyond those that it directly peers with, assuming its direct peers allow it to transit the community value. This community group has a lot of flexibility, and could be used to nest another ANNOUNCE_WITH community to gain reach greater than 2 ASN-hops away. If this is a good idea or not is unknown and is left to further study. The only theoretical restriction to the amount of nesting is that the community cannot exceed the maximum size for the Value Field. Since true transitivity can be obtained by simply setting a bit, this community is mainly useful for propagating NO_EXPORT or ONLY_EXPORT (which are non-transitive) to your neighbor's neighbors. In effect, this community, if allowed by the BGP neighbors in the chain, can be used for an originating network to very specifically control the distribution of its routes. This community type does contain a LOT of rope, and should be used with care. In the end, though, a mistake should only effect the person originating the route. Name: ANNOUNCE_WITH Type Code: 0x0003 Can Take Structures: Ox01 (ASN), 0x02 (IPv4), 0x03 (IPv6), 0x04 (neighbor-class) Transitive: Non-Transitive Min Length of Value Field: 8 octets Max Length of Value Field: 254 octets Behavior: This community's Value Field is split into two sections. - The first section is a variable length field that contains the full community value that you wish to announce. - The second section is a variable length field that contains the list of, ASN's, IP addresses, or neighbor_classes you wish to propagate this community to. If you wish to propagate to all peers, use the ALL NEIGHBORS neighbor class. When a router receives this community value, it should strip the ANNOUNCE_WITH community and announce the underlying community value to its neighbor. Lange [Page 12] INTERNET DRAFT December 2002 7.4. PREPEND This community can be used to ask a BGP peer to prepend its own ASN to its peers. Name: PREPEND Type Code: 0x0004 Can Take Structures: Ox01 (ASN), 0x02 (IPv4), 0x03 (IPv6), 0x04 (neighbor-class) Transitive: Non-Transitive Min Length of Value Field: 3 octets Max Length of Value Field: 254 octets Behavior: This community has 2 sections: The first section: Is a one-octet value which specifies the number of times that the ASN should prepend its ASN. It is recommended that operators constrain this value to no more than 3. Implementations MUST offer the ability for an operator to set a maximum bound for this field. The suggested default is also 3. The second section: Contains a list of ASNs, peer IPs, or Neighbor Classes to which the originator of this community wishes its peer to prepend its ASN. 7.5. The BGP VPN Communities These communities are used mostly for BGP MPLS VPN's. Please see RFC2547 [RFC2547] for more detail on how these VPNs are constructed. Name: ROUTE_TARGET Type Code: 0x0005 Can Take Structures: 0x02 (IPv4), 0x03 (IPv6) Transitive: Transitive or Non-Transitive Min Length of Value Field: 4 octets Max Length of Value Field: 254 octets Behavior: The Value Field of this community represents a list of the IP addresses where this route is to be announced. Name: ROUTE_ORIGIN Type Code: 0x0006 Can Take Structures: 0x02 (IPv4), 0x03 (IPv6) Transitive: Transitive or Non-Transitive Min Length of Value Field: 4 octets Max Length of Value Field: 16 octets Lange [Page 13] INTERNET DRAFT December 2002 Behavior: The Value Field of this community represents a list of the IP address where this route is originated. This community can only contain one IP address. Name: LINK_BANDWIDTH Type Code: 0x0007 Can Take Structures: 0x00 (opaque), Ox01 (ASN) Transitive: Transitive or Non-Transitive Min Length of Value Field: 4 octets Max Length of Value Field: 6 octets Behavior: This community consists of two parts: The first part represents the bandwidth of the link in bits-per- second, encoded in IEEE floating point format. This part is 4 octets long. The second part consists of a list of ASNs of the peer whose link bandwidth you wish to propagate. 8. New Capability Code for Flexible Communities To ensure compatibility between implementations that may or may not implement this protocol extension, this document defines a new capability. Capability Code: TBD Capability Length: 1 Capability Value: 0x00 for unsupported 0x01 for supported Capability negotiation is especially important for this attribute because we are creating a transitivity action within an optional, transitive attribute. If an implementation sends a flexible community with the non-transitive bit set within the community to a router that does not support flexible communities, that router will send the community on to its peers when it should not do so. 9. Aggregation Aggregation behaves the same as with other community types. By default if a range of routes is to be aggregated and the resultant aggregates path attributes do not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate should have an Flexible Communities path attribute which contains the set union of all the Flexible Communities from all of the aggregated routes. The default Lange [Page 14] INTERNET DRAFT December 2002 behavior could be overridden via local configuration, in which case handling the Flexible Communities attribute in the presence of route aggregation becomes a matter of the local policy of the BGP speaker that performs the aggregation. 10. Operations Flexible Communities are handled operationally in a manner very similar to other community values. A BGP speaker may use the Flexible Communities attribute to control which routing information it accepts or distributes to its peers. The Flexible Community attribute MUST NOT be used to modify the BGP best path selection algorithm in a way that leads to forwarding loops. A BGP speaker receiving a route that doesn't have the Flexible Commu- nities attribute MAY append this attribute to the route when propagating it to its peers. A BGP speaker receiving a route with the Flexible Communities attribute MAY modify this attribute according to the local policy. If a route has a non-transitivity flexible community, then before advertising the route across the Autonomous system boundary the community SHOULD be removed from the route. However, the community SHOULD NOT be removed when advertising the route across the BGP Confederation boundary. A route may carry the BGP Communities attribute as defined in [RFC1997]), the Extended BGP Communities attribute as defined in [EX- COMM], and the Flexible Communities attribute. In this case the BGP Communities attribute is handled as specified in [RFC1997], the Extended BGP Communities attribute is handled as specified in [EX- COMM], and the Flexible Communities attribute is handled as specified in this document. If older community types are present in addition to the flexible community there is the possibility that the information contained may be redundant. Although effort should be made to avoid this situation, if it does occur the BGP Speaker shall prefer the flexible community first, then the extended community second and then the base community. 11. Security Considerations This extension to BGP does not change the underlying security issues. Lange [Page 15] INTERNET DRAFT December 2002 12. IANA Considerations The values for the Transitivity Field (1 or 0) are completely defined in this document. The assignment policy for the Structure Field is: o The "L" bit's usage is completely defined in this document. o Values of the Structure Field where the "L" bit is "0" are to be assigned in accordance with the Private Use policy outlined in RFC2434 [RFC2434]. o Values of the Structure Field where the "L" bit is "1" defined in this document are: 0-4 (0x40-0x44 and 0xC1-0xC4). Remaining values in this range are to be assigned using the IETF Consensus policy outlined in RFC2434 [RFC2434]. The assignment policy for the Type Field is: o The "L" bit's usage is completely defined in this document. o Values of the Type Field where the "L" bit is "0" are to be assigned in accordance with the Private Use policy outlined in RFC2434 [RFC2434]. o Values of the Type Field where the "L" but is "1" defined in this document are: 0-7 (0x0000-0x0007). Remaining values in this range are to be assigned using the IETF Consensus policy outlined in RFC2434 [RFC2434]. The assignment policy for Neighbor Classes is: o The "L" bit's usage is completely defined in this document. o Values of the Type Field where the "L" bit is "0" are to be assigned in accordance with the Private Use policy outlined in RFC2434 [RFC2434]. o Values of the Type Field where the "L" but is "1" defined in this document are: 0-4 (0x8000-0x8004). Remaining values in this range are to be assigned using the IETF Consensus policy outlined in RFC2434 [RFC2434]. 13. References [RFC1771] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC1997] Chandra, R., Traina, P., Li, T., "BGP Communities Attribute", RFC 1997, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998 Lange [Page 16] INTERNET DRAFT December 2002 [RFC2547] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March 1999. [RFC2842] Chandra, R., Scudder, J., "Capabilities Advertisement with BGP-4", RFC 2842, May 2000. [EX-COMM] Sangli, S., Tappan, D., Rekhter, Y., "BGP Extended Communities Attribute", draft-ietf-idr-bgp-ext-communities-05.txt, work-in-progress, expires November, 2002. [NOPEER] Huston, G., "NOPEER community for BGP route scope control", draft-ietf-ptomaine-nopeer-00.txt, work-in-progress, expires October, 2002. [REDIST] Bonaventure, O., et. al., "Controlling the redistribution of BGP routes", draft-ietf-ptomaine-redistribution-01.txt, work-in- progress, expires February, 2003. 14. Acknowledgements I would like to thank Tom Barron, Dave Ward and especially Hal Peterson for their valuable comments and feedback. 15. Author's Address: Andrew Lange Alcatel 274 Ferguson Drive Mountain View, CA 94043 andrew.lange@alcatel.com Lange [Page 17] --==========F9F1C055D554AA970B14==========-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Mar 3 03:03:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09154 for ; Wed, 3 Mar 2004 03:03:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRLm-0000al-00 for idr-archive@ietf.org; Wed, 03 Mar 2004 03:03:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRKz-0000P5-00 for idr-archive@ietf.org; Wed, 03 Mar 2004 03:02:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyRJy-00009P-00; Wed, 03 Mar 2004 03:01:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRJa-0000GW-NF; Wed, 03 Mar 2004 03:01:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRIz-0000Bb-Se for idr@optimus.ietf.org; Wed, 03 Mar 2004 03:00:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08495 for ; Wed, 3 Mar 2004 03:00:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRIb-0007XI-00 for idr@ietf.org; Wed, 03 Mar 2004 03:00:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRH2-0007BS-00 for idr@ietf.org; Wed, 03 Mar 2004 02:58:37 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AyRGG-0006zJ-00 for idr@ietf.org; Wed, 03 Mar 2004 02:57:49 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D6CF92D48D0 for ; Wed, 3 Mar 2004 02:57:19 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 77477-01-7 for ; Wed, 3 Mar 2004 02:57:18 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 92BB92D4879 for ; Wed, 3 Mar 2004 02:57:17 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] FW: IDR minutes Message-ID: Thread-Topic: [Idr] FW: IDR minutes Thread-Index: AcQAv/OALjBfDCc2Rr2faKxgck3z/AAK3dpA From: "Susan Hares" To: "Sharon Chisholm" , X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Mar 2004 02:57:17 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable we'll add that. We certainly did talk about that! sue -----Original Message----- From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] Sent: Tuesday, March 02, 2004 8:31 PM To: idr@ietf.org Subject: RE: [Idr] FW: IDR minutes hi I believe we also briefly discussed setting up a call to discuss the v2 = MIB and that interested parties should contact either Sue or myself. Sharon -----Original Message----- From: Susan Hares [mailto:shares@nexthop.com]=20 Sent: Monday, March 01, 2004 10:40 PM To: idr@ietf.org Subject: [Idr] FW: IDR minutes Minutes for 3/1/04 session -----Original Message----- From: Jake Khuon=20 Sent: Monday, March 01, 2004 3:18 AM To: Susan Hares; yakov@juniper.net Subject: IDR minutes Inter-Domain Routing WG (idr) Monday, March 1 at 1530-1730 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: Sue Hares (skh@nexthop.com) Yakov Rekhter (yakov@juniper.net) =20 AGENDA: 1) Agenda Bashing Agenda Slides 2) Document status [5 minutes] - Bundle went to IESG BGP-4 draft-23 draft-ietf-idr-bgp4-23.txt BGP-4 V1 MIB draft-ietf-idr-bgp4-mib-13.txt BGP-4 Protocol Analysis draft-ietf-idr-bgp-analysis-04.txt BGP Security Vulnerabilities Analysis draft-ietf-idr-bgp-vuln-00.txt Experience with the BGP-4 Protocol draft-ietf-idr-bgp4-experience-protocol-03.txt BGP 4 Implementation Report draft-ietf-idr-bgp-implementation-00.txt BGP-4 V1 MIB implementation report draft-ietf-idr-bgp-mibagent-survey-01.txt Presentation 3) Implementation Reports and FSM issues for current drafts [10 minutes] document: None, presentation only Presentation Sue Hares - Yakov: route-reflector update status? - Enke: route-reflector update (4 weeks) - Enke: prefix-orf was not added to charter - Sue: yes it was added, administrative error in listing 4) BGP Peer Restart Backoff Mechanisms [10 minutes] document: draft-hares-bgp-backoff-01.txt (ietf) (-02 Update) Author: Susan Hares Presentation Sue Hares - Alex: draft should say informational achieve functionality using existing states? - Sue: no... can't use existing states; already investigated that option 5) Deterministic Route Redistribution into BGP [10 minutes] document: draft-chen-bgp-redist-00.txt Authors: Jenny Yuan, Enke Chen Enke Chen - Andrew Lang: used to use configured localpref tweaking; not management intensive... unsure if this is needed - Enke: timing dependent non-deterministic problem so current knobs cannot be used reliably; does not break anything... backwards compatible - Andrew Lang: better to educate people about localpref - Barry Friedman: lacks generality too narrow a problem space... only addresses RIP/iBGP interaction - Enke: tweaking of admin distance defines a baseline - need per route granularity to solve for all cases?=20 Possibility of adding more configuration conflicts. - Alex: this problem only occurs if there's a consistency issue between two places... May not be an issue for a single selection point. Introduction of new step will effect current deployment traffic selection? - Enke: This will happen regardless. Should not effect current deployments and if there's a change, the change will be for the better. - By definition, it does change behavior. - Alex: Will this be applicable to only situations where there is a problem? - Yakov: Is this an implementation method? - Alex: Is this informational or standards-track? - Enke: Either is fine - It can't be a local matter because it must be consistent throughout the entire system - Enke: Decision on redistributed routes is made locally in each router - Behavior is changed because new code now uses admin distance over localpref? - Enke: If only localpref is used then things should not change - Cengiz: If route-reflector is used? - Enke: I need to think about it further 6) BGP based auto-discovery [Sue Hares, P. Unbehagen] [10 minutes] document: draft-hlmu-l2vpn-bgp-discovery-00.txt authors: P. Unbehagen, P. Muley, V. Radoaca, Susan Hares Presentation Sue Hares, P. Unbehagen - Already a L2VPN draft that addresses this in a defined NLRI with label information - Paul: This draft is meant to provide LDP pseudowire config information - Other spec can do same thing [autodiscovery] without label information - Kireeti: Would like to be able to use this AFI with different SAFI [65] and NLRI format - Would the two SAFIs be solving similar problems - Kireeti: My SAFI solves different problems 7) BGP Assignment of AFI/SAFI address [10 minutes] Document: draft-hares-bgp-assign-afisafi-00.txt=20 Author: Susan Hares Presentation Sue Hares 8) BGP Attribute Codes and Suggested Procedures Document: draft-kompella-zinin-early-allocation-00.txt Author: Alex Zinin, Kireeti Kompella Presentation Alex Zinin - Sharon: talking about protocols and not OIDs preallocation?=20 bad to preallocate in the MIB... different from what other WGs; exclude MIB OIDs - Kireeti: not suggesting that everyone use this - It would have been nicer to have had OIDs preallocated so as not to reimpliment the MIB =09 - Sharon: OIDs not allocated to drafts because if the drafts goes away then you've wasted numbers - Lou Berger: allocation with 1 year with 1 renewal is too short; alterntate policy: as long as draft or version is alive, expire in 3 to 6 months - Alex: that suggestion ties validity with ability of author to submit the draft; suggestion: once document is submitted to IESG then we freeze. Don't want to allocate codepoints too early. - Dave Meyer: Are you sure that IANA can time anything out - Alex: No - Dave Meyer: WG chair needs to manage this? - What happens if the allocation is not renewed and code is using it still? - Alex: Add provision to document to deprecate but not return - Kireeti: Deprecate for a period of time to give people time to remove. Formal process to do early allocations and if it goes through then stick with it but if it doesn't go through then people must take this out. - Dino: Allocate experimental codepoints and once standardised, then adopt standard codepoint for sending but accept both. - Sue: Good for SAFIs as well as AFIs? - Dino: All well known IANA values - Fenner: RFC already documents a process for transitioning codepoints 9) Charter Discussion [20 minutes] Thanks to all implementers who send in reports on the base specification, we will be opening the charter. This section of the meeting will discuss what items will be added to the charter. Presentation - Top three most important; maybe ECMP little higher than Fault Isolation -- /*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D[ Jake Khuon = = ]=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Field App. Engineer http://www.nexthop.com/ /\ /~ E X T H O = P | | Ofc: +1 (425) 391-2262 Fax: +1 (425) 391-6772 / \/ Technologies, = Inc.| +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D[ 1911 Landings Drive, Mountain View, CA = 94043 USA ]=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Mar 3 03:23:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10378 for ; Wed, 3 Mar 2004 03:23:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRfP-00047z-00 for idr-archive@ietf.org; Wed, 03 Mar 2004 03:23:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRe6-0003lp-00 for idr-archive@ietf.org; Wed, 03 Mar 2004 03:22:27 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyRcA-0003QU-02; Wed, 03 Mar 2004 03:20:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyROV-0005rj-Ks; Wed, 03 Mar 2004 03:06:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRON-0001Oh-6y; Wed, 03 Mar 2004 03:06:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyP84-0000Lm-V2 for idr@optimus.ietf.org; Wed, 03 Mar 2004 00:41:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03221 for ; Wed, 3 Mar 2004 00:41:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyP82-0007Ws-00 for idr@ietf.org; Wed, 03 Mar 2004 00:41:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyP76-0007JP-00 for idr@ietf.org; Wed, 03 Mar 2004 00:40:13 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AyP60-0006xh-00 for idr@ietf.org; Wed, 03 Mar 2004 00:39:04 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i235cWA00544 for ; Tue, 2 Mar 2004 23:38:33 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1699KRK7>; Wed, 3 Mar 2004 06:38:27 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503B64455@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Sharon Chisholm , idr@ietf.org Cc: "Wijnen, Bert (Bert)" Subject: RE: [Idr] Experimental code-points MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C400E1.BFB30A80" Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Mar 2004 06:38:26 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C400E1.BFB30A80 Content-Type: text/plain Good point. They can get an OID assigned in the experimental branch though. Thanks, Bert -----Original Message----- From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] Sent: dinsdag 2 maart 2004 9:30 To: idr@ietf.org Cc: Wijnen, Bert (Bert) Subject: RE: [Idr] Experimental code-points hi In looking through http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated. In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' Sharon -----Original Message----- From: Alex Zinin [ mailto:zinin@psg.com ] Sent: Monday, March 01, 2004 3:11 AM To: idr@ietf.org Subject: [Idr] Experimental code-points As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. -- Alex http://www.psg.com/~zinin/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------_=_NextPart_001_01C400E1.BFB30A80 Content-Type: text/html RE: [Idr] Experimental code-points
Good point. They can get an OID assigned in the experimental branch though.
 

Thanks,
Bert

-----Original Message-----
From: Sharon Chisholm [mailto:schishol@nortelnetworks.com]
Sent: dinsdag 2 maart 2004 9:30
To: idr@ietf.org
Cc: Wijnen, Bert (Bert)
Subject: RE: [Idr] Experimental code-points

hi

In looking through
        http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt

I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated.

In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added.

'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.'

Sharon

-----Original Message-----
From: Alex Zinin [mailto:zinin@psg.com]
Sent: Monday, March 01, 2004 3:11 AM
To: idr@ietf.org
Subject: [Idr] Experimental code-points



As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable.

--
Alex
http://www.psg.com/~zinin/


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr

------_=_NextPart_001_01C400E1.BFB30A80-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Mar 3 03:25:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10550 for ; Wed, 3 Mar 2004 03:25:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRg7-0004Fj-GA for idr-archive@odin.ietf.org; Wed, 03 Mar 2004 03:24:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i238OV68016339 for idr-archive@odin.ietf.org; Wed, 3 Mar 2004 03:24:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRg6-0004FK-Qz for idr-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 03:24:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10381 for ; Wed, 3 Mar 2004 03:23:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRfQ-00048G-00 for idr-web-archive@ietf.org; Wed, 03 Mar 2004 03:23:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRe7-0003m2-00 for idr-web-archive@ietf.org; Wed, 03 Mar 2004 03:22:28 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyRcA-0003QU-02; Wed, 03 Mar 2004 03:20:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyROV-0005rj-Ks; Wed, 03 Mar 2004 03:06:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRON-0001Oh-6y; Wed, 03 Mar 2004 03:06:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyP84-0000Lm-V2 for idr@optimus.ietf.org; Wed, 03 Mar 2004 00:41:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03221 for ; Wed, 3 Mar 2004 00:41:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyP82-0007Ws-00 for idr@ietf.org; Wed, 03 Mar 2004 00:41:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyP76-0007JP-00 for idr@ietf.org; Wed, 03 Mar 2004 00:40:13 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AyP60-0006xh-00 for idr@ietf.org; Wed, 03 Mar 2004 00:39:04 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i235cWA00544 for ; Tue, 2 Mar 2004 23:38:33 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1699KRK7>; Wed, 3 Mar 2004 06:38:27 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503B64455@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Sharon Chisholm , idr@ietf.org Cc: "Wijnen, Bert (Bert)" Subject: RE: [Idr] Experimental code-points MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C400E1.BFB30A80" Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Mar 2004 06:38:26 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C400E1.BFB30A80 Content-Type: text/plain Good point. They can get an OID assigned in the experimental branch though. Thanks, Bert -----Original Message----- From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] Sent: dinsdag 2 maart 2004 9:30 To: idr@ietf.org Cc: Wijnen, Bert (Bert) Subject: RE: [Idr] Experimental code-points hi In looking through http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated. In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' Sharon -----Original Message----- From: Alex Zinin [ mailto:zinin@psg.com ] Sent: Monday, March 01, 2004 3:11 AM To: idr@ietf.org Subject: [Idr] Experimental code-points As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. -- Alex http://www.psg.com/~zinin/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------_=_NextPart_001_01C400E1.BFB30A80 Content-Type: text/html RE: [Idr] Experimental code-points
Good point. They can get an OID assigned in the experimental branch though.
 

Thanks,
Bert

-----Original Message-----
From: Sharon Chisholm [mailto:schishol@nortelnetworks.com]
Sent: dinsdag 2 maart 2004 9:30
To: idr@ietf.org
Cc: Wijnen, Bert (Bert)
Subject: RE: [Idr] Experimental code-points

hi

In looking through
        http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt

I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated.

In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added.

'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.'

Sharon

-----Original Message-----
From: Alex Zinin [mailto:zinin@psg.com]
Sent: Monday, March 01, 2004 3:11 AM
To: idr@ietf.org
Subject: [Idr] Experimental code-points



As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable.

--
Alex
http://www.psg.com/~zinin/


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr

------_=_NextPart_001_01C400E1.BFB30A80-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Mar 3 08:08:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24388 for ; Wed, 3 Mar 2004 08:08:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyW7O-0005uc-00 for idr-archive@ietf.org; Wed, 03 Mar 2004 08:08:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyW5V-0005Ov-00 for idr-archive@ietf.org; Wed, 03 Mar 2004 08:07:01 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyW4T-0005Bb-01; Wed, 03 Mar 2004 08:05:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyVwy-0003wF-64; Wed, 03 Mar 2004 07:58:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVwn-0001Ew-5R; Wed, 03 Mar 2004 07:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVve-0001Ck-MW for idr@optimus.ietf.org; Wed, 03 Mar 2004 07:57:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23537 for ; Wed, 3 Mar 2004 07:56:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyVvJ-0003TX-00 for idr@ietf.org; Wed, 03 Mar 2004 07:56:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyVuZ-0003LR-00 for idr@ietf.org; Wed, 03 Mar 2004 07:55:44 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AyVtw-0003Bs-00 for idr@ietf.org; Wed, 03 Mar 2004 07:55:04 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyVtq-0007lo-G4; Wed, 03 Mar 2004 12:54:58 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <15122904797.20040303215438@psg.com> To: "Wijnen, Bert (Bert)" CC: Sharon Chisholm , idr@ietf.org Subject: Re: [Idr] Experimental code-points In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15503B64455@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15503B64455@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Mar 2004 21:54:38 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Bert, Sharon- The doc says: > This memo only addresses the early allocation of code points from > spaces whose allocation policy is "Standards Action" [2434] AND have > been amended to permit early allocation. This permission must be > granted by the IESG, and code spaces with permission for early > allocation must be marked as such in the IANA registry. In other words, it doesn't apply to an existing registry unless IESG approves that this process is applicable. This leaves existing registries, OID included, intact unless someone takes an action. Is this good enough? -- Alex http://www.psg.com/~zinin/ Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote: > Good point. They can get an OID assigned in the experimental branch though. > Thanks, > Bert > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] > Sent: dinsdag 2 maart 2004 9:30 > To: idr@ietf.org > Cc: Wijnen, Bert (Bert) > Subject: RE: [Idr] Experimental code-points > hi > In looking through > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt > I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated. > In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. > 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' > Sharon > -----Original Message----- > From: Alex Zinin [ mailto:zinin@psg.com ] > Sent: Monday, March 01, 2004 3:11 AM > To: idr@ietf.org > Subject: [Idr] Experimental code-points > As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Mar 3 08:10:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24699 for ; Wed, 3 Mar 2004 08:10:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyW89-000289-S3 for idr-archive@odin.ietf.org; Wed, 03 Mar 2004 08:09:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23D9jZN008185 for idr-archive@odin.ietf.org; Wed, 3 Mar 2004 08:09:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyW89-00027v-Nb for idr-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 08:09:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24392 for ; Wed, 3 Mar 2004 08:08:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyW7P-0005uk-00 for idr-web-archive@ietf.org; Wed, 03 Mar 2004 08:08:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyW5V-0005P2-00 for idr-web-archive@ietf.org; Wed, 03 Mar 2004 08:07:02 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyW4T-0005Bb-01; Wed, 03 Mar 2004 08:05:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyVwy-0003wF-64; Wed, 03 Mar 2004 07:58:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVwn-0001Ew-5R; Wed, 03 Mar 2004 07:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVve-0001Ck-MW for idr@optimus.ietf.org; Wed, 03 Mar 2004 07:57:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23537 for ; Wed, 3 Mar 2004 07:56:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyVvJ-0003TX-00 for idr@ietf.org; Wed, 03 Mar 2004 07:56:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyVuZ-0003LR-00 for idr@ietf.org; Wed, 03 Mar 2004 07:55:44 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AyVtw-0003Bs-00 for idr@ietf.org; Wed, 03 Mar 2004 07:55:04 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyVtq-0007lo-G4; Wed, 03 Mar 2004 12:54:58 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <15122904797.20040303215438@psg.com> To: "Wijnen, Bert (Bert)" CC: Sharon Chisholm , idr@ietf.org Subject: Re: [Idr] Experimental code-points In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15503B64455@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15503B64455@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Mar 2004 21:54:38 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Bert, Sharon- The doc says: > This memo only addresses the early allocation of code points from > spaces whose allocation policy is "Standards Action" [2434] AND have > been amended to permit early allocation. This permission must be > granted by the IESG, and code spaces with permission for early > allocation must be marked as such in the IANA registry. In other words, it doesn't apply to an existing registry unless IESG approves that this process is applicable. This leaves existing registries, OID included, intact unless someone takes an action. Is this good enough? -- Alex http://www.psg.com/~zinin/ Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote: > Good point. They can get an OID assigned in the experimental branch though. > Thanks, > Bert > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] > Sent: dinsdag 2 maart 2004 9:30 > To: idr@ietf.org > Cc: Wijnen, Bert (Bert) > Subject: RE: [Idr] Experimental code-points > hi > In looking through > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt > I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated. > In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. > 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' > Sharon > -----Original Message----- > From: Alex Zinin [ mailto:zinin@psg.com ] > Sent: Monday, March 01, 2004 3:11 AM > To: idr@ietf.org > Subject: [Idr] Experimental code-points > As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Mar 3 17:14:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29831 for ; Wed, 3 Mar 2004 17:14:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayeda-0001l4-00 for idr-archive@ietf.org; Wed, 03 Mar 2004 17:14:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayecc-0001bg-00 for idr-archive@ietf.org; Wed, 03 Mar 2004 17:13:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayebh-0001TN-00; Wed, 03 Mar 2004 17:12:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayeav-0007hG-Ha; Wed, 03 Mar 2004 17:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyeZy-0007gg-M0 for idr@optimus.ietf.org; Wed, 03 Mar 2004 17:11:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29749 for ; Wed, 3 Mar 2004 17:10:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyeZw-00019t-00 for idr@ietf.org; Wed, 03 Mar 2004 17:11:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyeZ1-0000y2-00 for idr@ietf.org; Wed, 03 Mar 2004 17:10:04 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1AyeY5-0000bf-00 for idr@ietf.org; Wed, 03 Mar 2004 17:09:05 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i23M8ZBm026489 for ; Wed, 3 Mar 2004 14:08:35 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i23M8Zo00577 for ; Wed, 3 Mar 2004 14:08:35 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200403032208.i23M8Zo00577@merlot.juniper.net> To: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <35832.1078351715.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 03 Mar 2004 14:08:35 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Folks, Let me propose that those who think that the base spec should be changed please get together and propose a *specific* replacement text, *taking into account* all the comments on this topic that have been posted to the list over the last few days (as well as the past discussion on this topic). Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Mar 3 17:15:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29886 for ; Wed, 3 Mar 2004 17:15:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayedd-0007tF-Dg for idr-archive@odin.ietf.org; Wed, 03 Mar 2004 17:14:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23MEnCh030321 for idr-archive@odin.ietf.org; Wed, 3 Mar 2004 17:14:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayedd-0007sy-4f for idr-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 17:14:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29849 for ; Wed, 3 Mar 2004 17:14:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayeda-0001l9-00 for idr-web-archive@ietf.org; Wed, 03 Mar 2004 17:14:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayecd-0001bn-00 for idr-web-archive@ietf.org; Wed, 03 Mar 2004 17:13:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayebh-0001TN-00; Wed, 03 Mar 2004 17:12:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayeav-0007hG-Ha; Wed, 03 Mar 2004 17:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyeZy-0007gg-M0 for idr@optimus.ietf.org; Wed, 03 Mar 2004 17:11:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29749 for ; Wed, 3 Mar 2004 17:10:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyeZw-00019t-00 for idr@ietf.org; Wed, 03 Mar 2004 17:11:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyeZ1-0000y2-00 for idr@ietf.org; Wed, 03 Mar 2004 17:10:04 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1AyeY5-0000bf-00 for idr@ietf.org; Wed, 03 Mar 2004 17:09:05 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i23M8ZBm026489 for ; Wed, 3 Mar 2004 14:08:35 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i23M8Zo00577 for ; Wed, 3 Mar 2004 14:08:35 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200403032208.i23M8Zo00577@merlot.juniper.net> To: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <35832.1078351715.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 03 Mar 2004 14:08:35 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Folks, Let me propose that those who think that the base spec should be changed please get together and propose a *specific* replacement text, *taking into account* all the comments on this topic that have been posted to the list over the last few days (as well as the past discussion on this topic). Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Mar 3 19:21:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09500 for ; Wed, 3 Mar 2004 19:21:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aygcf-0002Zp-00 for idr-archive@ietf.org; Wed, 03 Mar 2004 19:21:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aygbj-0002Pz-00 for idr-archive@ietf.org; Wed, 03 Mar 2004 19:21:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aygb1-0002Gv-00; Wed, 03 Mar 2004 19:20:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aygaq-0000Td-EI; Wed, 03 Mar 2004 19:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aygag-0000Sc-84 for idr@optimus.ietf.org; Wed, 03 Mar 2004 19:19:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09441 for ; Wed, 3 Mar 2004 19:19:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aygae-0002Fw-00 for idr@ietf.org; Wed, 03 Mar 2004 19:19:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AygZh-00027d-00 for idr@ietf.org; Wed, 03 Mar 2004 19:18:54 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AygZ0-0001q8-00 for idr@ietf.org; Wed, 03 Mar 2004 19:18:10 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i240HdQ01415 for ; Wed, 3 Mar 2004 19:17:39 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 19:17:39 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A60B0F0@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: idr@ietf.org Cc: "Wijnen, Bert (Bert)" Subject: RE: [Idr] Experimental code-points MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Mar 2004 19:17:39 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 hi My concern is that this is opening us up to even more queries for premature OID assignment, for which we are most likely going to say they need to wait for the RFC. It's a matter of cutting off a frequently asked question by having clear text in the draft that properly sets expectations. People may reason that if Foo qualifies then the Foo MIB does, so I'd like to see some text in the document that will make it more clear that this isn't the case. Perhaps a middle ground would be to add text indicating that early allocation of code points for the protocol is independent of the MIB OID allocation, or something along those lines. Sharon -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Wednesday, March 03, 2004 7:55 AM To: Wijnen, Bert (Bert) Cc: Chisholm, Sharon [CAR:0S00:EXCH]; idr@ietf.org Subject: Re: [Idr] Experimental code-points Bert, Sharon- The doc says: > This memo only addresses the early allocation of code points from > spaces whose allocation policy is "Standards Action" [2434] AND have > been amended to permit early allocation. This permission must be > granted by the IESG, and code spaces with permission for early > allocation must be marked as such in the IANA registry. In other words, it doesn't apply to an existing registry unless IESG approves that this process is applicable. This leaves existing registries, OID included, intact unless someone takes an action. Is this good enough? -- Alex http://www.psg.com/~zinin/ Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote: > Good point. They can get an OID assigned in the experimental branch > though. > Thanks, > Bert > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] > Sent: dinsdag 2 maart 2004 9:30 > To: idr@ietf.org > Cc: Wijnen, Bert (Bert) > Subject: RE: [Idr] Experimental code-points > hi > In looking through > > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocat > ion-00.txt > tion-00.txt> > I would suggest the following change to address my concern that it > inappropriately sets the expectation that MIB OIDs will be > pre-allocated. > In either the 'Introduction' or in the section 'Conditions for Early > Allocation' the following text needs to be added. > 'Note that under no condition will MIB Object Identifiers (OIDs) be > allocated before the RFC is published.' > Sharon > -----Original Message----- > From: Alex Zinin [ mailto:zinin@psg.com ] > Sent: Monday, March 01, 2004 3:11 AM > To: idr@ietf.org > Subject: [Idr] Experimental code-points > As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Mar 3 19:22:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09533 for ; Wed, 3 Mar 2004 19:22:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aygcj-0000iG-1E for idr-archive@odin.ietf.org; Wed, 03 Mar 2004 19:22:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i240M0Ec002724 for idr-archive@odin.ietf.org; Wed, 3 Mar 2004 19:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aygci-0000hr-4C for idr-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 19:22:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09518 for ; Wed, 3 Mar 2004 19:21:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aygcg-0002a2-00 for idr-web-archive@ietf.org; Wed, 03 Mar 2004 19:21:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aygbk-0002Q8-00 for idr-web-archive@ietf.org; Wed, 03 Mar 2004 19:21:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aygb1-0002Gv-00; Wed, 03 Mar 2004 19:20:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aygaq-0000Td-EI; Wed, 03 Mar 2004 19:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aygag-0000Sc-84 for idr@optimus.ietf.org; Wed, 03 Mar 2004 19:19:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09441 for ; Wed, 3 Mar 2004 19:19:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aygae-0002Fw-00 for idr@ietf.org; Wed, 03 Mar 2004 19:19:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AygZh-00027d-00 for idr@ietf.org; Wed, 03 Mar 2004 19:18:54 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AygZ0-0001q8-00 for idr@ietf.org; Wed, 03 Mar 2004 19:18:10 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i240HdQ01415 for ; Wed, 3 Mar 2004 19:17:39 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 19:17:39 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A60B0F0@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: idr@ietf.org Cc: "Wijnen, Bert (Bert)" Subject: RE: [Idr] Experimental code-points MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Mar 2004 19:17:39 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 hi My concern is that this is opening us up to even more queries for premature OID assignment, for which we are most likely going to say they need to wait for the RFC. It's a matter of cutting off a frequently asked question by having clear text in the draft that properly sets expectations. People may reason that if Foo qualifies then the Foo MIB does, so I'd like to see some text in the document that will make it more clear that this isn't the case. Perhaps a middle ground would be to add text indicating that early allocation of code points for the protocol is independent of the MIB OID allocation, or something along those lines. Sharon -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Wednesday, March 03, 2004 7:55 AM To: Wijnen, Bert (Bert) Cc: Chisholm, Sharon [CAR:0S00:EXCH]; idr@ietf.org Subject: Re: [Idr] Experimental code-points Bert, Sharon- The doc says: > This memo only addresses the early allocation of code points from > spaces whose allocation policy is "Standards Action" [2434] AND have > been amended to permit early allocation. This permission must be > granted by the IESG, and code spaces with permission for early > allocation must be marked as such in the IANA registry. In other words, it doesn't apply to an existing registry unless IESG approves that this process is applicable. This leaves existing registries, OID included, intact unless someone takes an action. Is this good enough? -- Alex http://www.psg.com/~zinin/ Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote: > Good point. They can get an OID assigned in the experimental branch > though. > Thanks, > Bert > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] > Sent: dinsdag 2 maart 2004 9:30 > To: idr@ietf.org > Cc: Wijnen, Bert (Bert) > Subject: RE: [Idr] Experimental code-points > hi > In looking through > > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocat > ion-00.txt > tion-00.txt> > I would suggest the following change to address my concern that it > inappropriately sets the expectation that MIB OIDs will be > pre-allocated. > In either the 'Introduction' or in the section 'Conditions for Early > Allocation' the following text needs to be added. > 'Note that under no condition will MIB Object Identifiers (OIDs) be > allocated before the RFC is published.' > Sharon > -----Original Message----- > From: Alex Zinin [ mailto:zinin@psg.com ] > Sent: Monday, March 01, 2004 3:11 AM > To: idr@ietf.org > Subject: [Idr] Experimental code-points > As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 8 15:45:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28959 for ; Mon, 8 Mar 2004 15:45:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0RdR-0003FF-00 for idr-archive@ietf.org; Mon, 08 Mar 2004 15:46:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Rah-0002Pz-00 for idr-archive@ietf.org; Mon, 08 Mar 2004 15:43:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0RYE-0001jl-00; Mon, 08 Mar 2004 15:40:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RXg-0001jc-5Q; Mon, 08 Mar 2004 15:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzbSu-0001uy-To for idr@optimus.ietf.org; Sat, 06 Mar 2004 08:03:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16033 for ; Sat, 6 Mar 2004 08:03:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzbSt-0000ef-00 for idr@ietf.org; Sat, 06 Mar 2004 08:03:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzbS1-0000VC-00 for idr@ietf.org; Sat, 06 Mar 2004 08:02:46 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AzbRU-0000LD-00 for idr@ietf.org; Sat, 06 Mar 2004 08:02:12 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i26D1c020197 for ; Sat, 6 Mar 2004 07:01:39 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1699NT0S>; Sat, 6 Mar 2004 14:01:37 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503B64AB9@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Alex Zinin , "Wijnen, Bert (Bert)" Cc: Sharon Chisholm , idr@ietf.org Subject: RE: [Idr] Experimental code-points MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 6 Mar 2004 14:01:34 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Aha ... good. For me that Covers it. But... it might be good to add that "IESG approval" into the list of "conditions" in sect 2 as well. I bet people will often skip the intro and go straight to the "what are the conditions" section to see if they can request an early registration. Thanks, Bert > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: woensdag 3 maart 2004 21:55 > To: Wijnen, Bert (Bert) > Cc: Sharon Chisholm; idr@ietf.org > Subject: Re: [Idr] Experimental code-points > > > Bert, Sharon- > > The doc says: > > > This memo only addresses the early allocation of code points from > > spaces whose allocation policy is "Standards Action" > [2434] AND have > > been amended to permit early allocation. This permission must be > > granted by the IESG, and code spaces with permission for early > > allocation must be marked as such in the IANA registry. > > In other words, it doesn't apply to an existing registry > unless IESG approves > that this process is applicable. This leaves existing > registries, OID included, > intact unless someone takes an action. > > Is this good enough? > > -- > Alex > http://www.psg.com/~zinin/ > > Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote: > > Good point. They can get an OID assigned in the > experimental branch though. > > > > Thanks, > > Bert > > > -----Original Message----- > > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] > > Sent: dinsdag 2 maart 2004 9:30 > > To: idr@ietf.org > > Cc: Wijnen, Bert (Bert) > > Subject: RE: [Idr] Experimental code-points > > > > > hi > > > In looking through > > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt > I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated. > In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. > 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' > Sharon > -----Original Message----- > From: Alex Zinin [ mailto:zinin@psg.com ] > Sent: Monday, March 01, 2004 3:11 AM > To: idr@ietf.org > Subject: [Idr] Experimental code-points > As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 8 15:46:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29024 for ; Mon, 8 Mar 2004 15:46:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RdT-0002GM-M1 for idr-archive@odin.ietf.org; Mon, 08 Mar 2004 15:46:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28Kk3Ik008692 for idr-archive@odin.ietf.org; Mon, 8 Mar 2004 15:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RdT-0002G7-Hb for idr-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 15:46:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28973 for ; Mon, 8 Mar 2004 15:46:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0RdS-0003FZ-00 for idr-web-archive@ietf.org; Mon, 08 Mar 2004 15:46:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Raj-0002QT-00 for idr-web-archive@ietf.org; Mon, 08 Mar 2004 15:43:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0RYE-0001jl-00; Mon, 08 Mar 2004 15:40:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RXg-0001jc-5Q; Mon, 08 Mar 2004 15:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzbSu-0001uy-To for idr@optimus.ietf.org; Sat, 06 Mar 2004 08:03:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16033 for ; Sat, 6 Mar 2004 08:03:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzbSt-0000ef-00 for idr@ietf.org; Sat, 06 Mar 2004 08:03:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzbS1-0000VC-00 for idr@ietf.org; Sat, 06 Mar 2004 08:02:46 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AzbRU-0000LD-00 for idr@ietf.org; Sat, 06 Mar 2004 08:02:12 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i26D1c020197 for ; Sat, 6 Mar 2004 07:01:39 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1699NT0S>; Sat, 6 Mar 2004 14:01:37 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503B64AB9@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Alex Zinin , "Wijnen, Bert (Bert)" Cc: Sharon Chisholm , idr@ietf.org Subject: RE: [Idr] Experimental code-points MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 6 Mar 2004 14:01:34 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Aha ... good. For me that Covers it. But... it might be good to add that "IESG approval" into the list of "conditions" in sect 2 as well. I bet people will often skip the intro and go straight to the "what are the conditions" section to see if they can request an early registration. Thanks, Bert > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: woensdag 3 maart 2004 21:55 > To: Wijnen, Bert (Bert) > Cc: Sharon Chisholm; idr@ietf.org > Subject: Re: [Idr] Experimental code-points > > > Bert, Sharon- > > The doc says: > > > This memo only addresses the early allocation of code points from > > spaces whose allocation policy is "Standards Action" > [2434] AND have > > been amended to permit early allocation. This permission must be > > granted by the IESG, and code spaces with permission for early > > allocation must be marked as such in the IANA registry. > > In other words, it doesn't apply to an existing registry > unless IESG approves > that this process is applicable. This leaves existing > registries, OID included, > intact unless someone takes an action. > > Is this good enough? > > -- > Alex > http://www.psg.com/~zinin/ > > Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote: > > Good point. They can get an OID assigned in the > experimental branch though. > > > > Thanks, > > Bert > > > -----Original Message----- > > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] > > Sent: dinsdag 2 maart 2004 9:30 > > To: idr@ietf.org > > Cc: Wijnen, Bert (Bert) > > Subject: RE: [Idr] Experimental code-points > > > > > hi > > > In looking through > > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt > I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated. > In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. > 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' > Sharon > -----Original Message----- > From: Alex Zinin [ mailto:zinin@psg.com ] > Sent: Monday, March 01, 2004 3:11 AM > To: idr@ietf.org > Subject: [Idr] Experimental code-points > As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 9 18:18:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06488 for ; Tue, 9 Mar 2004 18:18:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0qV2-0000cy-00 for idr-archive@ietf.org; Tue, 09 Mar 2004 18:19:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0qU6-0000Tj-00 for idr-archive@ietf.org; Tue, 09 Mar 2004 18:18:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0qTg-0000KN-00; Tue, 09 Mar 2004 18:17:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0qT7-0000y1-LN; Tue, 09 Mar 2004 18:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0qSN-0000nK-1i for idr@optimus.ietf.org; Tue, 09 Mar 2004 18:16:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06217 for ; Tue, 9 Mar 2004 18:16:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0qSK-0000At-00 for idr@ietf.org; Tue, 09 Mar 2004 18:16:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0qRK-00000m-00 for idr@ietf.org; Tue, 09 Mar 2004 18:15:11 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B0qQR-0007ex-00 for idr@ietf.org; Tue, 09 Mar 2004 18:14:15 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0qQR-0008Wb-RW; Tue, 09 Mar 2004 23:14:15 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <22240253766.20040309151326@psg.com> To: "Susan Hares" CC: idr@ietf.org Subject: Re: [Idr] FW: IDR minutes In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Mar 2004 15:13:26 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sue- Some corrections below, please. Monday, March 1, 2004, 7:40:23 PM, Susan Hares wrote: [...] > 4) BGP Peer Restart Backoff Mechanisms [10 minutes] > document: draft-hares-bgp-backoff-01.txt (ietf) (-02 Update) > Author: Susan Hares > Presentation Sue Hares > - Alex: draft should say informational Change to "the draft says it's an RFC, shouldn't do that" > achieve functionality using existing states? > - Sue: no... can't use existing states; already > investigated that option > 5) Deterministic Route Redistribution into BGP [10 minutes] > document: draft-chen-bgp-redist-00.txt > Authors: Jenny Yuan, Enke Chen > Enke Chen > - Andrew Lang: used to use configured localpref tweaking; not > management intensive... unsure if this is needed > - Enke: timing dependent non-deterministic problem so > current knobs cannot be used reliably; does not > break anything... backwards compatible > - Andrew Lang: better to educate people about localpref > - Barry Friedman: lacks generality too narrow a problem > space... only addresses RIP/iBGP interaction > - Enke: tweaking of admin distance defines a baseline > - need per route granularity to solve for all cases? > Possibility of adding more configuration conflicts. > - Alex: this problem only occurs if there's a consistancy > issue between two places... May not be an issue for > a single selection point. Change to: the problem occurs if a router has to select best routes in two places: as in the draft--once in BGP and once in the routing table, and the decisions are not consistent. wonder if the problem still exists if an implementation selects best paths in one place only, e.g. gated?. if so, is the problem implementation-specific, not to mean it shouldn't resolved. Alex sent an e-mail to the list with more details. > 8) BGP Attribute Codes and Suggested Procedures > Document: draft-kompella-zinin-early-allocation-00.txt > Author: Alex Zinin, Kireeti Kompella > Presentation Alex Zinin > - Sharon: talking about protocols and not OIDs preallocation? > bad to preallocate in the MIB... different from what > other WGs; exclude MIB OIDs > - Kireeti: not suggesting that everyone use this > - It would have been nicer to have had OIDs > preallocated so as not to reimpliment the MIB > - Sharon: OIDs not allocated to drafts because if the drafts > goes away then you've wasted numbers > - Lou Berger: allocation with 1 year with 1 renewal is too short; > alterntate policy: as long as draft or version is > alive, expire in 3 to 6 months > - Alex: that suggestion ties validity with ability of author > to submit the draft; suggestion: once document is > submitted to IESG then we freeze. Don't want to > allocate codepoints too early. > - Dave Meyer: Are you sure that IANA can time anything out > - Alex: No Change to: No, that's why the drafts asks the WG chairs to keep track of the timers. > - Dave Meyer: WG chair needs to manage this? I think Dave asked if the WG chairs will need to maintain their own, parallel registry to maintain this. Alex: if IANA registry includes all info necessary, such as time of allocation, responsible WG, etc., then it should be a matter of periodically looking through the IANA registries. > - What happens if the allocation is not renewed and > code is using it still? > - Alex: Add provision to document to deprecate but not return Change to: the document allows to deprecate, but not return > - Kireeti: Deprecate for a period of time to give people time > to remove. Formal process to do early allocations > and if it goes through then stick with it but if it > doesn't go through then people must take this out. > - Dino: Allocate experimental codepoints and once > standardised, then adopt standard codepoint for > sending but accept both. > - Sue: Good for SAFIs as well as AFIs? > - Dino: All well known IANA values > - Fenner: RFC already documents a process for transitioning > codepoints Thanks. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 9 18:19:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06538 for ; Tue, 9 Mar 2004 18:19:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0qV6-0001WO-Gc for idr-archive@odin.ietf.org; Tue, 09 Mar 2004 18:19:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29NJ4hV005842 for idr-archive@odin.ietf.org; Tue, 9 Mar 2004 18:19:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0qV6-0001W9-BW for idr-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 18:19:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06498 for ; Tue, 9 Mar 2004 18:18:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0qV3-0000d3-00 for idr-web-archive@ietf.org; Tue, 09 Mar 2004 18:19:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0qU7-0000Tq-00 for idr-web-archive@ietf.org; Tue, 09 Mar 2004 18:18:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0qTg-0000KN-00; Tue, 09 Mar 2004 18:17:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0qT7-0000y1-LN; Tue, 09 Mar 2004 18:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0qSN-0000nK-1i for idr@optimus.ietf.org; Tue, 09 Mar 2004 18:16:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06217 for ; Tue, 9 Mar 2004 18:16:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0qSK-0000At-00 for idr@ietf.org; Tue, 09 Mar 2004 18:16:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0qRK-00000m-00 for idr@ietf.org; Tue, 09 Mar 2004 18:15:11 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B0qQR-0007ex-00 for idr@ietf.org; Tue, 09 Mar 2004 18:14:15 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0qQR-0008Wb-RW; Tue, 09 Mar 2004 23:14:15 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <22240253766.20040309151326@psg.com> To: "Susan Hares" CC: idr@ietf.org Subject: Re: [Idr] FW: IDR minutes In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Mar 2004 15:13:26 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sue- Some corrections below, please. Monday, March 1, 2004, 7:40:23 PM, Susan Hares wrote: [...] > 4) BGP Peer Restart Backoff Mechanisms [10 minutes] > document: draft-hares-bgp-backoff-01.txt (ietf) (-02 Update) > Author: Susan Hares > Presentation Sue Hares > - Alex: draft should say informational Change to "the draft says it's an RFC, shouldn't do that" > achieve functionality using existing states? > - Sue: no... can't use existing states; already > investigated that option > 5) Deterministic Route Redistribution into BGP [10 minutes] > document: draft-chen-bgp-redist-00.txt > Authors: Jenny Yuan, Enke Chen > Enke Chen > - Andrew Lang: used to use configured localpref tweaking; not > management intensive... unsure if this is needed > - Enke: timing dependent non-deterministic problem so > current knobs cannot be used reliably; does not > break anything... backwards compatible > - Andrew Lang: better to educate people about localpref > - Barry Friedman: lacks generality too narrow a problem > space... only addresses RIP/iBGP interaction > - Enke: tweaking of admin distance defines a baseline > - need per route granularity to solve for all cases? > Possibility of adding more configuration conflicts. > - Alex: this problem only occurs if there's a consistancy > issue between two places... May not be an issue for > a single selection point. Change to: the problem occurs if a router has to select best routes in two places: as in the draft--once in BGP and once in the routing table, and the decisions are not consistent. wonder if the problem still exists if an implementation selects best paths in one place only, e.g. gated?. if so, is the problem implementation-specific, not to mean it shouldn't resolved. Alex sent an e-mail to the list with more details. > 8) BGP Attribute Codes and Suggested Procedures > Document: draft-kompella-zinin-early-allocation-00.txt > Author: Alex Zinin, Kireeti Kompella > Presentation Alex Zinin > - Sharon: talking about protocols and not OIDs preallocation? > bad to preallocate in the MIB... different from what > other WGs; exclude MIB OIDs > - Kireeti: not suggesting that everyone use this > - It would have been nicer to have had OIDs > preallocated so as not to reimpliment the MIB > - Sharon: OIDs not allocated to drafts because if the drafts > goes away then you've wasted numbers > - Lou Berger: allocation with 1 year with 1 renewal is too short; > alterntate policy: as long as draft or version is > alive, expire in 3 to 6 months > - Alex: that suggestion ties validity with ability of author > to submit the draft; suggestion: once document is > submitted to IESG then we freeze. Don't want to > allocate codepoints too early. > - Dave Meyer: Are you sure that IANA can time anything out > - Alex: No Change to: No, that's why the drafts asks the WG chairs to keep track of the timers. > - Dave Meyer: WG chair needs to manage this? I think Dave asked if the WG chairs will need to maintain their own, parallel registry to maintain this. Alex: if IANA registry includes all info necessary, such as time of allocation, responsible WG, etc., then it should be a matter of periodically looking through the IANA registries. > - What happens if the allocation is not renewed and > code is using it still? > - Alex: Add provision to document to deprecate but not return Change to: the document allows to deprecate, but not return > - Kireeti: Deprecate for a period of time to give people time > to remove. Formal process to do early allocations > and if it goes through then stick with it but if it > doesn't go through then people must take this out. > - Dino: Allocate experimental codepoints and once > standardised, then adopt standard codepoint for > sending but accept both. > - Sue: Good for SAFIs as well as AFIs? > - Dino: All well known IANA values > - Fenner: RFC already documents a process for transitioning > codepoints Thanks. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 9 18:50:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07751 for ; Tue, 9 Mar 2004 18:50:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0qz6-0005vH-00 for idr-archive@ietf.org; Tue, 09 Mar 2004 18:50:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0qyE-0005kj-00 for idr-archive@ietf.org; Tue, 09 Mar 2004 18:49:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0qxC-0005a9-00; Tue, 09 Mar 2004 18:48:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0qx7-0003Mj-NR; Tue, 09 Mar 2004 18:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0qwQ-0003Ku-VZ for idr@optimus.ietf.org; Tue, 09 Mar 2004 18:47:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07593 for ; Tue, 9 Mar 2004 18:47:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0qwN-0005Ph-00 for idr@ietf.org; Tue, 09 Mar 2004 18:47:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0qvf-0005Ee-00 for idr@ietf.org; Tue, 09 Mar 2004 18:46:32 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B0quf-00052g-00 for idr@ietf.org; Tue, 09 Mar 2004 18:45:29 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0qua-000Glc-Dc; Tue, 09 Mar 2004 23:45:24 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <124242121131.20040309154433@psg.com> To: "Wijnen, Bert (Bert)" CC: Sharon Chisholm , idr@ietf.org Subject: Re: [Idr] Experimental code-points In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15503B64AB9@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15503B64AB9@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Mar 2004 15:44:33 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Bert, Seems that the text already has it: > a) The code points must be from a space designated as "Standards > Action", amended by IESG approval to permit Early Allocation. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Does it do the job? -- Alex http://www.psg.com/~zinin/ Saturday, March 6, 2004, 5:01:34 AM, Wijnen, Bert (Bert) wrote: > Aha ... good. For me that Covers it. > But... it might be good to add that "IESG approval" > into the list of "conditions" in sect 2 as well. > I bet people will often skip the intro and go straight to > the "what are the conditions" section to see if they can > request an early registration. > Thanks, > Bert >> -----Original Message----- >> From: Alex Zinin [mailto:zinin@psg.com] >> Sent: woensdag 3 maart 2004 21:55 >> To: Wijnen, Bert (Bert) >> Cc: Sharon Chisholm; idr@ietf.org >> Subject: Re: [Idr] Experimental code-points >> >> >> Bert, Sharon- >> >> The doc says: >> >> > This memo only addresses the early allocation of code points from >> > spaces whose allocation policy is "Standards Action" >> [2434] AND have >> > been amended to permit early allocation. This permission must be >> > granted by the IESG, and code spaces with permission for early >> > allocation must be marked as such in the IANA registry. >> >> In other words, it doesn't apply to an existing registry >> unless IESG approves >> that this process is applicable. This leaves existing >> registries, OID included, >> intact unless someone takes an action. >> >> Is this good enough? >> >> -- >> Alex >> http://www.psg.com/~zinin/ >> >> Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote: >> > Good point. They can get an OID assigned in the >> experimental branch though. >> >> >> > Thanks, >> > Bert >> >> > -----Original Message----- >> > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] >> > Sent: dinsdag 2 maart 2004 9:30 >> > To: idr@ietf.org >> > Cc: Wijnen, Bert (Bert) >> > Subject: RE: [Idr] Experimental code-points >> >> >> >> > hi >> >> > In looking through >> > > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt >> I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated. >> In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. >> 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' >> Sharon >> -----Original Message----- >> From: Alex Zinin [ mailto:zinin@psg.com ] >> Sent: Monday, March 01, 2004 3:11 AM >> To: idr@ietf.org >> Subject: [Idr] Experimental code-points >> As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 9 18:50:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07814 for ; Tue, 9 Mar 2004 18:50:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0qzB-0003Xf-1u for idr-archive@odin.ietf.org; Tue, 09 Mar 2004 18:50:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29No9Uw013615 for idr-archive@odin.ietf.org; Tue, 9 Mar 2004 18:50:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0qzA-0003XW-CX for idr-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 18:50:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07768 for ; Tue, 9 Mar 2004 18:50:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0qz7-0005vM-00 for idr-web-archive@ietf.org; Tue, 09 Mar 2004 18:50:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0qyE-0005kq-00 for idr-web-archive@ietf.org; Tue, 09 Mar 2004 18:49:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0qxC-0005a9-00; Tue, 09 Mar 2004 18:48:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0qx7-0003Mj-NR; Tue, 09 Mar 2004 18:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0qwQ-0003Ku-VZ for idr@optimus.ietf.org; Tue, 09 Mar 2004 18:47:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07593 for ; Tue, 9 Mar 2004 18:47:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0qwN-0005Ph-00 for idr@ietf.org; Tue, 09 Mar 2004 18:47:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0qvf-0005Ee-00 for idr@ietf.org; Tue, 09 Mar 2004 18:46:32 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B0quf-00052g-00 for idr@ietf.org; Tue, 09 Mar 2004 18:45:29 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0qua-000Glc-Dc; Tue, 09 Mar 2004 23:45:24 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <124242121131.20040309154433@psg.com> To: "Wijnen, Bert (Bert)" CC: Sharon Chisholm , idr@ietf.org Subject: Re: [Idr] Experimental code-points In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15503B64AB9@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15503B64AB9@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Mar 2004 15:44:33 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Bert, Seems that the text already has it: > a) The code points must be from a space designated as "Standards > Action", amended by IESG approval to permit Early Allocation. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Does it do the job? -- Alex http://www.psg.com/~zinin/ Saturday, March 6, 2004, 5:01:34 AM, Wijnen, Bert (Bert) wrote: > Aha ... good. For me that Covers it. > But... it might be good to add that "IESG approval" > into the list of "conditions" in sect 2 as well. > I bet people will often skip the intro and go straight to > the "what are the conditions" section to see if they can > request an early registration. > Thanks, > Bert >> -----Original Message----- >> From: Alex Zinin [mailto:zinin@psg.com] >> Sent: woensdag 3 maart 2004 21:55 >> To: Wijnen, Bert (Bert) >> Cc: Sharon Chisholm; idr@ietf.org >> Subject: Re: [Idr] Experimental code-points >> >> >> Bert, Sharon- >> >> The doc says: >> >> > This memo only addresses the early allocation of code points from >> > spaces whose allocation policy is "Standards Action" >> [2434] AND have >> > been amended to permit early allocation. This permission must be >> > granted by the IESG, and code spaces with permission for early >> > allocation must be marked as such in the IANA registry. >> >> In other words, it doesn't apply to an existing registry >> unless IESG approves >> that this process is applicable. This leaves existing >> registries, OID included, >> intact unless someone takes an action. >> >> Is this good enough? >> >> -- >> Alex >> http://www.psg.com/~zinin/ >> >> Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote: >> > Good point. They can get an OID assigned in the >> experimental branch though. >> >> >> > Thanks, >> > Bert >> >> > -----Original Message----- >> > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] >> > Sent: dinsdag 2 maart 2004 9:30 >> > To: idr@ietf.org >> > Cc: Wijnen, Bert (Bert) >> > Subject: RE: [Idr] Experimental code-points >> >> >> >> > hi >> >> > In looking through >> > > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt >> I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated. >> In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. >> 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' >> Sharon >> -----Original Message----- >> From: Alex Zinin [ mailto:zinin@psg.com ] >> Sent: Monday, March 01, 2004 3:11 AM >> To: idr@ietf.org >> Subject: [Idr] Experimental code-points >> As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Mar 10 02:08:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03211 for ; Wed, 10 Mar 2004 02:08:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0xpA-0000E7-00 for idr-archive@ietf.org; Wed, 10 Mar 2004 02:08:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0xoH-00002F-00 for idr-archive@ietf.org; Wed, 10 Mar 2004 02:07:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0xnO-0007ey-00; Wed, 10 Mar 2004 02:06:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0xn1-0005l4-54; Wed, 10 Mar 2004 02:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0xmO-0005RU-Nv for idr@optimus.ietf.org; Wed, 10 Mar 2004 02:05:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29771 for ; Wed, 10 Mar 2004 02:05:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0xmL-0007TK-00 for idr@ietf.org; Wed, 10 Mar 2004 02:05:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0xlb-0007II-00 for idr@ietf.org; Wed, 10 Mar 2004 02:04:36 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B0xkZ-00073y-00 for idr@ietf.org; Wed, 10 Mar 2004 02:03:32 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0xkW-000GP3-4c; Wed, 10 Mar 2004 07:03:28 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <127268419917.20040309230252@psg.com> To: "Wijnen, Bert (Bert)" CC: Sharon Chisholm , idr@ietf.org Subject: Re: [Idr] Experimental code-points In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15503C9CF57@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15503C9CF57@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Mar 2004 23:02:52 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit OK. Sharon, would this work for you? -- Alex http://www.psg.com/~zinin/ Tuesday, March 9, 2004, 6:54:03 PM, Wijnen, Bert (Bert) wrote: > Yes.... I wonder why I did not see that ?? > Maybve I was too tired at end of IETF week. > Thanks, > Bert >> -----Original Message----- >> From: Alex Zinin [mailto:zinin@psg.com] >> Sent: woensdag 10 maart 2004 7:45 >> To: Wijnen, Bert (Bert) >> Cc: Sharon Chisholm; idr@ietf.org >> Subject: Re: [Idr] Experimental code-points >> >> >> Bert, >> >> Seems that the text already has it: >> >> > a) The code points must be from a space designated as "Standards >> > Action", amended by IESG approval to permit Early Allocation. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> Does it do the job? >> >> -- >> Alex >> http://www.psg.com/~zinin/ >> >> Saturday, March 6, 2004, 5:01:34 AM, Wijnen, Bert (Bert) wrote: >> > Aha ... good. For me that Covers it. >> > But... it might be good to add that "IESG approval" >> > into the list of "conditions" in sect 2 as well. >> > I bet people will often skip the intro and go straight to >> > the "what are the conditions" section to see if they can >> > request an early registration. >> >> > Thanks, >> > Bert >> >> >> -----Original Message----- >> >> From: Alex Zinin [mailto:zinin@psg.com] >> >> Sent: woensdag 3 maart 2004 21:55 >> >> To: Wijnen, Bert (Bert) >> >> Cc: Sharon Chisholm; idr@ietf.org >> >> Subject: Re: [Idr] Experimental code-points >> >> >> >> >> >> Bert, Sharon- >> >> >> >> The doc says: >> >> >> >> > This memo only addresses the early allocation of code >> points from >> >> > spaces whose allocation policy is "Standards Action" >> >> [2434] AND have >> >> > been amended to permit early allocation. This >> permission must be >> >> > granted by the IESG, and code spaces with permission for early >> >> > allocation must be marked as such in the IANA registry. >> >> >> >> In other words, it doesn't apply to an existing registry >> >> unless IESG approves >> >> that this process is applicable. This leaves existing >> >> registries, OID included, >> >> intact unless someone takes an action. >> >> >> >> Is this good enough? >> >> >> >> -- >> >> Alex >> >> http://www.psg.com/~zinin/ >> >> >> >> Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote: >> >> > Good point. They can get an OID assigned in the >> >> experimental branch though. >> >> >> >> >> >> > Thanks, >> >> > Bert >> >> >> >> > -----Original Message----- >> >> > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] >> >> > Sent: dinsdag 2 maart 2004 9:30 >> >> > To: idr@ietf.org >> >> > Cc: Wijnen, Bert (Bert) >> >> > Subject: RE: [Idr] Experimental code-points >> >> >> >> >> >> >> >> > hi >> >> >> >> > In looking through >> >> > >> > > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt >>> I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated. >>> In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. >>> 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' >>> Sharon >>> -----Original Message----- >>> From: Alex Zinin [ mailto:zinin@psg.com ] >>> Sent: Monday, March 01, 2004 3:11 AM >>> To: idr@ietf.org >>> Subject: [Idr] Experimental code-points >>> As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Mar 10 02:08:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03918 for ; Wed, 10 Mar 2004 02:08:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0xpH-00070g-Er for idr-archive@odin.ietf.org; Wed, 10 Mar 2004 02:08:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A78NUL026929 for idr-archive@odin.ietf.org; Wed, 10 Mar 2004 02:08:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0xpG-0006zz-4w for idr-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 02:08:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03256 for ; Wed, 10 Mar 2004 02:08:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0xpC-0000EK-00 for idr-web-archive@ietf.org; Wed, 10 Mar 2004 02:08:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0xoI-00002N-00 for idr-web-archive@ietf.org; Wed, 10 Mar 2004 02:07:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0xnO-0007ey-00; Wed, 10 Mar 2004 02:06:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0xn1-0005l4-54; Wed, 10 Mar 2004 02:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0xmO-0005RU-Nv for idr@optimus.ietf.org; Wed, 10 Mar 2004 02:05:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29771 for ; Wed, 10 Mar 2004 02:05:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0xmL-0007TK-00 for idr@ietf.org; Wed, 10 Mar 2004 02:05:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0xlb-0007II-00 for idr@ietf.org; Wed, 10 Mar 2004 02:04:36 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B0xkZ-00073y-00 for idr@ietf.org; Wed, 10 Mar 2004 02:03:32 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0xkW-000GP3-4c; Wed, 10 Mar 2004 07:03:28 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <127268419917.20040309230252@psg.com> To: "Wijnen, Bert (Bert)" CC: Sharon Chisholm , idr@ietf.org Subject: Re: [Idr] Experimental code-points In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15503C9CF57@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15503C9CF57@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Mar 2004 23:02:52 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit OK. Sharon, would this work for you? -- Alex http://www.psg.com/~zinin/ Tuesday, March 9, 2004, 6:54:03 PM, Wijnen, Bert (Bert) wrote: > Yes.... I wonder why I did not see that ?? > Maybve I was too tired at end of IETF week. > Thanks, > Bert >> -----Original Message----- >> From: Alex Zinin [mailto:zinin@psg.com] >> Sent: woensdag 10 maart 2004 7:45 >> To: Wijnen, Bert (Bert) >> Cc: Sharon Chisholm; idr@ietf.org >> Subject: Re: [Idr] Experimental code-points >> >> >> Bert, >> >> Seems that the text already has it: >> >> > a) The code points must be from a space designated as "Standards >> > Action", amended by IESG approval to permit Early Allocation. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> Does it do the job? >> >> -- >> Alex >> http://www.psg.com/~zinin/ >> >> Saturday, March 6, 2004, 5:01:34 AM, Wijnen, Bert (Bert) wrote: >> > Aha ... good. For me that Covers it. >> > But... it might be good to add that "IESG approval" >> > into the list of "conditions" in sect 2 as well. >> > I bet people will often skip the intro and go straight to >> > the "what are the conditions" section to see if they can >> > request an early registration. >> >> > Thanks, >> > Bert >> >> >> -----Original Message----- >> >> From: Alex Zinin [mailto:zinin@psg.com] >> >> Sent: woensdag 3 maart 2004 21:55 >> >> To: Wijnen, Bert (Bert) >> >> Cc: Sharon Chisholm; idr@ietf.org >> >> Subject: Re: [Idr] Experimental code-points >> >> >> >> >> >> Bert, Sharon- >> >> >> >> The doc says: >> >> >> >> > This memo only addresses the early allocation of code >> points from >> >> > spaces whose allocation policy is "Standards Action" >> >> [2434] AND have >> >> > been amended to permit early allocation. This >> permission must be >> >> > granted by the IESG, and code spaces with permission for early >> >> > allocation must be marked as such in the IANA registry. >> >> >> >> In other words, it doesn't apply to an existing registry >> >> unless IESG approves >> >> that this process is applicable. This leaves existing >> >> registries, OID included, >> >> intact unless someone takes an action. >> >> >> >> Is this good enough? >> >> >> >> -- >> >> Alex >> >> http://www.psg.com/~zinin/ >> >> >> >> Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote: >> >> > Good point. They can get an OID assigned in the >> >> experimental branch though. >> >> >> >> >> >> > Thanks, >> >> > Bert >> >> >> >> > -----Original Message----- >> >> > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] >> >> > Sent: dinsdag 2 maart 2004 9:30 >> >> > To: idr@ietf.org >> >> > Cc: Wijnen, Bert (Bert) >> >> > Subject: RE: [Idr] Experimental code-points >> >> >> >> >> >> >> >> > hi >> >> >> >> > In looking through >> >> > >> > > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt >>> I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated. >>> In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. >>> 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' >>> Sharon >>> -----Original Message----- >>> From: Alex Zinin [ mailto:zinin@psg.com ] >>> Sent: Monday, March 01, 2004 3:11 AM >>> To: idr@ietf.org >>> Subject: [Idr] Experimental code-points >>> As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Wed Mar 10 15:31:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02270 for ; Wed, 10 Mar 2004 15:31:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1AMw-00039B-00 for idr-archive@ietf.org; Wed, 10 Mar 2004 15:31:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1AM2-00030G-00 for idr-archive@ietf.org; Wed, 10 Mar 2004 15:31:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1ALX-0002qh-00; Wed, 10 Mar 2004 15:30:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1AL4-0003Kw-Ns; Wed, 10 Mar 2004 15:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1AKA-0003GM-Nt for idr@optimus.ietf.org; Wed, 10 Mar 2004 15:29:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02124 for ; Wed, 10 Mar 2004 15:29:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1AK9-0002g8-00 for idr@ietf.org; Wed, 10 Mar 2004 15:29:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1AJI-0002Vz-00 for idr@ietf.org; Wed, 10 Mar 2004 15:28:13 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1B1AIi-0002JJ-00 for idr@ietf.org; Wed, 10 Mar 2004 15:27:36 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i2AKR4124828 for ; Wed, 10 Mar 2004 15:27:05 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Mar 2004 15:27:05 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A7435E8@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: idr@ietf.org Cc: "Wijnen, Bert (Bert)" Subject: RE: [Idr] Experimental code-points MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 15:27:02 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 hi I'd prefer something more explicit, but I guess I can live with the current text. Sharon -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Wednesday, March 10, 2004 2:03 AM To: Wijnen, Bert (Bert) Cc: Chisholm, Sharon [CAR:0S00:EXCH]; idr@ietf.org Subject: Re: [Idr] Experimental code-points OK. Sharon, would this work for you? -- Alex http://www.psg.com/~zinin/ Tuesday, March 9, 2004, 6:54:03 PM, Wijnen, Bert (Bert) wrote: > Yes.... I wonder why I did not see that ?? > Maybve I was too tired at end of IETF week. > Thanks, > Bert >> -----Original Message----- >> From: Alex Zinin [mailto:zinin@psg.com] >> Sent: woensdag 10 maart 2004 7:45 >> To: Wijnen, Bert (Bert) >> Cc: Sharon Chisholm; idr@ietf.org >> Subject: Re: [Idr] Experimental code-points >> >> >> Bert, >> >> Seems that the text already has it: >> >> > a) The code points must be from a space designated as "Standards >> > Action", amended by IESG approval to permit Early Allocation. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> Does it do the job? >> >> -- >> Alex >> http://www.psg.com/~zinin/ >> >> Saturday, March 6, 2004, 5:01:34 AM, Wijnen, Bert (Bert) wrote: >> > Aha ... good. For me that Covers it. >> > But... it might be good to add that "IESG approval" >> > into the list of "conditions" in sect 2 as well. >> > I bet people will often skip the intro and go straight to >> > the "what are the conditions" section to see if they can >> > request an early registration. >> >> > Thanks, >> > Bert >> >> >> -----Original Message----- >> >> From: Alex Zinin [mailto:zinin@psg.com] >> >> Sent: woensdag 3 maart 2004 21:55 >> >> To: Wijnen, Bert (Bert) >> >> Cc: Sharon Chisholm; idr@ietf.org >> >> Subject: Re: [Idr] Experimental code-points >> >> >> >> >> >> Bert, Sharon- >> >> >> >> The doc says: >> >> >> >> > This memo only addresses the early allocation of code >> points from >> >> > spaces whose allocation policy is "Standards Action" >> >> [2434] AND have >> >> > been amended to permit early allocation. This >> permission must be >> >> > granted by the IESG, and code spaces with permission for early >> >> > allocation must be marked as such in the IANA registry. >> >> >> >> In other words, it doesn't apply to an existing registry >> >> unless IESG approves >> >> that this process is applicable. This leaves existing >> >> registries, OID included, >> >> intact unless someone takes an action. >> >> >> >> Is this good enough? >> >> >> >> -- >> >> Alex >> >> http://www.psg.com/~zinin/ >> >> >> >> Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote: >> >> > Good point. They can get an OID assigned in the >> >> experimental branch though. >> >> >> >> >> >> > Thanks, >> >> > Bert >> >> >> >> > -----Original Message----- >> >> > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] >> >> > Sent: dinsdag 2 maart 2004 9:30 >> >> > To: idr@ietf.org >> >> > Cc: Wijnen, Bert (Bert) >> >> > Subject: RE: [Idr] Experimental code-points >> >> >> >> >> >> >> >> > hi >> >> >> >> > In looking through >> >> > >> > > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocat > ion-00.txt > tion-00.txt> >>> I would suggest the following change to address my concern that it >>> inappropriately sets the expectation that MIB OIDs will be >>> pre-allocated. >>> In either the 'Introduction' or in the section 'Conditions for Early >>> Allocation' the following text needs to be added. >>> 'Note that under no condition will MIB Object Identifiers (OIDs) be >>> allocated before the RFC is published.' >>> Sharon >>> -----Original Message----- >>> From: Alex Zinin [ mailto:zinin@psg.com ] >>> Sent: Monday, March 01, 2004 3:11 AM >>> To: idr@ietf.org >>> Subject: [Idr] Experimental code-points >>> As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Wed Mar 10 15:32:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02292 for ; Wed, 10 Mar 2004 15:32:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1AMz-0003cM-K3 for idr-archive@odin.ietf.org; Wed, 10 Mar 2004 15:32:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AKW1Pj013904 for idr-archive@odin.ietf.org; Wed, 10 Mar 2004 15:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1AMz-0003bv-29 for idr-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 15:32:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02282 for ; Wed, 10 Mar 2004 15:31:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1AMx-00039G-00 for idr-web-archive@ietf.org; Wed, 10 Mar 2004 15:31:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1AM3-00030N-00 for idr-web-archive@ietf.org; Wed, 10 Mar 2004 15:31:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1ALX-0002qh-00; Wed, 10 Mar 2004 15:30:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1AL4-0003Kw-Ns; Wed, 10 Mar 2004 15:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1AKA-0003GM-Nt for idr@optimus.ietf.org; Wed, 10 Mar 2004 15:29:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02124 for ; Wed, 10 Mar 2004 15:29:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1AK9-0002g8-00 for idr@ietf.org; Wed, 10 Mar 2004 15:29:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1AJI-0002Vz-00 for idr@ietf.org; Wed, 10 Mar 2004 15:28:13 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1B1AIi-0002JJ-00 for idr@ietf.org; Wed, 10 Mar 2004 15:27:36 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i2AKR4124828 for ; Wed, 10 Mar 2004 15:27:05 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Mar 2004 15:27:05 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A7435E8@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: idr@ietf.org Cc: "Wijnen, Bert (Bert)" Subject: RE: [Idr] Experimental code-points MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 15:27:02 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 hi I'd prefer something more explicit, but I guess I can live with the current text. Sharon -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Wednesday, March 10, 2004 2:03 AM To: Wijnen, Bert (Bert) Cc: Chisholm, Sharon [CAR:0S00:EXCH]; idr@ietf.org Subject: Re: [Idr] Experimental code-points OK. Sharon, would this work for you? -- Alex http://www.psg.com/~zinin/ Tuesday, March 9, 2004, 6:54:03 PM, Wijnen, Bert (Bert) wrote: > Yes.... I wonder why I did not see that ?? > Maybve I was too tired at end of IETF week. > Thanks, > Bert >> -----Original Message----- >> From: Alex Zinin [mailto:zinin@psg.com] >> Sent: woensdag 10 maart 2004 7:45 >> To: Wijnen, Bert (Bert) >> Cc: Sharon Chisholm; idr@ietf.org >> Subject: Re: [Idr] Experimental code-points >> >> >> Bert, >> >> Seems that the text already has it: >> >> > a) The code points must be from a space designated as "Standards >> > Action", amended by IESG approval to permit Early Allocation. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> Does it do the job? >> >> -- >> Alex >> http://www.psg.com/~zinin/ >> >> Saturday, March 6, 2004, 5:01:34 AM, Wijnen, Bert (Bert) wrote: >> > Aha ... good. For me that Covers it. >> > But... it might be good to add that "IESG approval" >> > into the list of "conditions" in sect 2 as well. >> > I bet people will often skip the intro and go straight to >> > the "what are the conditions" section to see if they can >> > request an early registration. >> >> > Thanks, >> > Bert >> >> >> -----Original Message----- >> >> From: Alex Zinin [mailto:zinin@psg.com] >> >> Sent: woensdag 3 maart 2004 21:55 >> >> To: Wijnen, Bert (Bert) >> >> Cc: Sharon Chisholm; idr@ietf.org >> >> Subject: Re: [Idr] Experimental code-points >> >> >> >> >> >> Bert, Sharon- >> >> >> >> The doc says: >> >> >> >> > This memo only addresses the early allocation of code >> points from >> >> > spaces whose allocation policy is "Standards Action" >> >> [2434] AND have >> >> > been amended to permit early allocation. This >> permission must be >> >> > granted by the IESG, and code spaces with permission for early >> >> > allocation must be marked as such in the IANA registry. >> >> >> >> In other words, it doesn't apply to an existing registry >> >> unless IESG approves >> >> that this process is applicable. This leaves existing >> >> registries, OID included, >> >> intact unless someone takes an action. >> >> >> >> Is this good enough? >> >> >> >> -- >> >> Alex >> >> http://www.psg.com/~zinin/ >> >> >> >> Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote: >> >> > Good point. They can get an OID assigned in the >> >> experimental branch though. >> >> >> >> >> >> > Thanks, >> >> > Bert >> >> >> >> > -----Original Message----- >> >> > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] >> >> > Sent: dinsdag 2 maart 2004 9:30 >> >> > To: idr@ietf.org >> >> > Cc: Wijnen, Bert (Bert) >> >> > Subject: RE: [Idr] Experimental code-points >> >> >> >> >> >> >> >> > hi >> >> >> >> > In looking through >> >> > >> > > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocat > ion-00.txt > tion-00.txt> >>> I would suggest the following change to address my concern that it >>> inappropriately sets the expectation that MIB OIDs will be >>> pre-allocated. >>> In either the 'Introduction' or in the section 'Conditions for Early >>> Allocation' the following text needs to be added. >>> 'Note that under no condition will MIB Object Identifiers (OIDs) be >>> allocated before the RFC is published.' >>> Sharon >>> -----Original Message----- >>> From: Alex Zinin [ mailto:zinin@psg.com ] >>> Sent: Monday, March 01, 2004 3:11 AM >>> To: idr@ietf.org >>> Subject: [Idr] Experimental code-points >>> As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Mar 11 05:28:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23924 for ; Thu, 11 Mar 2004 05:28:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1NQS-0003py-00 for idr-archive@ietf.org; Thu, 11 Mar 2004 05:28:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1NPS-0003ds-00 for idr-archive@ietf.org; Thu, 11 Mar 2004 05:27:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1NOU-0003T7-00; Thu, 11 Mar 2004 05:26:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1NO9-0007gk-Cx; Thu, 11 Mar 2004 05:26:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1AWk-0004l7-53 for idr@optimus.ietf.org; Wed, 10 Mar 2004 15:42:06 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03167; Wed, 10 Mar 2004 15:42:04 -0500 (EST) Message-Id: <200403102042.PAA03167@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-route-filter-10.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 15:42:03 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Cooperative Route Filtering Capability for BGP-4 Author(s) : E. Chen, Y. Rekhter Filename : draft-ietf-idr-route-filter-10.txt Pages : 11 Date : 2004-3-10 This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of route filters that the peer would use to constrain/filter its outbound routing updates to the speaker. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-route-filter-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-route-filter-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-10150457.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-route-filter-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-route-filter-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-10150457.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Mar 11 05:28:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23985 for ; Thu, 11 Mar 2004 05:28:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1NQW-0007xq-MB for idr-archive@odin.ietf.org; Thu, 11 Mar 2004 05:28:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BASWaA030613 for idr-archive@odin.ietf.org; Thu, 11 Mar 2004 05:28:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1NQW-0007xg-Bk for idr-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 05:28:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23942 for ; Thu, 11 Mar 2004 05:28:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1NQS-0003q3-00 for idr-web-archive@ietf.org; Thu, 11 Mar 2004 05:28:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1NPS-0003dz-00 for idr-web-archive@ietf.org; Thu, 11 Mar 2004 05:27:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1NOU-0003T7-00; Thu, 11 Mar 2004 05:26:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1NO9-0007gk-Cx; Thu, 11 Mar 2004 05:26:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1AWk-0004l7-53 for idr@optimus.ietf.org; Wed, 10 Mar 2004 15:42:06 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03167; Wed, 10 Mar 2004 15:42:04 -0500 (EST) Message-Id: <200403102042.PAA03167@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-route-filter-10.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 15:42:03 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Cooperative Route Filtering Capability for BGP-4 Author(s) : E. Chen, Y. Rekhter Filename : draft-ietf-idr-route-filter-10.txt Pages : 11 Date : 2004-3-10 This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of route filters that the peer would use to constrain/filter its outbound routing updates to the speaker. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-route-filter-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-route-filter-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-10150457.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-route-filter-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-route-filter-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-10150457.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Mar 12 03:51:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08816 for ; Fri, 12 Mar 2004 03:51:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1iNw-0005BI-00 for idr-archive@ietf.org; Fri, 12 Mar 2004 03:51:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1iN2-00052M-00 for idr-archive@ietf.org; Fri, 12 Mar 2004 03:50:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1iMC-0004uA-00; Fri, 12 Mar 2004 03:49:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1iLo-0003uW-4K; Fri, 12 Mar 2004 03:49:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1WeO-0002Ac-SI for idr@optimus.ietf.org; Thu, 11 Mar 2004 15:19:28 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20077; Thu, 11 Mar 2004 15:19:26 -0500 (EST) Message-Id: <200403112019.PAA20077@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-implementation-00.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Mar 2004 15:19:26 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP 4 Implementation Report Author(s) : S. Hares Filename : draft-ietf-idr-bgp-implementation-00.txt Pages : 81 Date : 2004-3-11 This document provides a survey of the BGP-4 implementation draft- ietf-idr-bgp4-23.txt. After a brief summary, each response is listed. The editor makes no claim as to the accuracy of the information provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-implementation-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-implementation-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-implementation-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-11142831.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-implementation-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-implementation-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-11142831.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Mar 12 03:51:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08901 for ; Fri, 12 Mar 2004 03:51:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1iO1-0004QR-F1 for idr-archive@odin.ietf.org; Fri, 12 Mar 2004 03:51:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C8pLuC017005 for idr-archive@odin.ietf.org; Fri, 12 Mar 2004 03:51:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1iO0-0004QC-K5 for idr-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 03:51:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08836 for ; Fri, 12 Mar 2004 03:51:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1iNy-0005BV-00 for idr-web-archive@ietf.org; Fri, 12 Mar 2004 03:51:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1iN3-00052T-00 for idr-web-archive@ietf.org; Fri, 12 Mar 2004 03:50:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1iMC-0004uA-00; Fri, 12 Mar 2004 03:49:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1iLo-0003uW-4K; Fri, 12 Mar 2004 03:49:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1WeO-0002Ac-SI for idr@optimus.ietf.org; Thu, 11 Mar 2004 15:19:28 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20077; Thu, 11 Mar 2004 15:19:26 -0500 (EST) Message-Id: <200403112019.PAA20077@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-implementation-00.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Mar 2004 15:19:26 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP 4 Implementation Report Author(s) : S. Hares Filename : draft-ietf-idr-bgp-implementation-00.txt Pages : 81 Date : 2004-3-11 This document provides a survey of the BGP-4 implementation draft- ietf-idr-bgp4-23.txt. After a brief summary, each response is listed. The editor makes no claim as to the accuracy of the information provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-implementation-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-implementation-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-implementation-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-11142831.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-implementation-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-implementation-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-11142831.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Mar 12 04:17:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09738 for ; Fri, 12 Mar 2004 04:17:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1inC-0000iO-00 for idr-archive@ietf.org; Fri, 12 Mar 2004 04:17:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1imJ-0000bO-00 for idr-archive@ietf.org; Fri, 12 Mar 2004 04:16:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1ilz-0000Tu-00; Fri, 12 Mar 2004 04:16:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ilu-0005gF-Qb; Fri, 12 Mar 2004 04:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ilL-0005ey-C1 for idr@optimus.ietf.org; Fri, 12 Mar 2004 04:15:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09633 for ; Fri, 12 Mar 2004 04:15:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1ilI-0000Sb-00 for idr@ietf.org; Fri, 12 Mar 2004 04:15:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1ikL-0000KJ-00 for idr@ietf.org; Fri, 12 Mar 2004 04:14:26 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1ijw-0000Bk-00 for idr@ietf.org; Fri, 12 Mar 2004 04:14:00 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2C9DVJ02659 for ; Fri, 12 Mar 2004 11:13:31 +0200 From: Pekka Savola To: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <200403021542.i22Fg3kL083856@workhorse.fictitious.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 11:13:31 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hello, it's me again :).. Now that the on-list thread has apparently died, and the off-list discussions as well, I think it would be important to understand how to move forward, and to try to gauge whether everyone is aware of which issue we're talking about. As there was a lot of confusion at first on the actual problem, I won't try to summarize the thread, because at different times, people probably had entirely different assumptions of the problem. The bottom line is this: in very many cases you cannot avoid having to insert some some kind of discard/reject or null0 route for a specific prefix on a router (e.g., to generate a default route to some peers). When the next-hop of some other router, on that *same* router, goes through that "discard" route, the next-hop is still considered valid. This causes rather obvious BGP timeout problems. The non-problem is when you have to redistribute that discard route in your routing system, whether in IGP or BGP, and the other routers cannot tell that's it's a discard route as it's learned through a routing protocol. This can be rather easily avoided by configuring the discard routes everywhere, so I don't think this needs to be solved at this point. Now.. what do people think about this problem -- what should we do (pick one or multiple): 1) try to specify some behaviour in the bgp spec to avoid this issue; for example: 1.a) state that if the route towards the next-hop leads to packets being discarded by the router, SHOULD consider the next-hop ineligible 1.b) state that the implementation SHOULD support being able to configure which routes to use in in the next-hop eligibility detection process 1.c) to be worked out later.. 1.d) something else -- what? 2) defer the solution until later 3) clarify the operational problem, to make the reader/implementer aware of it 3.a) in this revision of bgp spec 3.b) in some other documents(s) 4) other -- what ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Mar 12 04:17:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09761 for ; Fri, 12 Mar 2004 04:17:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1inH-0005pQ-UK for idr-archive@odin.ietf.org; Fri, 12 Mar 2004 04:17:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C9HRvX022402 for idr-archive@odin.ietf.org; Fri, 12 Mar 2004 04:17:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1inG-0005p6-41 for idr-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 04:17:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09756 for ; Fri, 12 Mar 2004 04:17:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1inD-0000iS-00 for idr-web-archive@ietf.org; Fri, 12 Mar 2004 04:17:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1imK-0000bV-00 for idr-web-archive@ietf.org; Fri, 12 Mar 2004 04:16:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1ilz-0000Tu-00; Fri, 12 Mar 2004 04:16:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ilu-0005gF-Qb; Fri, 12 Mar 2004 04:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ilL-0005ey-C1 for idr@optimus.ietf.org; Fri, 12 Mar 2004 04:15:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09633 for ; Fri, 12 Mar 2004 04:15:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1ilI-0000Sb-00 for idr@ietf.org; Fri, 12 Mar 2004 04:15:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1ikL-0000KJ-00 for idr@ietf.org; Fri, 12 Mar 2004 04:14:26 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1ijw-0000Bk-00 for idr@ietf.org; Fri, 12 Mar 2004 04:14:00 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2C9DVJ02659 for ; Fri, 12 Mar 2004 11:13:31 +0200 From: Pekka Savola To: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <200403021542.i22Fg3kL083856@workhorse.fictitious.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 11:13:31 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hello, it's me again :).. Now that the on-list thread has apparently died, and the off-list discussions as well, I think it would be important to understand how to move forward, and to try to gauge whether everyone is aware of which issue we're talking about. As there was a lot of confusion at first on the actual problem, I won't try to summarize the thread, because at different times, people probably had entirely different assumptions of the problem. The bottom line is this: in very many cases you cannot avoid having to insert some some kind of discard/reject or null0 route for a specific prefix on a router (e.g., to generate a default route to some peers). When the next-hop of some other router, on that *same* router, goes through that "discard" route, the next-hop is still considered valid. This causes rather obvious BGP timeout problems. The non-problem is when you have to redistribute that discard route in your routing system, whether in IGP or BGP, and the other routers cannot tell that's it's a discard route as it's learned through a routing protocol. This can be rather easily avoided by configuring the discard routes everywhere, so I don't think this needs to be solved at this point. Now.. what do people think about this problem -- what should we do (pick one or multiple): 1) try to specify some behaviour in the bgp spec to avoid this issue; for example: 1.a) state that if the route towards the next-hop leads to packets being discarded by the router, SHOULD consider the next-hop ineligible 1.b) state that the implementation SHOULD support being able to configure which routes to use in in the next-hop eligibility detection process 1.c) to be worked out later.. 1.d) something else -- what? 2) defer the solution until later 3) clarify the operational problem, to make the reader/implementer aware of it 3.a) in this revision of bgp spec 3.b) in some other documents(s) 4) other -- what ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Mar 12 04:54:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10943 for ; Fri, 12 Mar 2004 04:54:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jMt-0005BP-00 for idr-archive@ietf.org; Fri, 12 Mar 2004 04:54:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jLv-00053O-00 for idr-archive@ietf.org; Fri, 12 Mar 2004 04:53:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1jL9-0004wv-00; Fri, 12 Mar 2004 04:52:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jKm-0007Ni-0k; Fri, 12 Mar 2004 04:52:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jK5-0007NA-AM for idr@optimus.ietf.org; Fri, 12 Mar 2004 04:51:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10768 for ; Fri, 12 Mar 2004 04:51:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jK2-0004o4-00 for idr@ietf.org; Fri, 12 Mar 2004 04:51:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jJ4-0004g5-00 for idr@ietf.org; Fri, 12 Mar 2004 04:50:18 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B1jI9-0004RZ-00 for idr@ietf.org; Fri, 12 Mar 2004 04:49:22 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i2C9moWK004427; Fri, 12 Mar 2004 01:48:50 -0800 (PST) Received: from cisco.com (sjc-vpn4-372.cisco.com [10.21.81.116]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARC73878; Fri, 12 Mar 2004 01:48:48 -0800 (PST) Message-ID: <40518780.30702@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 01:48:48 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Pekka, > Now that the on-list thread has apparently died, and the off-list > discussions as well, I think it would be important to understand how > to move forward, and to try to gauge whether everyone is aware of > which issue we're talking about. The problem did not died but was solved. The solution was that this is implementation detail what next hops are used for route resolution as a matter of the protocol owner as well as what mask length is desired. It was also clearly concluded by a few that BGP spec is not the place to add this and that you may rather issue a standalone draft describing operational implications on discard next hops and possibly recommend to implementations some new functionality. > When the next-hop of some other router, on that *same* router, goes > through that "discard" route, the next-hop is still considered valid. > This causes rather obvious BGP timeout problems. Well I would say that this is rather not so obvious to have next hops for the routes causing any BGP timeouts. I have not see anyone opening a BGP session or configuring update src to a null0 route. I am not even sure what you are trying to say above. Cheers, R. > Pekka Savola wrote: > > Hello, it's me again :).. > > Now that the on-list thread has apparently died, and the off-list > discussions as well, I think it would be important to understand how > to move forward, and to try to gauge whether everyone is aware of > which issue we're talking about. > > As there was a lot of confusion at first on the actual problem, I > won't try to summarize the thread, because at different times, people > probably had entirely different assumptions of the problem. > > The bottom line is this: in very many cases you cannot avoid having to > insert some some kind of discard/reject or null0 route for a specific > prefix on a router (e.g., to generate a default route to some peers). > When the next-hop of some other router, on that *same* router, goes > through that "discard" route, the next-hop is still considered valid. > This causes rather obvious BGP timeout problems. > > The non-problem is when you have to redistribute that discard route in > your routing system, whether in IGP or BGP, and the other routers > cannot tell that's it's a discard route as it's learned through a > routing protocol. This can be rather easily avoided by configuring > the discard routes everywhere, so I don't think this needs to be > solved at this point. > > Now.. what do people think about this problem -- what should we do > (pick one or multiple): > > 1) try to specify some behaviour in the bgp spec to avoid this issue; > for example: > 1.a) state that if the route towards the next-hop leads to packets > being discarded by the router, SHOULD consider the next-hop ineligible > 1.b) state that the implementation SHOULD support being able to > configure which routes to use in in the next-hop eligibility detection > process > 1.c) to be worked out later.. > 1.d) something else -- what? > > 2) defer the solution until later > > 3) clarify the operational problem, to make the reader/implementer > aware of it > 3.a) in this revision of bgp spec > 3.b) in some other documents(s) > > 4) other -- what ? > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Mar 12 04:54:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10989 for ; Fri, 12 Mar 2004 04:54:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jN1-0007Wk-GZ for idr-archive@odin.ietf.org; Fri, 12 Mar 2004 04:54:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C9sNV9028926 for idr-archive@odin.ietf.org; Fri, 12 Mar 2004 04:54:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jMx-0007WT-RG for idr-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 04:54:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10953 for ; Fri, 12 Mar 2004 04:54:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jMu-0005BV-00 for idr-web-archive@ietf.org; Fri, 12 Mar 2004 04:54:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jLw-00053W-00 for idr-web-archive@ietf.org; Fri, 12 Mar 2004 04:53:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1jL9-0004wv-00; Fri, 12 Mar 2004 04:52:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jKm-0007Ni-0k; Fri, 12 Mar 2004 04:52:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jK5-0007NA-AM for idr@optimus.ietf.org; Fri, 12 Mar 2004 04:51:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10768 for ; Fri, 12 Mar 2004 04:51:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jK2-0004o4-00 for idr@ietf.org; Fri, 12 Mar 2004 04:51:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jJ4-0004g5-00 for idr@ietf.org; Fri, 12 Mar 2004 04:50:18 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B1jI9-0004RZ-00 for idr@ietf.org; Fri, 12 Mar 2004 04:49:22 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i2C9moWK004427; Fri, 12 Mar 2004 01:48:50 -0800 (PST) Received: from cisco.com (sjc-vpn4-372.cisco.com [10.21.81.116]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARC73878; Fri, 12 Mar 2004 01:48:48 -0800 (PST) Message-ID: <40518780.30702@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 01:48:48 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka, > Now that the on-list thread has apparently died, and the off-list > discussions as well, I think it would be important to understand how > to move forward, and to try to gauge whether everyone is aware of > which issue we're talking about. The problem did not died but was solved. The solution was that this is implementation detail what next hops are used for route resolution as a matter of the protocol owner as well as what mask length is desired. It was also clearly concluded by a few that BGP spec is not the place to add this and that you may rather issue a standalone draft describing operational implications on discard next hops and possibly recommend to implementations some new functionality. > When the next-hop of some other router, on that *same* router, goes > through that "discard" route, the next-hop is still considered valid. > This causes rather obvious BGP timeout problems. Well I would say that this is rather not so obvious to have next hops for the routes causing any BGP timeouts. I have not see anyone opening a BGP session or configuring update src to a null0 route. I am not even sure what you are trying to say above. Cheers, R. > Pekka Savola wrote: > > Hello, it's me again :).. > > Now that the on-list thread has apparently died, and the off-list > discussions as well, I think it would be important to understand how > to move forward, and to try to gauge whether everyone is aware of > which issue we're talking about. > > As there was a lot of confusion at first on the actual problem, I > won't try to summarize the thread, because at different times, people > probably had entirely different assumptions of the problem. > > The bottom line is this: in very many cases you cannot avoid having to > insert some some kind of discard/reject or null0 route for a specific > prefix on a router (e.g., to generate a default route to some peers). > When the next-hop of some other router, on that *same* router, goes > through that "discard" route, the next-hop is still considered valid. > This causes rather obvious BGP timeout problems. > > The non-problem is when you have to redistribute that discard route in > your routing system, whether in IGP or BGP, and the other routers > cannot tell that's it's a discard route as it's learned through a > routing protocol. This can be rather easily avoided by configuring > the discard routes everywhere, so I don't think this needs to be > solved at this point. > > Now.. what do people think about this problem -- what should we do > (pick one or multiple): > > 1) try to specify some behaviour in the bgp spec to avoid this issue; > for example: > 1.a) state that if the route towards the next-hop leads to packets > being discarded by the router, SHOULD consider the next-hop ineligible > 1.b) state that the implementation SHOULD support being able to > configure which routes to use in in the next-hop eligibility detection > process > 1.c) to be worked out later.. > 1.d) something else -- what? > > 2) defer the solution until later > > 3) clarify the operational problem, to make the reader/implementer > aware of it > 3.a) in this revision of bgp spec > 3.b) in some other documents(s) > > 4) other -- what ? > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Mar 12 04:59:22 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11101 for ; Fri, 12 Mar 2004 04:59:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jRq-0005mz-00 for idr-archive@ietf.org; Fri, 12 Mar 2004 04:59:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jQu-0005g5-00 for idr-archive@ietf.org; Fri, 12 Mar 2004 04:58:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1jQZ-0005Z7-00; Fri, 12 Mar 2004 04:58:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jQX-0007bu-6i; Fri, 12 Mar 2004 04:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jPw-0007bd-VB for idr@optimus.ietf.org; Fri, 12 Mar 2004 04:57:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11051 for ; Fri, 12 Mar 2004 04:57:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jPt-0005YF-00 for idr@ietf.org; Fri, 12 Mar 2004 04:57:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jOv-0005Rc-00 for idr@ietf.org; Fri, 12 Mar 2004 04:56:21 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1B1jOg-0005LB-00 for idr@ietf.org; Fri, 12 Mar 2004 04:56:07 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i2C9t4bZ076794; Fri, 12 Mar 2004 04:55:04 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403120955.i2C9t4bZ076794@workhorse.fictitious.org> To: Pekka Savola cc: idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: Your message of "Fri, 12 Mar 2004 11:13:31 +0200." From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 04:55:04 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message , Pekka Savola w rites: > Hello, it's me again :).. > > Now that the on-list thread has apparently died, and the off-list > discussions as well, I think it would be important to understand how > to move forward, and to try to gauge whether everyone is aware of > which issue we're talking about. > > As there was a lot of confusion at first on the actual problem, I > won't try to summarize the thread, because at different times, people > probably had entirely different assumptions of the problem. > > The bottom line is this: in very many cases you cannot avoid having to > insert some some kind of discard/reject or null0 route for a specific > prefix on a router (e.g., to generate a default route to some peers). > When the next-hop of some other router, on that *same* router, goes > through that "discard" route, the next-hop is still considered valid. > This causes rather obvious BGP timeout problems. > > The non-problem is when you have to redistribute that discard route in > your routing system, whether in IGP or BGP, and the other routers > cannot tell that's it's a discard route as it's learned through a > routing protocol. This can be rather easily avoided by configuring > the discard routes everywhere, so I don't think this needs to be > solved at this point. > > Now.. what do people think about this problem -- what should we do > (pick one or multiple): > > 1) try to specify some behaviour in the bgp spec to avoid this issue; > for example: > 1.a) state that if the route towards the next-hop leads to packets > being discarded by the router, SHOULD consider the next-hop ineligible > 1.b) state that the implementation SHOULD support being able to > configure which routes to use in in the next-hop eligibility detection > process > 1.c) to be worked out later.. > 1.d) something else -- what? > > 2) defer the solution until later > > 3) clarify the operational problem, to make the reader/implementer > aware of it > 3.a) in this revision of bgp spec > 3.b) in some other documents(s) > > 4) other -- what ? > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings In this ongoing discussion, we should be clear about what the consequence is. IBGP learned routes from a peer that has gone down do not get withdrawn on the IGP route withdraw due to the coverage of the next hop by an aggregate. Those IBGP learned routes are withdrawn after the BGP session times out which is rather a long time by today's standards. This is mostly a usage issue which arises when a provider's infrastructure is covered by an aggregate that is advertised within that provider's infrastructure. This problem is easily avoided, except in providers (or other BGP usage) where a default route is made available or where address space of the provider is taken from a larger aggregate of another provider. With some optional configuration a router can exclude routes from consideration in matching the BGP next-hop resolvable test. If the router does so, the provider doesn't need to work around the problem. I think the best way to handle this (from the standards standpoint) is to write a separate draft. The draft would provide a better "BGP next hop resolvable test" but does not match any current implementation so it does not belong in the BGP spec. If changes are made to any implementations they would remain fully interoperable with those that go by the letter of the spec without any "better resolvable test". Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Mar 12 04:59:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11124 for ; Fri, 12 Mar 2004 04:59:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jRw-0007kY-QD for idr-archive@odin.ietf.org; Fri, 12 Mar 2004 04:59:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C9xSmi029779 for idr-archive@odin.ietf.org; Fri, 12 Mar 2004 04:59:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jRt-0007kA-SL for idr-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 04:59:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11119 for ; Fri, 12 Mar 2004 04:59:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jRq-0005n4-00 for idr-web-archive@ietf.org; Fri, 12 Mar 2004 04:59:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jQv-0005gD-00 for idr-web-archive@ietf.org; Fri, 12 Mar 2004 04:58:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1jQZ-0005Z7-00; Fri, 12 Mar 2004 04:58:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jQX-0007bu-6i; Fri, 12 Mar 2004 04:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jPw-0007bd-VB for idr@optimus.ietf.org; Fri, 12 Mar 2004 04:57:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11051 for ; Fri, 12 Mar 2004 04:57:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jPt-0005YF-00 for idr@ietf.org; Fri, 12 Mar 2004 04:57:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jOv-0005Rc-00 for idr@ietf.org; Fri, 12 Mar 2004 04:56:21 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1B1jOg-0005LB-00 for idr@ietf.org; Fri, 12 Mar 2004 04:56:07 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i2C9t4bZ076794; Fri, 12 Mar 2004 04:55:04 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403120955.i2C9t4bZ076794@workhorse.fictitious.org> To: Pekka Savola cc: idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: Your message of "Fri, 12 Mar 2004 11:13:31 +0200." From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 04:55:04 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message , Pekka Savola w rites: > Hello, it's me again :).. > > Now that the on-list thread has apparently died, and the off-list > discussions as well, I think it would be important to understand how > to move forward, and to try to gauge whether everyone is aware of > which issue we're talking about. > > As there was a lot of confusion at first on the actual problem, I > won't try to summarize the thread, because at different times, people > probably had entirely different assumptions of the problem. > > The bottom line is this: in very many cases you cannot avoid having to > insert some some kind of discard/reject or null0 route for a specific > prefix on a router (e.g., to generate a default route to some peers). > When the next-hop of some other router, on that *same* router, goes > through that "discard" route, the next-hop is still considered valid. > This causes rather obvious BGP timeout problems. > > The non-problem is when you have to redistribute that discard route in > your routing system, whether in IGP or BGP, and the other routers > cannot tell that's it's a discard route as it's learned through a > routing protocol. This can be rather easily avoided by configuring > the discard routes everywhere, so I don't think this needs to be > solved at this point. > > Now.. what do people think about this problem -- what should we do > (pick one or multiple): > > 1) try to specify some behaviour in the bgp spec to avoid this issue; > for example: > 1.a) state that if the route towards the next-hop leads to packets > being discarded by the router, SHOULD consider the next-hop ineligible > 1.b) state that the implementation SHOULD support being able to > configure which routes to use in in the next-hop eligibility detection > process > 1.c) to be worked out later.. > 1.d) something else -- what? > > 2) defer the solution until later > > 3) clarify the operational problem, to make the reader/implementer > aware of it > 3.a) in this revision of bgp spec > 3.b) in some other documents(s) > > 4) other -- what ? > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings In this ongoing discussion, we should be clear about what the consequence is. IBGP learned routes from a peer that has gone down do not get withdrawn on the IGP route withdraw due to the coverage of the next hop by an aggregate. Those IBGP learned routes are withdrawn after the BGP session times out which is rather a long time by today's standards. This is mostly a usage issue which arises when a provider's infrastructure is covered by an aggregate that is advertised within that provider's infrastructure. This problem is easily avoided, except in providers (or other BGP usage) where a default route is made available or where address space of the provider is taken from a larger aggregate of another provider. With some optional configuration a router can exclude routes from consideration in matching the BGP next-hop resolvable test. If the router does so, the provider doesn't need to work around the problem. I think the best way to handle this (from the standards standpoint) is to write a separate draft. The draft would provide a better "BGP next hop resolvable test" but does not match any current implementation so it does not belong in the BGP spec. If changes are made to any implementations they would remain fully interoperable with those that go by the letter of the spec without any "better resolvable test". Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Mar 12 05:01:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11201 for ; Fri, 12 Mar 2004 05:01:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jTs-00063X-00 for idr-archive@ietf.org; Fri, 12 Mar 2004 05:01:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jSs-0005vf-00 for idr-archive@ietf.org; Fri, 12 Mar 2004 05:00:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1jSZ-0005oB-00; Fri, 12 Mar 2004 05:00:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jSU-0007l6-UO; Fri, 12 Mar 2004 05:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jRn-0007k0-BK for idr@optimus.ietf.org; Fri, 12 Mar 2004 04:59:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11095 for ; Fri, 12 Mar 2004 04:59:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jRk-0005m9-00 for idr@ietf.org; Fri, 12 Mar 2004 04:59:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jQq-0005fO-00 for idr@ietf.org; Fri, 12 Mar 2004 04:58:21 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jPw-0005Rs-00 for idr@ietf.org; Fri, 12 Mar 2004 04:57:24 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2C9ukp03291; Fri, 12 Mar 2004 11:56:46 +0200 From: Pekka Savola To: Robert Raszuk cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <40518780.30702@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 11:56:46 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 12 Mar 2004, Robert Raszuk wrote: > > Now that the on-list thread has apparently died, and the off-list > > discussions as well, I think it would be important to understand how > > to move forward, and to try to gauge whether everyone is aware of > > which issue we're talking about. > > The problem did not died but was solved. The solution was that this is > implementation detail what next hops are used for route resolution as a > matter of the protocol owner as well as what mask length is desired. First, if it was decided that this is an implementation detail, it must IMHO be explicitly called out as such. Second, I disagree with this being an "implementation detail". This has significant operational implications, and the behaviour must be as consistent as possible. Dusting this off under the carpet doesn't seem to be reasonable. > > When the next-hop of some other router, on that *same* router, goes > > through that "discard" route, the next-hop is still considered valid. > > This causes rather obvious BGP timeout problems. > > Well I would say that this is rather not so obvious to have next hops > for the routes causing any BGP timeouts. I have not see anyone opening a > BGP session or configuring update src to a null0 route. I am not even > sure what you are trying to say above. Sorry for bad wording. The intent was to say that when another router fails, and the next-hop points to that router, if the next-hop is not made ineligible, the routes going through that router will only be removed when the BGP timeout expires... causing very long unavailability. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Mar 12 05:14:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11564 for ; Fri, 12 Mar 2004 05:14:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jgO-0007YQ-00 for idr-archive@ietf.org; Fri, 12 Mar 2004 05:14:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jfR-0007Qx-00 for idr-archive@ietf.org; Fri, 12 Mar 2004 05:13:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1jfA-0007K5-00; Fri, 12 Mar 2004 05:13:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jf4-0008R4-BG; Fri, 12 Mar 2004 05:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jeO-0008QE-8z for idr@optimus.ietf.org; Fri, 12 Mar 2004 05:12:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11513 for ; Fri, 12 Mar 2004 05:12:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jeL-0007Ir-00 for idr@ietf.org; Fri, 12 Mar 2004 05:12:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jdP-0007CC-00 for idr@ietf.org; Fri, 12 Mar 2004 05:11:20 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B1jcT-0006yP-00 for idr@ietf.org; Fri, 12 Mar 2004 05:10:21 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Mar 2004 02:13:42 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2CA9nK2021790; Fri, 12 Mar 2004 02:09:50 -0800 (PST) Received: from cisco.com (sjc-vpn4-372.cisco.com [10.21.81.116]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARC74416; Fri, 12 Mar 2004 02:09:47 -0800 (PST) Message-ID: <40518C6B.6060308@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 02:09:47 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Pekka, >> > When the next-hop of some other router, on that *same* router, goes >> > through that "discard" route, the next-hop is still considered valid. >> > This causes rather obvious BGP timeout problems. >> >>Well I would say that this is rather not so obvious to have next hops >>for the routes causing any BGP timeouts. I have not see anyone opening a >>BGP session or configuring update src to a null0 route. I am not even >>sure what you are trying to say above. > > > Sorry for bad wording. The intent was to say that when another router > fails, and the next-hop points to that router, if the next-hop is not > made ineligible, the routes going through that router will only be > removed when the BGP timeout expires... causing very long > unavailability. So all you are asking here is faster next hop state detection and fast route validatation. Very valid request, but again I fail to see why BGP spec should mandate how fast one wishes to validate his next hops. All major implementations I am aware about do it fast enough or allow one to configure how fast you want to validate the next hops. Anyhow you can for sure propose the text and min timers this should happen and send to the list for review. Btw .. bgp session timeout does not have to be only triggered by BGP keepalives :) If you monitor some other work in the IETF BFD could be one trigger, IGP another etc ... so it could be very fast indeed ;) Cheers, R. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Mar 12 05:14:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11585 for ; Fri, 12 Mar 2004 05:14:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jgU-0000Cx-Ds for idr-archive@odin.ietf.org; Fri, 12 Mar 2004 05:14:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CAEU2K000795 for idr-archive@odin.ietf.org; Fri, 12 Mar 2004 05:14:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jgS-0000Ck-Nz for idr-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 05:14:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11582 for ; Fri, 12 Mar 2004 05:14:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jgP-0007YV-00 for idr-web-archive@ietf.org; Fri, 12 Mar 2004 05:14:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jfR-0007R5-00 for idr-web-archive@ietf.org; Fri, 12 Mar 2004 05:13:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1jfA-0007K5-00; Fri, 12 Mar 2004 05:13:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jf4-0008R4-BG; Fri, 12 Mar 2004 05:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jeO-0008QE-8z for idr@optimus.ietf.org; Fri, 12 Mar 2004 05:12:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11513 for ; Fri, 12 Mar 2004 05:12:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jeL-0007Ir-00 for idr@ietf.org; Fri, 12 Mar 2004 05:12:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jdP-0007CC-00 for idr@ietf.org; Fri, 12 Mar 2004 05:11:20 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B1jcT-0006yP-00 for idr@ietf.org; Fri, 12 Mar 2004 05:10:21 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Mar 2004 02:13:42 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2CA9nK2021790; Fri, 12 Mar 2004 02:09:50 -0800 (PST) Received: from cisco.com (sjc-vpn4-372.cisco.com [10.21.81.116]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARC74416; Fri, 12 Mar 2004 02:09:47 -0800 (PST) Message-ID: <40518C6B.6060308@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 02:09:47 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka, >> > When the next-hop of some other router, on that *same* router, goes >> > through that "discard" route, the next-hop is still considered valid. >> > This causes rather obvious BGP timeout problems. >> >>Well I would say that this is rather not so obvious to have next hops >>for the routes causing any BGP timeouts. I have not see anyone opening a >>BGP session or configuring update src to a null0 route. I am not even >>sure what you are trying to say above. > > > Sorry for bad wording. The intent was to say that when another router > fails, and the next-hop points to that router, if the next-hop is not > made ineligible, the routes going through that router will only be > removed when the BGP timeout expires... causing very long > unavailability. So all you are asking here is faster next hop state detection and fast route validatation. Very valid request, but again I fail to see why BGP spec should mandate how fast one wishes to validate his next hops. All major implementations I am aware about do it fast enough or allow one to configure how fast you want to validate the next hops. Anyhow you can for sure propose the text and min timers this should happen and send to the list for review. Btw .. bgp session timeout does not have to be only triggered by BGP keepalives :) If you monitor some other work in the IETF BFD could be one trigger, IGP another etc ... so it could be very fast indeed ;) Cheers, R. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Mar 12 05:25:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11998 for ; Fri, 12 Mar 2004 05:25:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jr7-0001A9-00 for idr-archive@ietf.org; Fri, 12 Mar 2004 05:25:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jqN-00012L-00 for idr-archive@ietf.org; Fri, 12 Mar 2004 05:24:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1jpl-0000un-00; Fri, 12 Mar 2004 05:24:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jpi-0000bE-Dm; Fri, 12 Mar 2004 05:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jp7-0000ZT-Vq for idr@optimus.ietf.org; Fri, 12 Mar 2004 05:23:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11886 for ; Fri, 12 Mar 2004 05:23:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jp4-0000tF-00 for idr@ietf.org; Fri, 12 Mar 2004 05:23:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1joB-0000mC-00 for idr@ietf.org; Fri, 12 Mar 2004 05:22:28 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jnJ-0000X3-00 for idr@ietf.org; Fri, 12 Mar 2004 05:21:33 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2CAKtH03846; Fri, 12 Mar 2004 12:20:55 +0200 From: Pekka Savola To: Robert Raszuk cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <40518C6B.6060308@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 12:20:55 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 12 Mar 2004, Robert Raszuk wrote: > So all you are asking here is faster next hop state detection and fast > route validatation. Very valid request, but again I fail to see why BGP > spec should mandate how fast one wishes to validate his next hops. All > major implementations I am aware about do it fast enough or allow one to > configure how fast you want to validate the next hops. No, the validation time (i.e., how often you check whether a nexthop has become ineligible) is not the point. The point is that the validation process, no matter how often or seldom is run, reports "valid!" for these routes which go through a discard next-hop. Rigging the timers changes nothing. > Btw .. bgp session timeout does not have to be only triggered by BGP > keepalives :) If you monitor some other work in the IETF BFD could be > one trigger, IGP another etc ... so it could be very fast indeed ;) FWIW, Multi-hop case is currently basically out of scope for BFD. But that's a separate topic. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Mar 12 05:26:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12022 for ; Fri, 12 Mar 2004 05:26:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jrE-0000pg-1w for idr-archive@odin.ietf.org; Fri, 12 Mar 2004 05:25:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CAPZn4003201 for idr-archive@odin.ietf.org; Fri, 12 Mar 2004 05:25:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jrC-0000pT-3e for idr-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 05:25:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12015 for ; Fri, 12 Mar 2004 05:25:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jr8-0001AE-00 for idr-web-archive@ietf.org; Fri, 12 Mar 2004 05:25:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jqO-00012T-00 for idr-web-archive@ietf.org; Fri, 12 Mar 2004 05:24:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1jpl-0000un-00; Fri, 12 Mar 2004 05:24:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jpi-0000bE-Dm; Fri, 12 Mar 2004 05:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jp7-0000ZT-Vq for idr@optimus.ietf.org; Fri, 12 Mar 2004 05:23:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11886 for ; Fri, 12 Mar 2004 05:23:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jp4-0000tF-00 for idr@ietf.org; Fri, 12 Mar 2004 05:23:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1joB-0000mC-00 for idr@ietf.org; Fri, 12 Mar 2004 05:22:28 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jnJ-0000X3-00 for idr@ietf.org; Fri, 12 Mar 2004 05:21:33 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2CAKtH03846; Fri, 12 Mar 2004 12:20:55 +0200 From: Pekka Savola To: Robert Raszuk cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <40518C6B.6060308@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 12:20:55 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 12 Mar 2004, Robert Raszuk wrote: > So all you are asking here is faster next hop state detection and fast > route validatation. Very valid request, but again I fail to see why BGP > spec should mandate how fast one wishes to validate his next hops. All > major implementations I am aware about do it fast enough or allow one to > configure how fast you want to validate the next hops. No, the validation time (i.e., how often you check whether a nexthop has become ineligible) is not the point. The point is that the validation process, no matter how often or seldom is run, reports "valid!" for these routes which go through a discard next-hop. Rigging the timers changes nothing. > Btw .. bgp session timeout does not have to be only triggered by BGP > keepalives :) If you monitor some other work in the IETF BFD could be > one trigger, IGP another etc ... so it could be very fast indeed ;) FWIW, Multi-hop case is currently basically out of scope for BFD. But that's a separate topic. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Mar 12 14:17:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12086 for ; Fri, 12 Mar 2004 14:17:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1sAO-0006cN-00 for idr-archive@ietf.org; Fri, 12 Mar 2004 14:17:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1s9S-0006UI-00 for idr-archive@ietf.org; Fri, 12 Mar 2004 14:16:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1s8x-0006LU-00; Fri, 12 Mar 2004 14:16:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1s8a-0001Gc-2m; Fri, 12 Mar 2004 14:16:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1s8S-0001F9-C2 for idr@optimus.ietf.org; Fri, 12 Mar 2004 14:15:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11937 for ; Fri, 12 Mar 2004 14:15:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1s8P-0006Jn-00 for idr@ietf.org; Fri, 12 Mar 2004 14:15:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1s7l-0006Ay-00 for idr@ietf.org; Fri, 12 Mar 2004 14:15:14 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1B1s6r-0005xp-00 for idr@ietf.org; Fri, 12 Mar 2004 14:14:17 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 09E2A2D4889; Fri, 12 Mar 2004 14:13:47 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17404-01-36; Fri, 12 Mar 2004 14:13:45 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 4C5B92D4886; Fri, 12 Mar 2004 14:13:19 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i2CJDIl25240; Fri, 12 Mar 2004 14:13:18 -0500 (EST) From: Jeffrey Haas To: Curtis Villamizar Cc: Pekka Savola , idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes Message-ID: <20040312141318.C17845@nexthop.com> References: <200403120955.i2C9t4bZ076794@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200403120955.i2C9t4bZ076794@workhorse.fictitious.org>; from curtis@fictitious.org on Fri, Mar 12, 2004 at 04:55:04AM -0500 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 14:13:18 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, Mar 12, 2004 at 04:55:04AM -0500, Curtis Villamizar wrote: > I think the best way to handle this (from the standards standpoint) is > to write a separate draft. The draft would provide a better "BGP next > hop resolvable test" but does not match any current implementation so > it does not belong in the BGP spec. If changes are made to any > implementations they would remain fully interoperable with those that > go by the letter of the spec without any "better resolvable test". I would agree with Curtis. This is an operational/deployment issue and a draft covering such issues - and not just this one - may be a Good Thing. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Mar 12 14:18:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12124 for ; Fri, 12 Mar 2004 14:18:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1sAS-0001S4-2g for idr-archive@odin.ietf.org; Fri, 12 Mar 2004 14:18:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CJI0C5005576 for idr-archive@odin.ietf.org; Fri, 12 Mar 2004 14:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1sAR-0001Rr-VL for idr-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 14:17:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12100 for ; Fri, 12 Mar 2004 14:17:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1sAP-0006cS-00 for idr-web-archive@ietf.org; Fri, 12 Mar 2004 14:17:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1s9T-0006UP-00 for idr-web-archive@ietf.org; Fri, 12 Mar 2004 14:17:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1s8x-0006LU-00; Fri, 12 Mar 2004 14:16:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1s8a-0001Gc-2m; Fri, 12 Mar 2004 14:16:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1s8S-0001F9-C2 for idr@optimus.ietf.org; Fri, 12 Mar 2004 14:15:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11937 for ; Fri, 12 Mar 2004 14:15:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1s8P-0006Jn-00 for idr@ietf.org; Fri, 12 Mar 2004 14:15:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1s7l-0006Ay-00 for idr@ietf.org; Fri, 12 Mar 2004 14:15:14 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1B1s6r-0005xp-00 for idr@ietf.org; Fri, 12 Mar 2004 14:14:17 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 09E2A2D4889; Fri, 12 Mar 2004 14:13:47 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17404-01-36; Fri, 12 Mar 2004 14:13:45 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 4C5B92D4886; Fri, 12 Mar 2004 14:13:19 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i2CJDIl25240; Fri, 12 Mar 2004 14:13:18 -0500 (EST) From: Jeffrey Haas To: Curtis Villamizar Cc: Pekka Savola , idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes Message-ID: <20040312141318.C17845@nexthop.com> References: <200403120955.i2C9t4bZ076794@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200403120955.i2C9t4bZ076794@workhorse.fictitious.org>; from curtis@fictitious.org on Fri, Mar 12, 2004 at 04:55:04AM -0500 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 14:13:18 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, Mar 12, 2004 at 04:55:04AM -0500, Curtis Villamizar wrote: > I think the best way to handle this (from the standards standpoint) is > to write a separate draft. The draft would provide a better "BGP next > hop resolvable test" but does not match any current implementation so > it does not belong in the BGP spec. If changes are made to any > implementations they would remain fully interoperable with those that > go by the letter of the spec without any "better resolvable test". I would agree with Curtis. This is an operational/deployment issue and a draft covering such issues - and not just this one - may be a Good Thing. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Sat Mar 13 03:02:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03629 for ; Sat, 13 Mar 2004 03:02:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B245o-00009D-00 for idr-archive@ietf.org; Sat, 13 Mar 2004 03:02:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B244t-00007T-00 for idr-archive@ietf.org; Sat, 13 Mar 2004 03:01:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B244H-00005U-00; Sat, 13 Mar 2004 03:00:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B243v-0003rd-2S; Sat, 13 Mar 2004 03:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B243C-0003q8-BG for idr@optimus.ietf.org; Sat, 13 Mar 2004 02:59:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03559 for ; Sat, 13 Mar 2004 02:59:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2438-00001Q-00 for idr@ietf.org; Sat, 13 Mar 2004 02:59:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B242H-0007lc-00 for idr@ietf.org; Sat, 13 Mar 2004 02:58:21 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B241m-0007gQ-00 for idr@ietf.org; Sat, 13 Mar 2004 02:57:50 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2D7vFd21750 for ; Sat, 13 Mar 2004 09:57:15 +0200 From: Pekka Savola To: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <20040312141318.C17845@nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 13 Mar 2004 09:57:15 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 12 Mar 2004, Jeffrey Haas wrote: > On Fri, Mar 12, 2004 at 04:55:04AM -0500, Curtis Villamizar wrote: > > I think the best way to handle this (from the standards standpoint) is > > to write a separate draft. The draft would provide a better "BGP next > > hop resolvable test" but does not match any current implementation so > > it does not belong in the BGP spec. If changes are made to any > > implementations they would remain fully interoperable with those that > > go by the letter of the spec without any "better resolvable test". > > I would agree with Curtis. This is an operational/deployment issue > and a draft covering such issues - and not just this one - may > be a Good Thing. There was already an off-list discussion about this, but I think I should clarify the issue here: The local router knows that route R2 is a discard/null0 route, and the nexthop of route R1 goes through R2 after the more specific route has been withdrawn from IGP. Route R1 is considered valid even though the router knows it goes through a discard route. Many consider this an implementation bug; some have already said they'd fix this, so the argument "there is no implementation" does not hold. What I want is that this gets fixed in the spec, because the spec can be read both ways. I want to avoid "local optimizations" by implementations, and fix this in the specification. It would be irresponsible to have purposely ambiguous specifications. One possible way to fix this could be, in 9.1.2.1: ---- The route resolvability condition is defined as follows. 1. A route Rte1, referencing only the intermediate network address, is considered resolvable if the Routing Table contains at least one resolvable route Rte2 that matches Rte1's intermediate network address and is not recursively resolved (directly or indi- rectly) through Rte1. If multiple matching routes are available, only the longest matching route SHOULD be considered. 2. Routes referencing interfaces (with or without intermediate addresses) are considered resolvable if the state of the refer- enced interface is up and IP processing is enabled on this inter- face. ---- Add a clarifying paragraph afterwards: If a route's (Rte1) next-hop (Rte2) or next-hop interface would lead to packets being discarded by the same router, the route (Rte1) SHOULD be considered unresolvable. or: When considering resolvable routes or referenced interfaces, if packets through the route would be discarded by the router, the route SHOULD be considered unresolvable. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Sat Mar 13 03:02:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03652 for ; Sat, 13 Mar 2004 03:02:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B245w-00044m-0Y for idr-archive@odin.ietf.org; Sat, 13 Mar 2004 03:02:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2D827Bl015660 for idr-archive@odin.ietf.org; Sat, 13 Mar 2004 03:02:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B245t-00044U-2Q for idr-web-archive@optimus.ietf.org; Sat, 13 Mar 2004 03:02:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03647 for ; Sat, 13 Mar 2004 03:02:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B245p-00009I-00 for idr-web-archive@ietf.org; Sat, 13 Mar 2004 03:02:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B244u-00007d-00 for idr-web-archive@ietf.org; Sat, 13 Mar 2004 03:01:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B244H-00005U-00; Sat, 13 Mar 2004 03:00:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B243v-0003rd-2S; Sat, 13 Mar 2004 03:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B243C-0003q8-BG for idr@optimus.ietf.org; Sat, 13 Mar 2004 02:59:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03559 for ; Sat, 13 Mar 2004 02:59:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2438-00001Q-00 for idr@ietf.org; Sat, 13 Mar 2004 02:59:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B242H-0007lc-00 for idr@ietf.org; Sat, 13 Mar 2004 02:58:21 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B241m-0007gQ-00 for idr@ietf.org; Sat, 13 Mar 2004 02:57:50 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2D7vFd21750 for ; Sat, 13 Mar 2004 09:57:15 +0200 From: Pekka Savola To: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <20040312141318.C17845@nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 13 Mar 2004 09:57:15 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 12 Mar 2004, Jeffrey Haas wrote: > On Fri, Mar 12, 2004 at 04:55:04AM -0500, Curtis Villamizar wrote: > > I think the best way to handle this (from the standards standpoint) is > > to write a separate draft. The draft would provide a better "BGP next > > hop resolvable test" but does not match any current implementation so > > it does not belong in the BGP spec. If changes are made to any > > implementations they would remain fully interoperable with those that > > go by the letter of the spec without any "better resolvable test". > > I would agree with Curtis. This is an operational/deployment issue > and a draft covering such issues - and not just this one - may > be a Good Thing. There was already an off-list discussion about this, but I think I should clarify the issue here: The local router knows that route R2 is a discard/null0 route, and the nexthop of route R1 goes through R2 after the more specific route has been withdrawn from IGP. Route R1 is considered valid even though the router knows it goes through a discard route. Many consider this an implementation bug; some have already said they'd fix this, so the argument "there is no implementation" does not hold. What I want is that this gets fixed in the spec, because the spec can be read both ways. I want to avoid "local optimizations" by implementations, and fix this in the specification. It would be irresponsible to have purposely ambiguous specifications. One possible way to fix this could be, in 9.1.2.1: ---- The route resolvability condition is defined as follows. 1. A route Rte1, referencing only the intermediate network address, is considered resolvable if the Routing Table contains at least one resolvable route Rte2 that matches Rte1's intermediate network address and is not recursively resolved (directly or indi- rectly) through Rte1. If multiple matching routes are available, only the longest matching route SHOULD be considered. 2. Routes referencing interfaces (with or without intermediate addresses) are considered resolvable if the state of the refer- enced interface is up and IP processing is enabled on this inter- face. ---- Add a clarifying paragraph afterwards: If a route's (Rte1) next-hop (Rte2) or next-hop interface would lead to packets being discarded by the same router, the route (Rte1) SHOULD be considered unresolvable. or: When considering resolvable routes or referenced interfaces, if packets through the route would be discarded by the router, the route SHOULD be considered unresolvable. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 15 11:52:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09608 for ; Mon, 15 Mar 2004 11:52:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2vJz-0004DV-00 for idr-archive@ietf.org; Mon, 15 Mar 2004 11:52:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2vJ0-00045J-00 for idr-archive@ietf.org; Mon, 15 Mar 2004 11:51:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2vIM-0003xk-00; Mon, 15 Mar 2004 11:50:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2vHu-0004dn-QB; Mon, 15 Mar 2004 11:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2vHo-0004d0-Rz for idr@optimus.ietf.org; Mon, 15 Mar 2004 11:49:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09512 for ; Mon, 15 Mar 2004 11:49:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2vHn-0003tw-00 for idr@ietf.org; Mon, 15 Mar 2004 11:49:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2vGp-0003lQ-00 for idr@ietf.org; Mon, 15 Mar 2004 11:48:56 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1B2vFp-0003YE-00 for idr@ietf.org; Mon, 15 Mar 2004 11:47:53 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i2FGlNl68963 for ; Mon, 15 Mar 2004 08:47:23 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i2FGlIJ54485 for ; Mon, 15 Mar 2004 08:47:18 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200403151647.i2FGlIJ54485@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <86685.1079369238.1@juniper.net> From: Yakov Rekhter Subject: [Idr] BGP Extended Communities implementation report Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Mar 2004 08:47:18 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, Those who participated in the BGP Extended Communities implementation report please let me know if you'd like me to make any updates. Those who did not participate in the report, but would like to be added to the report, please send me the info in a format similar to the one used in the report. The deadline is March 28, 2004. Yakov. ------- Forwarded Message Date: Thu, 11 Mar 2004 15:18:35 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-rekhter-ext-communities-survey-02.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP Extended Communities Attribute - Implementation S urvey Author(s) : Y. Rekhter Filename : draft-rekhter-ext-communities-survey-02.txt Pages : 13 Date : 2004-3-11 This document provides a survey of BGP-4 Extended Communities implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rekhter-ext-communities-survey-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rekhter-ext-communities-survey-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rekhter-ext-communities-survey-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-11142651.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rekhter-ext-communities-survey-02.txt - --OtherAccess Content-Type: Message/External-body; name="draft-rekhter-ext-communities-survey-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-11142651.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 15 11:52:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09669 for ; Mon, 15 Mar 2004 11:52:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2vK7-0004v9-6I for idr-archive@odin.ietf.org; Mon, 15 Mar 2004 11:52:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FGqJ6a018915 for idr-archive@odin.ietf.org; Mon, 15 Mar 2004 11:52:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2vK7-0004v0-1L for idr-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 11:52:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09628 for ; Mon, 15 Mar 2004 11:52:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2vK5-0004EY-00 for idr-web-archive@ietf.org; Mon, 15 Mar 2004 11:52:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2vJ1-00045a-00 for idr-web-archive@ietf.org; Mon, 15 Mar 2004 11:51:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2vIM-0003xk-00; Mon, 15 Mar 2004 11:50:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2vHu-0004dn-QB; Mon, 15 Mar 2004 11:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2vHo-0004d0-Rz for idr@optimus.ietf.org; Mon, 15 Mar 2004 11:49:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09512 for ; Mon, 15 Mar 2004 11:49:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2vHn-0003tw-00 for idr@ietf.org; Mon, 15 Mar 2004 11:49:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2vGp-0003lQ-00 for idr@ietf.org; Mon, 15 Mar 2004 11:48:56 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1B2vFp-0003YE-00 for idr@ietf.org; Mon, 15 Mar 2004 11:47:53 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i2FGlNl68963 for ; Mon, 15 Mar 2004 08:47:23 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i2FGlIJ54485 for ; Mon, 15 Mar 2004 08:47:18 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200403151647.i2FGlIJ54485@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <86685.1079369238.1@juniper.net> From: Yakov Rekhter Subject: [Idr] BGP Extended Communities implementation report Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Mar 2004 08:47:18 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, Those who participated in the BGP Extended Communities implementation report please let me know if you'd like me to make any updates. Those who did not participate in the report, but would like to be added to the report, please send me the info in a format similar to the one used in the report. The deadline is March 28, 2004. Yakov. ------- Forwarded Message Date: Thu, 11 Mar 2004 15:18:35 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-rekhter-ext-communities-survey-02.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP Extended Communities Attribute - Implementation S urvey Author(s) : Y. Rekhter Filename : draft-rekhter-ext-communities-survey-02.txt Pages : 13 Date : 2004-3-11 This document provides a survey of BGP-4 Extended Communities implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rekhter-ext-communities-survey-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rekhter-ext-communities-survey-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rekhter-ext-communities-survey-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-11142651.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rekhter-ext-communities-survey-02.txt - --OtherAccess Content-Type: Message/External-body; name="draft-rekhter-ext-communities-survey-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-11142651.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 15 23:28:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22297 for ; Mon, 15 Mar 2004 23:28:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B36C0-00035X-00 for idr-archive@ietf.org; Mon, 15 Mar 2004 23:28:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B36Av-00031b-00 for idr-archive@ietf.org; Mon, 15 Mar 2004 23:27:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B36Aa-0002xm-00; Mon, 15 Mar 2004 23:27:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B36AO-00082r-TD; Mon, 15 Mar 2004 23:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B369u-00082A-3q for idr@optimus.ietf.org; Mon, 15 Mar 2004 23:26:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22234 for ; Mon, 15 Mar 2004 23:26:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B369s-0002wZ-00 for idr@ietf.org; Mon, 15 Mar 2004 23:26:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B368t-0002sz-00 for idr@ietf.org; Mon, 15 Mar 2004 23:25:28 -0500 Received: from web25108.mail.ukl.yahoo.com ([217.12.10.56]) by ietf-mx with smtp (Exim 4.12) id 1B3689-0002lr-00 for idr@ietf.org; Mon, 15 Mar 2004 23:24:41 -0500 Message-ID: <20040316042412.36359.qmail@web25108.mail.ukl.yahoo.com> Received: from [203.200.20.226] by web25108.mail.ukl.yahoo.com via HTTP; Tue, 16 Mar 2004 04:24:12 GMT From: =?iso-8859-1?q?John=20Smith?= To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Idr] IBGP to replace IGP Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 04:24:12 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Hi, I am very clear with the concept that IGPs cannot be used to carry the entire BGP feed as they cant be scaled to carry so many prefixes (even assuming we add enough TLVs to make them carry the BGP attributes). What is not very clear to me is, why cant we use IBGP inside an AS to completely do away with IGPs. IGPs compute the best path to reach a particular neighbor based on the link metric. This can be achieved in BGP also, if we include a TLV to carry the link cost. Moreover, it is *mandatory* to run BGP on all the routers if we are transiting traffic, because if a router isnt speaking BGP then it cant forward BGP traffic. Cant we do away with IGPs (say in some small networks) and run only IBGP there? Any help/clues/pointers in this regard will be really appreciated. Regards, Smith ___________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 15 23:29:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22318 for ; Mon, 15 Mar 2004 23:29:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B36C3-0008BJ-OH for idr-archive@odin.ietf.org; Mon, 15 Mar 2004 23:28:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2G4Shit031448 for idr-archive@odin.ietf.org; Mon, 15 Mar 2004 23:28:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B36C3-0008B9-J5 for idr-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 23:28:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22311 for ; Mon, 15 Mar 2004 23:28:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B36C1-00035c-00 for idr-web-archive@ietf.org; Mon, 15 Mar 2004 23:28:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B36Av-00031i-00 for idr-web-archive@ietf.org; Mon, 15 Mar 2004 23:27:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B36Aa-0002xm-00; Mon, 15 Mar 2004 23:27:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B36AO-00082r-TD; Mon, 15 Mar 2004 23:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B369u-00082A-3q for idr@optimus.ietf.org; Mon, 15 Mar 2004 23:26:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22234 for ; Mon, 15 Mar 2004 23:26:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B369s-0002wZ-00 for idr@ietf.org; Mon, 15 Mar 2004 23:26:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B368t-0002sz-00 for idr@ietf.org; Mon, 15 Mar 2004 23:25:28 -0500 Received: from web25108.mail.ukl.yahoo.com ([217.12.10.56]) by ietf-mx with smtp (Exim 4.12) id 1B3689-0002lr-00 for idr@ietf.org; Mon, 15 Mar 2004 23:24:41 -0500 Message-ID: <20040316042412.36359.qmail@web25108.mail.ukl.yahoo.com> Received: from [203.200.20.226] by web25108.mail.ukl.yahoo.com via HTTP; Tue, 16 Mar 2004 04:24:12 GMT From: =?iso-8859-1?q?John=20Smith?= To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Idr] IBGP to replace IGP Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 04:24:12 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, I am very clear with the concept that IGPs cannot be used to carry the entire BGP feed as they cant be scaled to carry so many prefixes (even assuming we add enough TLVs to make them carry the BGP attributes). What is not very clear to me is, why cant we use IBGP inside an AS to completely do away with IGPs. IGPs compute the best path to reach a particular neighbor based on the link metric. This can be achieved in BGP also, if we include a TLV to carry the link cost. Moreover, it is *mandatory* to run BGP on all the routers if we are transiting traffic, because if a router isnt speaking BGP then it cant forward BGP traffic. Cant we do away with IGPs (say in some small networks) and run only IBGP there? Any help/clues/pointers in this regard will be really appreciated. Regards, Smith ___________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 16 00:48:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27168 for ; Tue, 16 Mar 2004 00:48:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37RD-0003se-00 for idr-archive@ietf.org; Tue, 16 Mar 2004 00:48:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B37QK-0003pm-00 for idr-archive@ietf.org; Tue, 16 Mar 2004 00:47:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B37Px-0003mZ-00; Tue, 16 Mar 2004 00:47:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37Pp-00069Z-1z; Tue, 16 Mar 2004 00:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37PI-000693-KJ for idr@optimus.ietf.org; Tue, 16 Mar 2004 00:46:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27121 for ; Tue, 16 Mar 2004 00:46:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37PF-0003lw-00 for idr@ietf.org; Tue, 16 Mar 2004 00:46:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B37OP-0003j3-00 for idr@ietf.org; Tue, 16 Mar 2004 00:45:34 -0500 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1B37Nu-0003fv-00 for idr@ietf.org; Tue, 16 Mar 2004 00:45:02 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] IBGP to replace IGP X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: Thread-Topic: [Idr] IBGP to replace IGP Thread-Index: AcQLDvACp+BWjy6mS8K5VcYyQ713IwACe0zw From: "Michel Py" To: "John Smith" , Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Mar 2004 21:44:33 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > John Smith wrote: > Moreover, it is *mandatory* to run BGP on all the routers > if we are transiting traffic, because if a router isn't > speaking BGP then it cant forward BGP traffic.=20 Where does this come from? I have configured transit networks with an IGP (OSPF in my case, but some will prefer IS-IS) in the core and BGP at the edge. What about this animal called NLRI? Michel. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 16 00:48:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27189 for ; Tue, 16 Mar 2004 00:48:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37RH-0006Ho-Bq for idr-archive@odin.ietf.org; Tue, 16 Mar 2004 00:48:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2G5mVDM024158 for idr-archive@odin.ietf.org; Tue, 16 Mar 2004 00:48:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37RH-0006HZ-5v for idr-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 00:48:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27177 for ; Tue, 16 Mar 2004 00:48:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37RE-0003sl-00 for idr-web-archive@ietf.org; Tue, 16 Mar 2004 00:48:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B37QL-0003pt-00 for idr-web-archive@ietf.org; Tue, 16 Mar 2004 00:47:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B37Px-0003mZ-00; Tue, 16 Mar 2004 00:47:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37Pp-00069Z-1z; Tue, 16 Mar 2004 00:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37PI-000693-KJ for idr@optimus.ietf.org; Tue, 16 Mar 2004 00:46:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27121 for ; Tue, 16 Mar 2004 00:46:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37PF-0003lw-00 for idr@ietf.org; Tue, 16 Mar 2004 00:46:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B37OP-0003j3-00 for idr@ietf.org; Tue, 16 Mar 2004 00:45:34 -0500 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1B37Nu-0003fv-00 for idr@ietf.org; Tue, 16 Mar 2004 00:45:02 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] IBGP to replace IGP X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: Thread-Topic: [Idr] IBGP to replace IGP Thread-Index: AcQLDvACp+BWjy6mS8K5VcYyQ713IwACe0zw From: "Michel Py" To: "John Smith" , Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Mar 2004 21:44:33 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > John Smith wrote: > Moreover, it is *mandatory* to run BGP on all the routers > if we are transiting traffic, because if a router isn't > speaking BGP then it cant forward BGP traffic.=20 Where does this come from? I have configured transit networks with an IGP (OSPF in my case, but some will prefer IS-IS) in the core and BGP at the edge. What about this animal called NLRI? Michel. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 16 01:02:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27623 for ; Tue, 16 Mar 2004 01:02:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37eq-0004qX-00 for idr-archive@ietf.org; Tue, 16 Mar 2004 01:02:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B37dy-0004me-00 for idr-archive@ietf.org; Tue, 16 Mar 2004 01:01:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B37dP-0004ii-00; Tue, 16 Mar 2004 01:01:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37dN-0006u5-ML; Tue, 16 Mar 2004 01:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37cz-0006tO-1S for idr@optimus.ietf.org; Tue, 16 Mar 2004 01:00:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27563 for ; Tue, 16 Mar 2004 01:00:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37cw-0004hr-00 for idr@ietf.org; Tue, 16 Mar 2004 01:00:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B37c2-0004dm-00 for idr@ietf.org; Tue, 16 Mar 2004 00:59:39 -0500 Received: from web25107.mail.ukl.yahoo.com ([217.12.10.55]) by ietf-mx with smtp (Exim 4.12) id 1B37bY-0004Zg-00 for idr@ietf.org; Tue, 16 Mar 2004 00:59:09 -0500 Message-ID: <20040316055839.18764.qmail@web25107.mail.ukl.yahoo.com> Received: from [203.200.20.226] by web25107.mail.ukl.yahoo.com via HTTP; Tue, 16 Mar 2004 05:58:39 GMT From: =?iso-8859-1?q?John=20Smith?= Subject: RE: [Idr] IBGP to replace IGP To: michel@arneill-py.sacramento.ca.us Cc: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 05:58:39 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Michel, > Where does this come from? I have configured transit networks with an > IGP (OSPF in my case, but some will prefer IS-IS) in the core and BGP at > the edge. What about this animal called NLRI? Say your edge BGP speaker (R1) learns 10.0.0.0/8 from some other EBGP router (NH1). It advertises the same to the other edge (R2) BGP router (which resides in the other corner of the same AS) with the NEXT_HOP NH1. Now you have IGPs running in the core so all the routers are aware of how they can reach NH1. When data traffic comes on the BGP router R2, it looks at its FIB and determines that it needs to forward the packet to one of your core routers in between the path to reach NH1. When the packet comes to that core router, there isnt any information about 10.0.0.0/8 on that router. How is then that packet forwarded. One can use default routes on the core IGP speaking routers, but that isnt a good solution and can easily lead to routing loops/black holes. Hope i made my case clear. Regards, Smith ___________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 16 01:03:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27646 for ; Tue, 16 Mar 2004 01:03:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37eu-000791-AR for idr-archive@odin.ietf.org; Tue, 16 Mar 2004 01:02:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2G62aEt027457 for idr-archive@odin.ietf.org; Tue, 16 Mar 2004 01:02:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37eu-00078m-6P for idr-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 01:02:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27633 for ; Tue, 16 Mar 2004 01:02:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37eq-0004qd-00 for idr-web-archive@ietf.org; Tue, 16 Mar 2004 01:02:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B37dy-0004ml-00 for idr-web-archive@ietf.org; Tue, 16 Mar 2004 01:01:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B37dP-0004ii-00; Tue, 16 Mar 2004 01:01:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37dN-0006u5-ML; Tue, 16 Mar 2004 01:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37cz-0006tO-1S for idr@optimus.ietf.org; Tue, 16 Mar 2004 01:00:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27563 for ; Tue, 16 Mar 2004 01:00:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37cw-0004hr-00 for idr@ietf.org; Tue, 16 Mar 2004 01:00:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B37c2-0004dm-00 for idr@ietf.org; Tue, 16 Mar 2004 00:59:39 -0500 Received: from web25107.mail.ukl.yahoo.com ([217.12.10.55]) by ietf-mx with smtp (Exim 4.12) id 1B37bY-0004Zg-00 for idr@ietf.org; Tue, 16 Mar 2004 00:59:09 -0500 Message-ID: <20040316055839.18764.qmail@web25107.mail.ukl.yahoo.com> Received: from [203.200.20.226] by web25107.mail.ukl.yahoo.com via HTTP; Tue, 16 Mar 2004 05:58:39 GMT From: =?iso-8859-1?q?John=20Smith?= Subject: RE: [Idr] IBGP to replace IGP To: michel@arneill-py.sacramento.ca.us Cc: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 05:58:39 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Michel, > Where does this come from? I have configured transit networks with an > IGP (OSPF in my case, but some will prefer IS-IS) in the core and BGP at > the edge. What about this animal called NLRI? Say your edge BGP speaker (R1) learns 10.0.0.0/8 from some other EBGP router (NH1). It advertises the same to the other edge (R2) BGP router (which resides in the other corner of the same AS) with the NEXT_HOP NH1. Now you have IGPs running in the core so all the routers are aware of how they can reach NH1. When data traffic comes on the BGP router R2, it looks at its FIB and determines that it needs to forward the packet to one of your core routers in between the path to reach NH1. When the packet comes to that core router, there isnt any information about 10.0.0.0/8 on that router. How is then that packet forwarded. One can use default routes on the core IGP speaking routers, but that isnt a good solution and can easily lead to routing loops/black holes. Hope i made my case clear. Regards, Smith ___________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 16 01:03:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27699 for ; Tue, 16 Mar 2004 01:03:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37fu-0004vj-00 for idr-archive@ietf.org; Tue, 16 Mar 2004 01:03:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B37ev-0004rN-00 for idr-archive@ietf.org; Tue, 16 Mar 2004 01:02:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B37eK-0004n4-00; Tue, 16 Mar 2004 01:02:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37eM-00071R-6M; Tue, 16 Mar 2004 01:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37dy-00070k-LW for idr@optimus.ietf.org; Tue, 16 Mar 2004 01:01:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27592 for ; Tue, 16 Mar 2004 01:01:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37dv-0004mG-00 for idr@ietf.org; Tue, 16 Mar 2004 01:01:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B37cx-0004i6-00 for idr@ietf.org; Tue, 16 Mar 2004 01:00:35 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37cK-0004c5-00 for idr@ietf.org; Tue, 16 Mar 2004 00:59:56 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2G5xOB14039; Tue, 16 Mar 2004 07:59:24 +0200 From: Pekka Savola To: =?iso-8859-1?q?John=20Smith?= cc: idr@ietf.org Subject: Re: [Idr] IBGP to replace IGP In-Reply-To: <20040316042412.36359.qmail@web25108.mail.ukl.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 07:59:24 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 16 Mar 2004, John Smith wrote: > Cant we do away with IGPs (say in some small networks) and run only IBGP there? How do you route point-to-point and loopback addresses if not with IGP? Using static routes? :) Otherwise, yes, IBGP has mostly replaced IGP especially wrt. external prefixes and that's a good thing. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 16 01:04:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27726 for ; Tue, 16 Mar 2004 01:04:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37fx-0007B2-Qt for idr-archive@odin.ietf.org; Tue, 16 Mar 2004 01:03:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2G63fDl027582 for idr-archive@odin.ietf.org; Tue, 16 Mar 2004 01:03:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37fx-0007An-Kz for idr-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 01:03:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27708 for ; Tue, 16 Mar 2004 01:03:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37fu-0004vr-00 for idr-web-archive@ietf.org; Tue, 16 Mar 2004 01:03:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B37ew-0004rU-00 for idr-web-archive@ietf.org; Tue, 16 Mar 2004 01:02:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B37eK-0004n4-00; Tue, 16 Mar 2004 01:02:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37eM-00071R-6M; Tue, 16 Mar 2004 01:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37dy-00070k-LW for idr@optimus.ietf.org; Tue, 16 Mar 2004 01:01:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27592 for ; Tue, 16 Mar 2004 01:01:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37dv-0004mG-00 for idr@ietf.org; Tue, 16 Mar 2004 01:01:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B37cx-0004i6-00 for idr@ietf.org; Tue, 16 Mar 2004 01:00:35 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37cK-0004c5-00 for idr@ietf.org; Tue, 16 Mar 2004 00:59:56 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2G5xOB14039; Tue, 16 Mar 2004 07:59:24 +0200 From: Pekka Savola To: =?iso-8859-1?q?John=20Smith?= cc: idr@ietf.org Subject: Re: [Idr] IBGP to replace IGP In-Reply-To: <20040316042412.36359.qmail@web25108.mail.ukl.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 07:59:24 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 16 Mar 2004, John Smith wrote: > Cant we do away with IGPs (say in some small networks) and run only IBGP there? How do you route point-to-point and loopback addresses if not with IGP? Using static routes? :) Otherwise, yes, IBGP has mostly replaced IGP especially wrt. external prefixes and that's a good thing. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Mar 18 06:31:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03902 for ; Thu, 18 Mar 2004 06:31:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3vk7-0004hr-00 for idr-archive@ietf.org; Thu, 18 Mar 2004 06:31:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3vj9-0004ar-00 for idr-archive@ietf.org; Thu, 18 Mar 2004 06:30:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3viN-0004Tr-00; Thu, 18 Mar 2004 06:29:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vht-0004GS-Sd; Thu, 18 Mar 2004 06:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vhI-0004G5-7r for idr@optimus.ietf.org; Thu, 18 Mar 2004 06:28:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03754 for ; Thu, 18 Mar 2004 06:28:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3vhE-0004LZ-00 for idr@ietf.org; Thu, 18 Mar 2004 06:28:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3vgG-0004Ee-00 for idr@ietf.org; Thu, 18 Mar 2004 06:27:21 -0500 Received: from web21005.mail.yahoo.com ([216.136.227.59]) by ietf-mx with smtp (Exim 4.12) id 1B3vfV-00047s-00 for idr@ietf.org; Thu, 18 Mar 2004 06:26:33 -0500 Message-ID: <20040318112633.15547.qmail@web21005.mail.yahoo.com> Received: from [203.200.20.226] by web21005.mail.yahoo.com via HTTP; Thu, 18 Mar 2004 06:26:33 EST From: Hunju Park To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Idr] BGP Marker in the Header Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 06:26:33 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi, What is the need for the BGP Marker (16 bytes) containing all FFs. It is said that it was used at times for security but i dont think its valid anymore. If anybody wants security then he can use TCP-MD5. Any clues, Park P.S. I went through the IDR archives before posting this and couldnt find any explanation for this! Infact,this question was raised a long time back, but nobody answered this. ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Mar 18 06:31:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03939 for ; Thu, 18 Mar 2004 06:31:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vkC-0004SM-Ss for idr-archive@odin.ietf.org; Thu, 18 Mar 2004 06:31:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IBVOmj017124 for idr-archive@odin.ietf.org; Thu, 18 Mar 2004 06:31:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vkC-0004S7-NE for idr-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 06:31:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03919 for ; Thu, 18 Mar 2004 06:31:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3vk8-0004hw-00 for idr-web-archive@ietf.org; Thu, 18 Mar 2004 06:31:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3vjA-0004ay-00 for idr-web-archive@ietf.org; Thu, 18 Mar 2004 06:30:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3viN-0004Tr-00; Thu, 18 Mar 2004 06:29:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vht-0004GS-Sd; Thu, 18 Mar 2004 06:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vhI-0004G5-7r for idr@optimus.ietf.org; Thu, 18 Mar 2004 06:28:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03754 for ; Thu, 18 Mar 2004 06:28:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3vhE-0004LZ-00 for idr@ietf.org; Thu, 18 Mar 2004 06:28:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3vgG-0004Ee-00 for idr@ietf.org; Thu, 18 Mar 2004 06:27:21 -0500 Received: from web21005.mail.yahoo.com ([216.136.227.59]) by ietf-mx with smtp (Exim 4.12) id 1B3vfV-00047s-00 for idr@ietf.org; Thu, 18 Mar 2004 06:26:33 -0500 Message-ID: <20040318112633.15547.qmail@web21005.mail.yahoo.com> Received: from [203.200.20.226] by web21005.mail.yahoo.com via HTTP; Thu, 18 Mar 2004 06:26:33 EST From: Hunju Park To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Idr] BGP Marker in the Header Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 06:26:33 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi, What is the need for the BGP Marker (16 bytes) containing all FFs. It is said that it was used at times for security but i dont think its valid anymore. If anybody wants security then he can use TCP-MD5. Any clues, Park P.S. I went through the IDR archives before posting this and couldnt find any explanation for this! Infact,this question was raised a long time back, but nobody answered this. ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Mar 18 10:32:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19799 for ; Thu, 18 Mar 2004 10:32:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3zVA-0005xP-00 for idr-archive@ietf.org; Thu, 18 Mar 2004 10:32:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3zTU-0005gX-00 for idr-archive@ietf.org; Thu, 18 Mar 2004 10:30:27 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3zS2-0005Op-00; Thu, 18 Mar 2004 10:28:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3zBO-0005mj-0R; Thu, 18 Mar 2004 10:11:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zAn-0000na-Jx; Thu, 18 Mar 2004 10:11:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zAF-0000e5-DL for idr@optimus.ietf.org; Thu, 18 Mar 2004 10:10:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16965 for ; Thu, 18 Mar 2004 10:10:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3zAD-00041T-00 for idr@ietf.org; Thu, 18 Mar 2004 10:10:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3z99-0003ki-00 for idr@ietf.org; Thu, 18 Mar 2004 10:09:24 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1B3z7m-0003H6-00 for idr@ietf.org; Thu, 18 Mar 2004 10:07:58 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i2IF7Pl26985 for ; Thu, 18 Mar 2004 10:07:25 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Mar 2004 10:07:26 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A88BA53@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: idr@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Idr] FW: BGP MIB v1 Review Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 10:07:23 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, March 17, 2004 3:25 PM To: 'Wijnen, Bert (Bert)' Cc: 'Susan Hares'; 'Jeffrey Haas' Subject: BGP MIB v1 Review hi I focused more of my energy into reviewing the delta from the previous version as appose to the older content. I figured we should focus our efforts on getting version 2 of the MIB correct. Issues ------ 1. Need to update copyright dates to 2004 2. In the description of bgpPeerIdentifier and bgpPeerNegotiatedVersion the "should" should be "MUST". 3. The second occurrences of 'should' in bgpPeerNegotiatedVersion is an interesting case as the value was never restricted in the initial version of the MIB, yet you are trying to define what a legal value is in the text. Clarifying where the 'legal' definition is coming from might be helpful. 4. The description for bgp4PathAttrAtomicAggregate is worrisome, but I suspect we are not actually changing the behaviour as drastically as it sounds. I am assuming that the NLRI stuff does not have anything to do with the MIB and this behaviour is described elsewhere. I would suggest rewording it to say: "This object indicates whether or not a system has selected a less specific route without selecting a more specific route. If the ATOMIC_AGGREGATE attribute is present in the Path Attributes then this object MUST have a value of 'lessSpecificRouteNotSelected'. If the ATOMIC_AGGREGATE attribute is missing in the Path Attributes then this object MUST have a value of 'lessSpecificRouteSelected'. Note that ATOMIC_AGGREGATE has been deprecated in the BGP specification." Note we should also add a REFERENCE clause to the BGP specification. 5. In the definitions of the Notifications, we should replace "This object deprecates " with "This Notification replaces the Notification." On the other end, replace "This object has been deprecated in favor of " with "This Notification has been replaced by the Notification. 6. There is a line "--- XXX TODO ..." within the reference section that looks like it should be removed or replaced with an RFC editor instruction. 7. There are no references in the text to RFC1901, RFC2574, RFC2576, RFC3411, RFC3413, RFC3415, RFC3416 or RFC3417 within the text. These need to be removed. Non-gating Issues ---------- 1. I'm assuming the fact that the behaviour of several counters has changed has been discussed and is considered acceptable. I'm personally not sure it is the right thing to do. 2. The text describing behaviour of bgpPeerHoldTimer and bgpPeerKeepAlive is rather passive. This should definitely changed in version 2 or the MIB, but is probable ok for this version. Example "If the value is zero (0), the Hold Timer has either not been established with the peer, or, the value of bgpPeerHoldTimeConfigured is zero (0)." versus " If the Hold Timer has not been established with the peer this object MUST have a value of (0). If the bgpPeerHoldTimeConfigured has a value of (0), then this object MUST have a value of (0)." Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Mar 18 10:33:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19954 for ; Thu, 18 Mar 2004 10:33:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zVY-000644-BD for idr-archive@odin.ietf.org; Thu, 18 Mar 2004 10:32:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IFWIWk023285 for idr-archive@odin.ietf.org; Thu, 18 Mar 2004 10:32:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zVK-00063H-KA for idr-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 10:32:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19827 for ; Thu, 18 Mar 2004 10:32:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3zVC-0005xi-00 for idr-web-archive@ietf.org; Thu, 18 Mar 2004 10:32:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3zTX-0005gz-00 for idr-web-archive@ietf.org; Thu, 18 Mar 2004 10:30:29 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3zS2-0005Op-00; Thu, 18 Mar 2004 10:28:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3zBO-0005mj-0R; Thu, 18 Mar 2004 10:11:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zAn-0000na-Jx; Thu, 18 Mar 2004 10:11:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zAF-0000e5-DL for idr@optimus.ietf.org; Thu, 18 Mar 2004 10:10:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16965 for ; Thu, 18 Mar 2004 10:10:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3zAD-00041T-00 for idr@ietf.org; Thu, 18 Mar 2004 10:10:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3z99-0003ki-00 for idr@ietf.org; Thu, 18 Mar 2004 10:09:24 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1B3z7m-0003H6-00 for idr@ietf.org; Thu, 18 Mar 2004 10:07:58 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i2IF7Pl26985 for ; Thu, 18 Mar 2004 10:07:25 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Mar 2004 10:07:26 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A88BA53@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: idr@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Idr] FW: BGP MIB v1 Review Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 10:07:23 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, March 17, 2004 3:25 PM To: 'Wijnen, Bert (Bert)' Cc: 'Susan Hares'; 'Jeffrey Haas' Subject: BGP MIB v1 Review hi I focused more of my energy into reviewing the delta from the previous version as appose to the older content. I figured we should focus our efforts on getting version 2 of the MIB correct. Issues ------ 1. Need to update copyright dates to 2004 2. In the description of bgpPeerIdentifier and bgpPeerNegotiatedVersion the "should" should be "MUST". 3. The second occurrences of 'should' in bgpPeerNegotiatedVersion is an interesting case as the value was never restricted in the initial version of the MIB, yet you are trying to define what a legal value is in the text. Clarifying where the 'legal' definition is coming from might be helpful. 4. The description for bgp4PathAttrAtomicAggregate is worrisome, but I suspect we are not actually changing the behaviour as drastically as it sounds. I am assuming that the NLRI stuff does not have anything to do with the MIB and this behaviour is described elsewhere. I would suggest rewording it to say: "This object indicates whether or not a system has selected a less specific route without selecting a more specific route. If the ATOMIC_AGGREGATE attribute is present in the Path Attributes then this object MUST have a value of 'lessSpecificRouteNotSelected'. If the ATOMIC_AGGREGATE attribute is missing in the Path Attributes then this object MUST have a value of 'lessSpecificRouteSelected'. Note that ATOMIC_AGGREGATE has been deprecated in the BGP specification." Note we should also add a REFERENCE clause to the BGP specification. 5. In the definitions of the Notifications, we should replace "This object deprecates " with "This Notification replaces the Notification." On the other end, replace "This object has been deprecated in favor of " with "This Notification has been replaced by the Notification. 6. There is a line "--- XXX TODO ..." within the reference section that looks like it should be removed or replaced with an RFC editor instruction. 7. There are no references in the text to RFC1901, RFC2574, RFC2576, RFC3411, RFC3413, RFC3415, RFC3416 or RFC3417 within the text. These need to be removed. Non-gating Issues ---------- 1. I'm assuming the fact that the behaviour of several counters has changed has been discussed and is considered acceptable. I'm personally not sure it is the right thing to do. 2. The text describing behaviour of bgpPeerHoldTimer and bgpPeerKeepAlive is rather passive. This should definitely changed in version 2 or the MIB, but is probable ok for this version. Example "If the value is zero (0), the Hold Timer has either not been established with the peer, or, the value of bgpPeerHoldTimeConfigured is zero (0)." versus " If the Hold Timer has not been established with the peer this object MUST have a value of (0). If the bgpPeerHoldTimeConfigured has a value of (0), then this object MUST have a value of (0)." Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Mar 18 13:27:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29119 for ; Thu, 18 Mar 2004 13:27:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B42Ew-0001Fb-00 for idr-archive@ietf.org; Thu, 18 Mar 2004 13:27:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B42E1-0001DW-00 for idr-archive@ietf.org; Thu, 18 Mar 2004 13:26:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B42Dk-0001BF-00; Thu, 18 Mar 2004 13:26:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B42Ci-0007m9-9f; Thu, 18 Mar 2004 13:25:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B42C7-0007kO-MC for idr@optimus.ietf.org; Thu, 18 Mar 2004 13:24:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29021 for ; Thu, 18 Mar 2004 13:24:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B42C4-000174-00 for idr@ietf.org; Thu, 18 Mar 2004 13:24:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B42BE-00014h-00 for idr@ietf.org; Thu, 18 Mar 2004 13:23:44 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1B42AZ-00011C-00 for idr@ietf.org; Thu, 18 Mar 2004 13:23:03 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i2IIKdbZ060237; Thu, 18 Mar 2004 13:20:39 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403181820.i2IIKdbZ060237@workhorse.fictitious.org> To: Hunju Park cc: idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] BGP Marker in the Header In-reply-to: Your message of "Thu, 18 Mar 2004 06:26:33 EST." <20040318112633.15547.qmail@web21005.mail.yahoo.com> From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 13:20:38 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <20040318112633.15547.qmail@web21005.mail.yahoo.com>, Hunju Park wri tes: > Hi, > What is the need for the BGP Marker (16 bytes) containing all FFs. It is said > that it was used at > times for security but i dont think its valid anymore. If anybody wants secur > ity then he can use > TCP-MD5. > > Any clues, > Park > > P.S. > I went through the IDR archives before posting this and couldnt find any expl > anation for this! > Infact,this question was raised a long time back, but nobody answered this. It is used to detect a horrible bug in either the sending or receiving implementation in which packet alignment has been lost. Those sort of bugs are much less common that they were a decade or more ago, but it might not hurt to keep the check in place anyway. You can't tell what sort of code you will be BGP peering with, including someone's kludged together test or monitoring code. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Mar 18 13:28:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29141 for ; Thu, 18 Mar 2004 13:28:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B42Ez-0007y5-5U for idr-archive@odin.ietf.org; Thu, 18 Mar 2004 13:27:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IIRbkv030629 for idr-archive@odin.ietf.org; Thu, 18 Mar 2004 13:27:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B42Ey-0007xw-U6 for idr-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 13:27:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29133 for ; Thu, 18 Mar 2004 13:27:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B42Ew-0001Fg-00 for idr-web-archive@ietf.org; Thu, 18 Mar 2004 13:27:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B42E2-0001Dd-00 for idr-web-archive@ietf.org; Thu, 18 Mar 2004 13:26:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B42Dk-0001BF-00; Thu, 18 Mar 2004 13:26:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B42Ci-0007m9-9f; Thu, 18 Mar 2004 13:25:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B42C7-0007kO-MC for idr@optimus.ietf.org; Thu, 18 Mar 2004 13:24:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29021 for ; Thu, 18 Mar 2004 13:24:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B42C4-000174-00 for idr@ietf.org; Thu, 18 Mar 2004 13:24:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B42BE-00014h-00 for idr@ietf.org; Thu, 18 Mar 2004 13:23:44 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1B42AZ-00011C-00 for idr@ietf.org; Thu, 18 Mar 2004 13:23:03 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i2IIKdbZ060237; Thu, 18 Mar 2004 13:20:39 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403181820.i2IIKdbZ060237@workhorse.fictitious.org> To: Hunju Park cc: idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] BGP Marker in the Header In-reply-to: Your message of "Thu, 18 Mar 2004 06:26:33 EST." <20040318112633.15547.qmail@web21005.mail.yahoo.com> From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 13:20:38 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <20040318112633.15547.qmail@web21005.mail.yahoo.com>, Hunju Park wri tes: > Hi, > What is the need for the BGP Marker (16 bytes) containing all FFs. It is said > that it was used at > times for security but i dont think its valid anymore. If anybody wants secur > ity then he can use > TCP-MD5. > > Any clues, > Park > > P.S. > I went through the IDR archives before posting this and couldnt find any expl > anation for this! > Infact,this question was raised a long time back, but nobody answered this. It is used to detect a horrible bug in either the sending or receiving implementation in which packet alignment has been lost. Those sort of bugs are much less common that they were a decade or more ago, but it might not hurt to keep the check in place anyway. You can't tell what sort of code you will be BGP peering with, including someone's kludged together test or monitoring code. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Mar 19 14:36:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17754 for ; Fri, 19 Mar 2004 14:36:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Pn1-00011y-00 for idr-archive@ietf.org; Fri, 19 Mar 2004 14:36:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Pm8-0000wy-00 for idr-archive@ietf.org; Fri, 19 Mar 2004 14:35:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4PlM-0000rJ-00; Fri, 19 Mar 2004 14:34:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Pkn-0000AL-MA; Fri, 19 Mar 2004 14:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Pk7-0008W9-5c for idr@optimus.ietf.org; Fri, 19 Mar 2004 14:33:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17503 for ; Fri, 19 Mar 2004 14:33:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Pk4-0000hK-00 for idr@ietf.org; Fri, 19 Mar 2004 14:33:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Pj5-0000Z8-00 for idr@ietf.org; Fri, 19 Mar 2004 14:32:15 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B4Pi7-0000QS-00; Fri, 19 Mar 2004 14:31:16 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4Phx-000PyS-Ar; Fri, 19 Mar 2004 19:31:05 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <139156231539.20040319113030@psg.com> To: idr@ietf.org, rtg-dir@ietf.org, ops-dir@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Mar 2004 11:30:30 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks- Below is the IETF LC announcement that should have made it to several lists and hasn't yet http://www1.ietf.org/mail-archive/ietf-announce/Current/msg29135.html -- Alex http://www.psg.com/~zinin/ > * To: IETF-Announce :; > * Subject: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard > * From: The IESG > * Date: Tue, 16 Mar 2004 16:29:24 -0500 > * Cc: idr at ietf.org;rtg-dir at ietf.org; > * Reply-to: iesg at ietf.org > * Sender: owner-ietf-announce at ietf.org > > The IESG has received a request from the Inter-Domain Routing WG to consider > the following set of documents updating the Border Gateway Protocol 4 > specification. > > BGP4 protocol-related documents: > > - 'A Border Gateway Protocol 4 (BGP-4) ' > as a Draft Standard > - 'BGP Security Vulnerabilities Analysis ' > as an Informational RFC > - 'BGP-4 Protocol Analysis ' > as an Informational RFC > - 'Experience with the BGP-4 Protocol ' > as an Informational RFC > > BGP4 MIB-related documents: > > - 'Definitions of Managed Objects for the Fourth Version of Border Gateway > Protocol (BGP-4) ' > as a Proposed Standard > > Implementation reports: > > - 'BGP 4 Implementation Report ' > as an Informational RFC > - 'BGP MIB V1 implementation survey ' > as an Informational RFC > > The documents above satisfy the standardization criteria for Routing > Protocols described in RFC 1264. > > Since draft-ietf-idr-bgp4-23.txt specifies the TCP MD5 Signature Option (RFC > 2385), which is a Proposed Standard, as the mandatory to implement > authentication mechanism, the IESG is planning to apply the variance > procedure per RFC 2026 to allow the BGP4 protocol specification at the Draft > Standard level to have a normative reference to RFC 2385. The variance > prodedure request is documented in the following document: > > - 'Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC > 2385) and the BGP-4 Specification ' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2004-04-13. > > The files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-23.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-vuln-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-analysis-04.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol- > 03.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-13.txt > http://www.ietf.org/internet-drafts/draft-iesg-tcpmd5app-00.txt > > Implementation Reports can be accessed at > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-implementation-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-mibagent-survey-00.tx _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Mar 19 14:37:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17798 for ; Fri, 19 Mar 2004 14:37:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Pn7-0000Xa-7U for idr-archive@odin.ietf.org; Fri, 19 Mar 2004 14:36:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JJaOMf002077 for idr-archive@odin.ietf.org; Fri, 19 Mar 2004 14:36:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Pn6-0000XK-7V for idr-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 14:36:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17774 for ; Fri, 19 Mar 2004 14:36:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Pn2-00012C-00 for idr-web-archive@ietf.org; Fri, 19 Mar 2004 14:36:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Pm9-0000x7-00 for idr-web-archive@ietf.org; Fri, 19 Mar 2004 14:35:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4PlM-0000rJ-00; Fri, 19 Mar 2004 14:34:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Pkn-0000AL-MA; Fri, 19 Mar 2004 14:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Pk7-0008W9-5c for idr@optimus.ietf.org; Fri, 19 Mar 2004 14:33:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17503 for ; Fri, 19 Mar 2004 14:33:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Pk4-0000hK-00 for idr@ietf.org; Fri, 19 Mar 2004 14:33:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Pj5-0000Z8-00 for idr@ietf.org; Fri, 19 Mar 2004 14:32:15 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B4Pi7-0000QS-00; Fri, 19 Mar 2004 14:31:16 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4Phx-000PyS-Ar; Fri, 19 Mar 2004 19:31:05 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <139156231539.20040319113030@psg.com> To: idr@ietf.org, rtg-dir@ietf.org, ops-dir@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Mar 2004 11:30:30 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks- Below is the IETF LC announcement that should have made it to several lists and hasn't yet http://www1.ietf.org/mail-archive/ietf-announce/Current/msg29135.html -- Alex http://www.psg.com/~zinin/ > * To: IETF-Announce :; > * Subject: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard > * From: The IESG > * Date: Tue, 16 Mar 2004 16:29:24 -0500 > * Cc: idr at ietf.org;rtg-dir at ietf.org; > * Reply-to: iesg at ietf.org > * Sender: owner-ietf-announce at ietf.org > > The IESG has received a request from the Inter-Domain Routing WG to consider > the following set of documents updating the Border Gateway Protocol 4 > specification. > > BGP4 protocol-related documents: > > - 'A Border Gateway Protocol 4 (BGP-4) ' > as a Draft Standard > - 'BGP Security Vulnerabilities Analysis ' > as an Informational RFC > - 'BGP-4 Protocol Analysis ' > as an Informational RFC > - 'Experience with the BGP-4 Protocol ' > as an Informational RFC > > BGP4 MIB-related documents: > > - 'Definitions of Managed Objects for the Fourth Version of Border Gateway > Protocol (BGP-4) ' > as a Proposed Standard > > Implementation reports: > > - 'BGP 4 Implementation Report ' > as an Informational RFC > - 'BGP MIB V1 implementation survey ' > as an Informational RFC > > The documents above satisfy the standardization criteria for Routing > Protocols described in RFC 1264. > > Since draft-ietf-idr-bgp4-23.txt specifies the TCP MD5 Signature Option (RFC > 2385), which is a Proposed Standard, as the mandatory to implement > authentication mechanism, the IESG is planning to apply the variance > procedure per RFC 2026 to allow the BGP4 protocol specification at the Draft > Standard level to have a normative reference to RFC 2385. The variance > prodedure request is documented in the following document: > > - 'Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC > 2385) and the BGP-4 Specification ' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2004-04-13. > > The files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-23.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-vuln-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-analysis-04.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol- > 03.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-13.txt > http://www.ietf.org/internet-drafts/draft-iesg-tcpmd5app-00.txt > > Implementation Reports can be accessed at > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-implementation-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-mibagent-survey-00.tx _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 22 04:59:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13440 for ; Mon, 22 Mar 2004 04:59:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5MDX-0000WH-00 for idr-archive@ietf.org; Mon, 22 Mar 2004 04:59:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5MCW-0000ON-00 for idr-archive@ietf.org; Mon, 22 Mar 2004 04:58:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5MC5-0000Hg-00; Mon, 22 Mar 2004 04:58:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBP-0002Ai-Jl; Mon, 22 Mar 2004 04:57:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Lfn-0002YY-TJ for idr@optimus.ietf.org; Tue, 16 Mar 2004 16:00:27 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24350; Tue, 16 Mar 2004 16:00:24 -0500 (EST) Message-Id: <200403162100.QAA24350@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-rfc2858bis-04.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 16:00:24 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Multiprotocol Extensions for BGP-4 Author(s) : T. Bates, R. Chandra, D. Katz, Y. Rekhter Filename : draft-ietf-idr-rfc2858bis-04.txt Pages : 11 Date : 2004-3-16 Currently BGP-4 is capable of carrying routing information only for IPv4. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-rfc2858bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-rfc2858bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-16162447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc2858bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc2858bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-16162447.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 22 04:59:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13469 for ; Mon, 22 Mar 2004 04:59:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5MDZ-0000Wd-00 for idr-archive@ietf.org; Mon, 22 Mar 2004 04:59:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5MCZ-0000Ot-00 for idr-archive@ietf.org; Mon, 22 Mar 2004 04:58:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5MC5-0000Hl-00; Mon, 22 Mar 2004 04:58:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBU-0002FN-3M; Mon, 22 Mar 2004 04:57:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3db9-00022t-0V for idr@optimus.ietf.org; Wed, 17 Mar 2004 11:08:51 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15348; Wed, 17 Mar 2004 11:08:46 -0500 (EST) Message-Id: <200403171608.LAA15348@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-aspath-orf-06.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Mar 2004 11:08:46 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Aspath Based Outbound Route Filter for BGP-4 Author(s) : K. Patel, S. Hares Filename : draft-ietf-idr-aspath-orf-06.txt Pages : 0 Date : 2004-3-12 This document defines a new Outbound Router Filter type for BGP, termed 'Aspath Outbound Route Filter', that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-aspath-orf-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-aspath-orf-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-aspath-orf-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-17113158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-aspath-orf-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-aspath-orf-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-17113158.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 22 04:59:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13490 for ; Mon, 22 Mar 2004 04:59:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5MDb-0000Wn-00 for idr-archive@ietf.org; Mon, 22 Mar 2004 04:59:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5MCb-0000P8-00 for idr-archive@ietf.org; Mon, 22 Mar 2004 04:58:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5MC8-0000Hm-00; Mon, 22 Mar 2004 04:58:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBJ-00029l-Gi; Mon, 22 Mar 2004 04:57:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1r4L-00031S-7Q for idr@optimus.ietf.org; Fri, 12 Mar 2004 13:07:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08510 for ; Fri, 12 Mar 2004 13:07:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1r4J-0005FF-00 for idr@ietf.org; Fri, 12 Mar 2004 13:07:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1r3K-00057X-00 for idr@ietf.org; Fri, 12 Mar 2004 13:06:35 -0500 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx with smtp (Exim 4.12) id 1B1r2K-0004uQ-00 for idr@ietf.org; Fri, 12 Mar 2004 13:05:32 -0500 Received: (qmail 14604 invoked from network); 12 Mar 2004 18:04:57 -0000 Received: from 207-171-180-101.amazon.com (HELO ?10.21.134.173?) (ben@207.171.180.101) by layer8.net with SMTP; 12 Mar 2004 18:04:57 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: idr@ietf.org From: Benjamin Black Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes To: Pekka Savola X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 10:05:44 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Which one of your options leads to "this isn't something that concerns BGP"? Ben On Mar 12, 2004, at 1:13 AM, Pekka Savola wrote: > Hello, it's me again :).. > > Now that the on-list thread has apparently died, and the off-list > discussions as well, I think it would be important to understand how > to move forward, and to try to gauge whether everyone is aware of > which issue we're talking about. > > As there was a lot of confusion at first on the actual problem, I > won't try to summarize the thread, because at different times, people > probably had entirely different assumptions of the problem. > > The bottom line is this: in very many cases you cannot avoid having to > insert some some kind of discard/reject or null0 route for a specific > prefix on a router (e.g., to generate a default route to some peers). > When the next-hop of some other router, on that *same* router, goes > through that "discard" route, the next-hop is still considered valid. > This causes rather obvious BGP timeout problems. > > The non-problem is when you have to redistribute that discard route in > your routing system, whether in IGP or BGP, and the other routers > cannot tell that's it's a discard route as it's learned through a > routing protocol. This can be rather easily avoided by configuring > the discard routes everywhere, so I don't think this needs to be > solved at this point. > > Now.. what do people think about this problem -- what should we do > (pick one or multiple): > > 1) try to specify some behaviour in the bgp spec to avoid this issue; > for example: > 1.a) state that if the route towards the next-hop leads to packets > being discarded by the router, SHOULD consider the next-hop ineligible > 1.b) state that the implementation SHOULD support being able to > configure which routes to use in in the next-hop eligibility detection > process > 1.c) to be worked out later.. > 1.d) something else -- what? > > 2) defer the solution until later > > 3) clarify the operational problem, to make the reader/implementer > aware of it > 3.a) in this revision of bgp spec > 3.b) in some other documents(s) > > 4) other -- what ? > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 22 05:00:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13543 for ; Mon, 22 Mar 2004 05:00:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5MEA-0000bM-00 for idr-archive@ietf.org; Mon, 22 Mar 2004 05:00:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5MDC-0000TT-00 for idr-archive@ietf.org; Mon, 22 Mar 2004 04:59:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5MC5-0000Hh-00; Mon, 22 Mar 2004 04:58:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBK-0002A4-Tx; Mon, 22 Mar 2004 04:57:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1tHg-0006jL-AT for idr@optimus.ietf.org; Fri, 12 Mar 2004 15:29:32 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17097; Fri, 12 Mar 2004 15:29:30 -0500 (EST) Message-Id: <200403122029.PAA17097@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-gr-survey-01.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 15:29:29 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Graceful Restart - Implementation Survey Author(s) : J. Scudder Filename : draft-ietf-idr-bgp-gr-survey-01.txt Pages : 10 Date : 2004-3-12 This document provides a survey of BGP-4 Graceful Restart implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-gr-survey-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-gr-survey-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-gr-survey-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-12152622.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-gr-survey-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-gr-survey-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-12152622.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 22 05:00:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13564 for ; Mon, 22 Mar 2004 05:00:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5MEB-0000bW-00 for idr-archive@ietf.org; Mon, 22 Mar 2004 05:00:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5MDD-0000Tj-00 for idr-archive@ietf.org; Mon, 22 Mar 2004 04:59:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5MC5-0000Hj-00; Mon, 22 Mar 2004 04:58:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBS-0002CM-8C; Mon, 22 Mar 2004 04:57:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3M8J-0004kH-8o for idr@optimus.ietf.org; Tue, 16 Mar 2004 16:29:55 -0500 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26447 for ; Tue, 16 Mar 2004 16:29:52 -0500 (EST) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1B3M7o-0004hU-Uk; Tue, 16 Mar 2004 16:29:24 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: idr@ietf.org;rtg-dir@ietf.org;; From: The IESG Reply-to: iesg@ietf.org Message-Id: Subject: [Idr] Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 16:29:24 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,TO_HAS_SPACES autolearn=no version=2.60 The IESG has received a request from the Inter-Domain Routing WG to consider the following set of documents updating the Border Gateway Protocol 4 specification. BGP4 protocol-related documents: - 'A Border Gateway Protocol 4 (BGP-4) ' as a Draft Standard - 'BGP Security Vulnerabilities Analysis ' as an Informational RFC - 'BGP-4 Protocol Analysis ' as an Informational RFC - 'Experience with the BGP-4 Protocol ' as an Informational RFC BGP4 MIB-related documents: - 'Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4) ' as a Proposed Standard Implementation reports: - 'BGP 4 Implementation Report ' as an Informational RFC - 'BGP MIB V1 implementation survey ' as an Informational RFC The documents above satisfy the standardization criteria for Routing Protocols described in RFC 1264. Since draft-ietf-idr-bgp4-23.txt specifies the TCP MD5 Signature Option (RFC 2385), which is a Proposed Standard, as the mandatory to implement authentication mechanism, the IESG is planning to apply the variance procedure per RFC 2026 to allow the BGP4 protocol specification at the Draft Standard level to have a normative reference to RFC 2385. The variance prodedure request is documented in the following document: - 'Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-04-13. The files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-23.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-vuln-00.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-analysis-04.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol- 03.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-13.txt http://www.ietf.org/internet-drafts/draft-iesg-tcpmd5app-00.txt Implementation Reports can be accessed at http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-implementation-00.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-mibagent-survey-00.tx _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 22 05:00:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13585 for ; Mon, 22 Mar 2004 05:00:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5MED-0000bj-00 for idr-archive@ietf.org; Mon, 22 Mar 2004 05:00:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5MDF-0000U0-00 for idr-archive@ietf.org; Mon, 22 Mar 2004 04:59:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5MC5-0000Hk-00; Mon, 22 Mar 2004 04:58:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBO-0002AU-Hc; Mon, 22 Mar 2004 04:57:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Lfi-0002YR-NK for idr@optimus.ietf.org; Tue, 16 Mar 2004 16:00:22 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24333; Tue, 16 Mar 2004 16:00:19 -0500 (EST) Message-Id: <200403162100.QAA24333@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-as4bytes-08.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 16:00:19 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP support for four-octet AS number space Author(s) : Q. Vohra, E. Chen Filename : draft-ietf-idr-as4bytes-08.txt Pages : 7 Date : 2004-3-16 Currently the Autonomous System number is encoded in BGP [BGP] as a two-octets field. This document describes extensions to BGP to carry the Autonomous System number as a four-octets field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-as4bytes-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-as4bytes-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-16162437.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-as4bytes-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-as4bytes-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-16162437.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 22 05:00:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13606 for ; Mon, 22 Mar 2004 05:00:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5MEE-0000bu-00 for idr-archive@ietf.org; Mon, 22 Mar 2004 05:00:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5MDG-0000UF-00 for idr-archive@ietf.org; Mon, 22 Mar 2004 04:59:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5MC8-0000Hn-00; Mon, 22 Mar 2004 04:58:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBU-0002GJ-Vh; Mon, 22 Mar 2004 04:57:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dbP-00023S-RK for idr@optimus.ietf.org; Wed, 17 Mar 2004 11:09:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15364; Wed, 17 Mar 2004 11:09:02 -0500 (EST) Message-Id: <200403171609.LAA15364@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-gr-survey-01.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Mar 2004 11:09:02 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Graceful Restart - Implementation Survey Author(s) : J. Scudder Filename : draft-ietf-idr-bgp-gr-survey-01.txt Pages : 10 Date : 2004-3-12 This document provides a survey of BGP-4 Graceful Restart implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-gr-survey-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-gr-survey-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-gr-survey-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-17113209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-gr-survey-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-gr-survey-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-17113209.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 22 05:02:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13697 for ; Mon, 22 Mar 2004 05:02:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5MGJ-0000rG-00 for idr-archive@ietf.org; Mon, 22 Mar 2004 05:02:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5MFO-0000kz-00 for idr-archive@ietf.org; Mon, 22 Mar 2004 05:01:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5MF5-0000ev-00; Mon, 22 Mar 2004 05:01:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBK-00029u-4i; Mon, 22 Mar 2004 04:57:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1tHZ-0006jE-J5 for idr@optimus.ietf.org; Fri, 12 Mar 2004 15:29:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17080; Fri, 12 Mar 2004 15:29:23 -0500 (EST) Message-Id: <200403122029.PAA17080@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-aspath-orf-06.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 15:29:23 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Aspath Based Outbound Route Filter for BGP-4 Author(s) : K. Patel, S. Hares Filename : draft-ietf-idr-aspath-orf-06.txt Pages : 0 Date : 2004-3-12 This document defines a new Outbound Router Filter type for BGP, termed 'Aspath Outbound Route Filter', that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-aspath-orf-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-aspath-orf-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-aspath-orf-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-12152611.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-aspath-orf-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-aspath-orf-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-12152611.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 22 05:48:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13463 for ; Mon, 22 Mar 2004 04:59:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5MDY-0000WR-00 for idr-archive@ietf.org; Mon, 22 Mar 2004 04:59:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5MCY-0000Od-00 for idr-archive@ietf.org; Mon, 22 Mar 2004 04:58:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5MC5-0000Hi-00; Mon, 22 Mar 2004 04:58:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBL-0002AD-Ks; Mon, 22 Mar 2004 04:57:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37nQ-0008Bo-Ov for idr@optimus.ietf.org; Tue, 16 Mar 2004 01:11:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28006 for ; Tue, 16 Mar 2004 01:11:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37nN-0005Ts-00 for idr@ietf.org; Tue, 16 Mar 2004 01:11:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B37mT-0005QA-00 for idr@ietf.org; Tue, 16 Mar 2004 01:10:26 -0500 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx with smtp (Exim 4.12) id 1B37lZ-0005Ix-00 for idr@ietf.org; Tue, 16 Mar 2004 01:09:29 -0500 Received: (qmail 84822 invoked from network); 16 Mar 2004 06:08:56 -0000 Received: from c-24-19-2-172.client.comcast.net (HELO ?192.168.0.107?) (ben@24.19.2.172) by layer8.net with SMTP; 16 Mar 2004 06:08:56 -0000 In-Reply-To: <20040316042412.36359.qmail@web25108.mail.ukl.yahoo.com> References: <20040316042412.36359.qmail@web25108.mail.ukl.yahoo.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <87D72DFF-7710-11D8-93D0-000A95DA7468@layer8.net> Content-Transfer-Encoding: 7bit Cc: idr@ietf.org From: Benjamin Black Subject: Re: [Idr] IBGP to replace IGP To: John Smith X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Mar 2004 22:09:48 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit You could certainly run BGP and statics without another protocol for the IGP, but why would you want to? Convergence times, CPU load on RPs, etc., during changes would be rather unsatisfactory. If you want to run one dynamic protocol at all costs, then what you describe below will work, and has worked for some, but people with real traffic don't waste their time with it. Ben On Mar 15, 2004, at 8:24 PM, John Smith wrote: > Hi, > > I am very clear with the concept that IGPs cannot be used to carry the > entire BGP feed as > they cant be scaled to carry so many prefixes (even assuming we add > enough TLVs to make > them carry the BGP attributes). > > What is not very clear to me is, why cant we use IBGP inside an AS to > completely do away > with IGPs. IGPs compute the best path to reach a particular neighbor > based on the link > metric. This can be achieved in BGP also, if we include a TLV to carry > the link cost. > Moreover, it is *mandatory* to run BGP on all the routers if we are > transiting traffic, > because if a router isnt speaking BGP then it cant forward BGP traffic. > > Cant we do away with IGPs (say in some small networks) and run only > IBGP there? > > Any help/clues/pointers in this regard will be really appreciated. > > Regards, > Smith > > > > > > > ___________________________________________________________ > Yahoo! Messenger - Communicate instantly..."Ping" > your friends today! Download Messenger Now > http://uk.messenger.yahoo.com/download/index.html > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 23 09:49:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00032 for ; Tue, 23 Mar 2004 09:49:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5nDg-0004Vy-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 09:49:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5nCp-0004NJ-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 09:48:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5nC8-0004Eh-00; Tue, 23 Mar 2004 09:47:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5nBG-0003tb-4m; Tue, 23 Mar 2004 09:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5n8w-0003iZ-PD for idr@optimus.ietf.org; Tue, 23 Mar 2004 09:44:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29833 for ; Tue, 23 Mar 2004 09:44:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5n8u-0003qd-00 for idr@ietf.org; Tue, 23 Mar 2004 09:44:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5n8M-0003ik-00 for idr@ietf.org; Tue, 23 Mar 2004 09:44:03 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5n7V-0003SU-00 for idr@ietf.org; Tue, 23 Mar 2004 09:43:09 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2NEgaw06545 for ; Tue, 23 Mar 2004 16:42:36 +0200 From: Pekka Savola To: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 16:42:36 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 There were no follow-ups to this and the spec has entered IETF Last Call. So, let me ask again; is there opposition for adding a clarification like: If a route's (Rte1) next-hop (Rte2) or next-hop interface would lead to packets being discarded by the same router, the route (Rte1) SHOULD be considered unresolvable. or: When considering resolvable routes or referenced interfaces, if packets through the route would be discarded by the router, the route SHOULD be considered unresolvable. in 9.1.2.1, after the two points about the route resolvability condition (as justified by below) ? ---------- Forwarded message ---------- Date: Sat, 13 Mar 2004 09:57:15 +0200 (EET) From: Pekka Savola To: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes On Fri, 12 Mar 2004, Jeffrey Haas wrote: > On Fri, Mar 12, 2004 at 04:55:04AM -0500, Curtis Villamizar wrote: > > I think the best way to handle this (from the standards standpoint) is > > to write a separate draft. The draft would provide a better "BGP next > > hop resolvable test" but does not match any current implementation so > > it does not belong in the BGP spec. If changes are made to any > > implementations they would remain fully interoperable with those that > > go by the letter of the spec without any "better resolvable test". > > I would agree with Curtis. This is an operational/deployment issue > and a draft covering such issues - and not just this one - may > be a Good Thing. There was already an off-list discussion about this, but I think I should clarify the issue here: The local router knows that route R2 is a discard/null0 route, and the nexthop of route R1 goes through R2 after the more specific route has been withdrawn from IGP. Route R1 is considered valid even though the router knows it goes through a discard route. Many consider this an implementation bug; some have already said they'd fix this, so the argument "there is no implementation" does not hold. What I want is that this gets fixed in the spec, because the spec can be read both ways. I want to avoid "local optimizations" by implementations, and fix this in the specification. It would be irresponsible to have purposely ambiguous specifications. One possible way to fix this could be, in 9.1.2.1: ---- The route resolvability condition is defined as follows. 1. A route Rte1, referencing only the intermediate network address, is considered resolvable if the Routing Table contains at least one resolvable route Rte2 that matches Rte1's intermediate network address and is not recursively resolved (directly or indi- rectly) through Rte1. If multiple matching routes are available, only the longest matching route SHOULD be considered. 2. Routes referencing interfaces (with or without intermediate addresses) are considered resolvable if the state of the refer- enced interface is up and IP processing is enabled on this inter- face. ---- Add a clarifying paragraph afterwards: If a route's (Rte1) next-hop (Rte2) or next-hop interface would lead to packets being discarded by the same router, the route (Rte1) SHOULD be considered unresolvable. or: When considering resolvable routes or referenced interfaces, if packets through the route would be discarded by the router, the route SHOULD be considered unresolvable. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 23 09:50:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00088 for ; Tue, 23 Mar 2004 09:50:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5nDj-0004CS-3p for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 09:49:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NEnZFC016138 for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 09:49:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5nDi-0004CA-VU for idr-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 09:49:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00052 for ; Tue, 23 Mar 2004 09:49:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5nDh-0004W4-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 09:49:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5nCq-0004NQ-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 09:48:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5nC8-0004Eh-00; Tue, 23 Mar 2004 09:47:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5nBG-0003tb-4m; Tue, 23 Mar 2004 09:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5n8w-0003iZ-PD for idr@optimus.ietf.org; Tue, 23 Mar 2004 09:44:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29833 for ; Tue, 23 Mar 2004 09:44:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5n8u-0003qd-00 for idr@ietf.org; Tue, 23 Mar 2004 09:44:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5n8M-0003ik-00 for idr@ietf.org; Tue, 23 Mar 2004 09:44:03 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5n7V-0003SU-00 for idr@ietf.org; Tue, 23 Mar 2004 09:43:09 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2NEgaw06545 for ; Tue, 23 Mar 2004 16:42:36 +0200 From: Pekka Savola To: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 16:42:36 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 There were no follow-ups to this and the spec has entered IETF Last Call. So, let me ask again; is there opposition for adding a clarification like: If a route's (Rte1) next-hop (Rte2) or next-hop interface would lead to packets being discarded by the same router, the route (Rte1) SHOULD be considered unresolvable. or: When considering resolvable routes or referenced interfaces, if packets through the route would be discarded by the router, the route SHOULD be considered unresolvable. in 9.1.2.1, after the two points about the route resolvability condition (as justified by below) ? ---------- Forwarded message ---------- Date: Sat, 13 Mar 2004 09:57:15 +0200 (EET) From: Pekka Savola To: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes On Fri, 12 Mar 2004, Jeffrey Haas wrote: > On Fri, Mar 12, 2004 at 04:55:04AM -0500, Curtis Villamizar wrote: > > I think the best way to handle this (from the standards standpoint) is > > to write a separate draft. The draft would provide a better "BGP next > > hop resolvable test" but does not match any current implementation so > > it does not belong in the BGP spec. If changes are made to any > > implementations they would remain fully interoperable with those that > > go by the letter of the spec without any "better resolvable test". > > I would agree with Curtis. This is an operational/deployment issue > and a draft covering such issues - and not just this one - may > be a Good Thing. There was already an off-list discussion about this, but I think I should clarify the issue here: The local router knows that route R2 is a discard/null0 route, and the nexthop of route R1 goes through R2 after the more specific route has been withdrawn from IGP. Route R1 is considered valid even though the router knows it goes through a discard route. Many consider this an implementation bug; some have already said they'd fix this, so the argument "there is no implementation" does not hold. What I want is that this gets fixed in the spec, because the spec can be read both ways. I want to avoid "local optimizations" by implementations, and fix this in the specification. It would be irresponsible to have purposely ambiguous specifications. One possible way to fix this could be, in 9.1.2.1: ---- The route resolvability condition is defined as follows. 1. A route Rte1, referencing only the intermediate network address, is considered resolvable if the Routing Table contains at least one resolvable route Rte2 that matches Rte1's intermediate network address and is not recursively resolved (directly or indi- rectly) through Rte1. If multiple matching routes are available, only the longest matching route SHOULD be considered. 2. Routes referencing interfaces (with or without intermediate addresses) are considered resolvable if the state of the refer- enced interface is up and IP processing is enabled on this inter- face. ---- Add a clarifying paragraph afterwards: If a route's (Rte1) next-hop (Rte2) or next-hop interface would lead to packets being discarded by the same router, the route (Rte1) SHOULD be considered unresolvable. or: When considering resolvable routes or referenced interfaces, if packets through the route would be discarded by the router, the route SHOULD be considered unresolvable. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 23 10:13:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01867 for ; Tue, 23 Mar 2004 10:13:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5nap-0007jj-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 10:13:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5nZz-0007bd-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 10:12:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5nZ5-0007U0-00; Tue, 23 Mar 2004 10:11:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5nWx-0000qb-3g; Tue, 23 Mar 2004 10:09:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5nRx-0007eS-41 for idr@optimus.ietf.org; Tue, 23 Mar 2004 10:04:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00771 for ; Tue, 23 Mar 2004 10:04:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5nRv-0006Ur-00 for idr@ietf.org; Tue, 23 Mar 2004 10:04:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5nR9-0006N8-00 for idr@ietf.org; Tue, 23 Mar 2004 10:03:28 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B5nQF-0006A1-00 for idr@ietf.org; Tue, 23 Mar 2004 10:02:31 -0500 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2NF1vaD007033 for ; Tue, 23 Mar 2004 07:01:58 -0800 (PST) Received: from [64.101.214.212] (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA15172 for ; Tue, 23 Mar 2004 10:01:56 -0500 (EST) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: To: idr@ietf.org From: "John G. Scudder" Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes (fwd) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 10:01:57 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I'd object to either of those since they would have the effect of forbidding certain DoS mitigation techniques, as we've already discussed. Either option is not a clarification, but a spec change. --John At 4:42 PM +0200 3/23/04, Pekka Savola wrote: >There were no follow-ups to this and the spec has entered IETF Last >Call. > >So, let me ask again; is there opposition for adding a clarification >like: > > If a route's (Rte1) next-hop (Rte2) or next-hop interface would > lead to packets being discarded by the same router, the route > (Rte1) SHOULD be considered unresolvable. > >or: > > When considering resolvable routes or referenced interfaces, > if packets through the route would be discarded by the router, > the route SHOULD be considered unresolvable. > >in 9.1.2.1, after the two points about the route resolvability >condition (as justified by below) ? ... _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 23 10:13:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01957 for ; Tue, 23 Mar 2004 10:13:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5nas-0002Tg-SV for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 10:13:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NFDUSc009521 for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 10:13:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5nas-0002TU-OD for idr-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 10:13:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01879 for ; Tue, 23 Mar 2004 10:13:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5naq-0007jq-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 10:13:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5nZz-0007bk-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 10:12:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5nZ5-0007U0-00; Tue, 23 Mar 2004 10:11:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5nWx-0000qb-3g; Tue, 23 Mar 2004 10:09:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5nRx-0007eS-41 for idr@optimus.ietf.org; Tue, 23 Mar 2004 10:04:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00771 for ; Tue, 23 Mar 2004 10:04:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5nRv-0006Ur-00 for idr@ietf.org; Tue, 23 Mar 2004 10:04:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5nR9-0006N8-00 for idr@ietf.org; Tue, 23 Mar 2004 10:03:28 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B5nQF-0006A1-00 for idr@ietf.org; Tue, 23 Mar 2004 10:02:31 -0500 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2NF1vaD007033 for ; Tue, 23 Mar 2004 07:01:58 -0800 (PST) Received: from [64.101.214.212] (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA15172 for ; Tue, 23 Mar 2004 10:01:56 -0500 (EST) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: To: idr@ietf.org From: "John G. Scudder" Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes (fwd) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 10:01:57 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I'd object to either of those since they would have the effect of forbidding certain DoS mitigation techniques, as we've already discussed. Either option is not a clarification, but a spec change. --John At 4:42 PM +0200 3/23/04, Pekka Savola wrote: >There were no follow-ups to this and the spec has entered IETF Last >Call. > >So, let me ask again; is there opposition for adding a clarification >like: > > If a route's (Rte1) next-hop (Rte2) or next-hop interface would > lead to packets being discarded by the same router, the route > (Rte1) SHOULD be considered unresolvable. > >or: > > When considering resolvable routes or referenced interfaces, > if packets through the route would be discarded by the router, > the route SHOULD be considered unresolvable. > >in 9.1.2.1, after the two points about the route resolvability >condition (as justified by below) ? ... _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 23 11:52:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09918 for ; Tue, 23 Mar 2004 11:52:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5p96-0006Pe-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 11:52:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5p47-0005Uc-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 11:47:49 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5p1t-0004zr-00; Tue, 23 Mar 2004 11:45:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5ouo-00040q-KI; Tue, 23 Mar 2004 11:38:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oti-0005rH-52; Tue, 23 Mar 2004 11:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oq9-0005ir-K9 for idr@optimus.ietf.org; Tue, 23 Mar 2004 11:33:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08722 for ; Tue, 23 Mar 2004 11:33:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5oq8-0004W0-00 for idr@ietf.org; Tue, 23 Mar 2004 11:33:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5opO-0004TQ-00 for idr@ietf.org; Tue, 23 Mar 2004 11:32:35 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1B5ooT-0004Rl-00 for idr@ietf.org; Tue, 23 Mar 2004 11:31:38 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id BEDFC2D1B28; Tue, 23 Mar 2004 08:31:34 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27617-02; Tue, 23 Mar 2004 08:31:34 -0800 (PST) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id E3A892D1B26; Tue, 23 Mar 2004 08:31:33 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id 5E6AB15D3C2; Tue, 23 Mar 2004 08:31:33 -0800 (PST) To: Pekka Savola Cc: idr@ietf.org, enke@redback.com Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes (fwd) In-Reply-To: Message from Pekka Savola of "Tue, 23 Mar 2004 16:42:36 +0200." From: Enke Chen Message-Id: <20040323163133.5E6AB15D3C2@popserv1.redback.com> X-Virus-Scanned: by amavisd-new at redback.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 08:31:32 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, Pekka: Your proposed text does not reflect the deployed code, and prohibits certain practice in use. So I do not seem it is appropriate for the base spec.. -- Enke > From: Pekka Savola > To: idr@ietf.org > Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 > routes (fwd) > Message-ID: > > There were no follow-ups to this and the spec has entered IETF Last > Call. > > So, let me ask again; is there opposition for adding a clarification > like: > > If a route's (Rte1) next-hop (Rte2) or next-hop interface would > lead to packets being discarded by the same router, the route > (Rte1) SHOULD be considered unresolvable. > > or: > > When considering resolvable routes or referenced interfaces, > if packets through the route would be discarded by the router, > the route SHOULD be considered unresolvable. > > in 9.1.2.1, after the two points about the route resolvability > condition (as justified by below) ? > > ---------- Forwarded message ---------- > Date: Sat, 13 Mar 2004 09:57:15 +0200 (EET) > From: Pekka Savola > To: idr@ietf.org > Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 > routes > > On Fri, 12 Mar 2004, Jeffrey Haas wrote: > > On Fri, Mar 12, 2004 at 04:55:04AM -0500, Curtis Villamizar wrote: > > > I think the best way to handle this (from the standards standpoint) is > > > to write a separate draft. The draft would provide a better "BGP next > > > hop resolvable test" but does not match any current implementation so > > > it does not belong in the BGP spec. If changes are made to any > > > implementations they would remain fully interoperable with those that > > > go by the letter of the spec without any "better resolvable test". > > > > I would agree with Curtis. This is an operational/deployment issue > > and a draft covering such issues - and not just this one - may > > be a Good Thing. > > There was already an off-list discussion about this, but I think I > should clarify the issue here: > > The local router knows that route R2 is a discard/null0 route, and > the nexthop of route R1 goes through R2 after the more specific > route has been withdrawn from IGP. Route R1 is considered valid > even though the router knows it goes through a discard route. > > Many consider this an implementation bug; some have already said > they'd fix this, so the argument "there is no implementation" does not > hold. > > What I want is that this gets fixed in the spec, because the spec can > be read both ways. I want to avoid "local optimizations" by > implementations, and fix this in the specification. It would be > irresponsible to have purposely ambiguous specifications. > > One possible way to fix this could be, in 9.1.2.1: > > ---- > The route resolvability condition is defined as follows. > > 1. A route Rte1, referencing only the intermediate network > address, is considered resolvable if the Routing Table contains at > least one resolvable route Rte2 that matches Rte1's intermediate > network address and is not recursively resolved (directly or indi- > rectly) through Rte1. If multiple matching routes are available, > only the longest matching route SHOULD be considered. > > 2. Routes referencing interfaces (with or without intermediate > addresses) are considered resolvable if the state of the refer- > enced interface is up and IP processing is enabled on this inter- > face. > ---- > > Add a clarifying paragraph afterwards: > > If a route's (Rte1) next-hop (Rte2) or next-hop interface would > lead to packets being discarded by the same router, the route > (Rte1) SHOULD be considered unresolvable. > > or: > > When considering resolvable routes or referenced interfaces, > if packets through the route would be discarded by the router, > the route SHOULD be considered unresolvable. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 23 11:53:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10077 for ; Tue, 23 Mar 2004 11:53:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5p98-0008Pc-M3 for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 11:52:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NGqwjm032336 for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 11:52:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5p98-0008PT-Hu for idr-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 11:52:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09939 for ; Tue, 23 Mar 2004 11:52:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5p97-0006Py-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 11:52:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5p49-0005V4-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 11:47:51 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5p1t-0004zr-00; Tue, 23 Mar 2004 11:45:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5ouo-00040q-KI; Tue, 23 Mar 2004 11:38:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oti-0005rH-52; Tue, 23 Mar 2004 11:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oq9-0005ir-K9 for idr@optimus.ietf.org; Tue, 23 Mar 2004 11:33:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08722 for ; Tue, 23 Mar 2004 11:33:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5oq8-0004W0-00 for idr@ietf.org; Tue, 23 Mar 2004 11:33:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5opO-0004TQ-00 for idr@ietf.org; Tue, 23 Mar 2004 11:32:35 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1B5ooT-0004Rl-00 for idr@ietf.org; Tue, 23 Mar 2004 11:31:38 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id BEDFC2D1B28; Tue, 23 Mar 2004 08:31:34 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27617-02; Tue, 23 Mar 2004 08:31:34 -0800 (PST) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id E3A892D1B26; Tue, 23 Mar 2004 08:31:33 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id 5E6AB15D3C2; Tue, 23 Mar 2004 08:31:33 -0800 (PST) To: Pekka Savola Cc: idr@ietf.org, enke@redback.com Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes (fwd) In-Reply-To: Message from Pekka Savola of "Tue, 23 Mar 2004 16:42:36 +0200." From: Enke Chen Message-Id: <20040323163133.5E6AB15D3C2@popserv1.redback.com> X-Virus-Scanned: by amavisd-new at redback.com Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 08:31:32 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, Pekka: Your proposed text does not reflect the deployed code, and prohibits certain practice in use. So I do not seem it is appropriate for the base spec.. -- Enke > From: Pekka Savola > To: idr@ietf.org > Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 > routes (fwd) > Message-ID: > > There were no follow-ups to this and the spec has entered IETF Last > Call. > > So, let me ask again; is there opposition for adding a clarification > like: > > If a route's (Rte1) next-hop (Rte2) or next-hop interface would > lead to packets being discarded by the same router, the route > (Rte1) SHOULD be considered unresolvable. > > or: > > When considering resolvable routes or referenced interfaces, > if packets through the route would be discarded by the router, > the route SHOULD be considered unresolvable. > > in 9.1.2.1, after the two points about the route resolvability > condition (as justified by below) ? > > ---------- Forwarded message ---------- > Date: Sat, 13 Mar 2004 09:57:15 +0200 (EET) > From: Pekka Savola > To: idr@ietf.org > Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 > routes > > On Fri, 12 Mar 2004, Jeffrey Haas wrote: > > On Fri, Mar 12, 2004 at 04:55:04AM -0500, Curtis Villamizar wrote: > > > I think the best way to handle this (from the standards standpoint) is > > > to write a separate draft. The draft would provide a better "BGP next > > > hop resolvable test" but does not match any current implementation so > > > it does not belong in the BGP spec. If changes are made to any > > > implementations they would remain fully interoperable with those that > > > go by the letter of the spec without any "better resolvable test". > > > > I would agree with Curtis. This is an operational/deployment issue > > and a draft covering such issues - and not just this one - may > > be a Good Thing. > > There was already an off-list discussion about this, but I think I > should clarify the issue here: > > The local router knows that route R2 is a discard/null0 route, and > the nexthop of route R1 goes through R2 after the more specific > route has been withdrawn from IGP. Route R1 is considered valid > even though the router knows it goes through a discard route. > > Many consider this an implementation bug; some have already said > they'd fix this, so the argument "there is no implementation" does not > hold. > > What I want is that this gets fixed in the spec, because the spec can > be read both ways. I want to avoid "local optimizations" by > implementations, and fix this in the specification. It would be > irresponsible to have purposely ambiguous specifications. > > One possible way to fix this could be, in 9.1.2.1: > > ---- > The route resolvability condition is defined as follows. > > 1. A route Rte1, referencing only the intermediate network > address, is considered resolvable if the Routing Table contains at > least one resolvable route Rte2 that matches Rte1's intermediate > network address and is not recursively resolved (directly or indi- > rectly) through Rte1. If multiple matching routes are available, > only the longest matching route SHOULD be considered. > > 2. Routes referencing interfaces (with or without intermediate > addresses) are considered resolvable if the state of the refer- > enced interface is up and IP processing is enabled on this inter- > face. > ---- > > Add a clarifying paragraph afterwards: > > If a route's (Rte1) next-hop (Rte2) or next-hop interface would > lead to packets being discarded by the same router, the route > (Rte1) SHOULD be considered unresolvable. > > or: > > When considering resolvable routes or referenced interfaces, > if packets through the route would be discarded by the router, > the route SHOULD be considered unresolvable. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 23 16:25:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01723 for ; Tue, 23 Mar 2004 16:25:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5tOa-0003aU-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 16:25:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5tMX-0003Al-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 16:23:06 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5tL9-00030e-03; Tue, 23 Mar 2004 16:21:39 -0500 Received: from datatracker.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5tGO-0002Yb-5s; Tue, 23 Mar 2004 16:16:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tFi-0007Ot-7C; Tue, 23 Mar 2004 16:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5cXD-0003qR-Lt for idr@optimus.ietf.org; Mon, 22 Mar 2004 22:24:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15203 for ; Mon, 22 Mar 2004 22:24:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5cXA-0005W9-00 for idr@ietf.org; Mon, 22 Mar 2004 22:24:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5cWC-0005OW-00 for idr@ietf.org; Mon, 22 Mar 2004 22:23:56 -0500 Received: from law9-f111.law9.hotmail.com ([64.4.9.111] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B5cVA-0005C2-00 for idr@ietf.org; Mon, 22 Mar 2004 22:22:52 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 22 Mar 2004 19:22:22 -0800 Received: from 64.38.138.134 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 23 Mar 2004 03:22:22 GMT X-Originating-IP: [64.38.138.134] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: idr@ietf.org Subject: Re: [Idr] IBGP to replace IGP Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Mar 2004 03:22:22.0522 (UTC) FILETIME=[0E5351A0:01C41086] Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 03:22:22 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS autolearn=no version=2.60 Hi Ben, It would be great if you could share some more information on the "issues" of convergence time, CPU loads, and RP overloads. >From my understanding a. it makes more sense to have 1 routing protocol as we dont have multiple daemons scheduled on the CPU. (which ofcourse is not a problem but then so is the point you mentioned below) b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we inject 0.0.0.0/0 into IGP to make unknown prefixes go to the nearest BGP node.So does that help reduce the size of your routing table? c. The cases u mention of changes, I presume you mean route-flaps. Well in that case, we eitherways have issues when IGP flaps, we eitherways wait for IGP to converge for BGP to converge etc? (I am sure "real traffic" operators do that) d. We have the benefits of not having the "global view" dependent on 1 protocol while the internal topology dependent on another e. all i need to teach the network admins is BGP :) f. Based on c, how would you say that it makes things more complicated to run iBGP only compared to IGP+0.0.0.0/0 (default originate and originate always) and all those things taken into consideration? would be great if you could help clarify this. -Smith You could certainly run BGP and statics without another protocol for the IGP, but why would you want to? Convergence times, CPU load on RPs, etc., during changes would be rather unsatisfactory. If you want to run one dynamic protocol at all costs, then what you describe below will work, and has worked for some, but people with real traffic don't waste their time with it. Ben On Mar 15, 2004, at 8:24 PM, John Smith wrote: Hi, I am very clear with the concept that IGPs cannot be used to carry the entire BGP feed as they cant be scaled to carry so many prefixes (even assuming we add enough TLVs to make them carry the BGP attributes). What is not very clear to me is, why cant we use IBGP inside an AS to completely do away with IGPs. IGPs compute the best path to reach a particular neighbor based on the link metric. This can be achieved in BGP also, if we include a TLV to carry the link cost. Moreover, it is *mandatory* to run BGP on all the routers if we are transiting traffic, because if a router isnt speaking BGP then it cant forward BGP traffic. Cant we do away with IGPs (say in some small networks) and run only IBGP there? Any help/clues/pointers in this regard will be really appreciated. Regards, Smith _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 23 16:25:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01875 for ; Tue, 23 Mar 2004 16:25:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tOd-00086P-2h for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 16:25:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NLPFDF031144 for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 16:25:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tOc-00086F-Ur for idr-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 16:25:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01739 for ; Tue, 23 Mar 2004 16:25:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5tOb-0003ak-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 16:25:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5tMY-0003Av-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 16:23:07 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5tL9-00030e-03; Tue, 23 Mar 2004 16:21:39 -0500 Received: from datatracker.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5tGO-0002Yb-5s; Tue, 23 Mar 2004 16:16:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tFi-0007Ot-7C; Tue, 23 Mar 2004 16:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5cXD-0003qR-Lt for idr@optimus.ietf.org; Mon, 22 Mar 2004 22:24:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15203 for ; Mon, 22 Mar 2004 22:24:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5cXA-0005W9-00 for idr@ietf.org; Mon, 22 Mar 2004 22:24:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5cWC-0005OW-00 for idr@ietf.org; Mon, 22 Mar 2004 22:23:56 -0500 Received: from law9-f111.law9.hotmail.com ([64.4.9.111] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B5cVA-0005C2-00 for idr@ietf.org; Mon, 22 Mar 2004 22:22:52 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 22 Mar 2004 19:22:22 -0800 Received: from 64.38.138.134 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 23 Mar 2004 03:22:22 GMT X-Originating-IP: [64.38.138.134] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: idr@ietf.org Subject: Re: [Idr] IBGP to replace IGP Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Mar 2004 03:22:22.0522 (UTC) FILETIME=[0E5351A0:01C41086] Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 03:22:22 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS autolearn=no version=2.60 Hi Ben, It would be great if you could share some more information on the "issues" of convergence time, CPU loads, and RP overloads. >From my understanding a. it makes more sense to have 1 routing protocol as we dont have multiple daemons scheduled on the CPU. (which ofcourse is not a problem but then so is the point you mentioned below) b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we inject 0.0.0.0/0 into IGP to make unknown prefixes go to the nearest BGP node.So does that help reduce the size of your routing table? c. The cases u mention of changes, I presume you mean route-flaps. Well in that case, we eitherways have issues when IGP flaps, we eitherways wait for IGP to converge for BGP to converge etc? (I am sure "real traffic" operators do that) d. We have the benefits of not having the "global view" dependent on 1 protocol while the internal topology dependent on another e. all i need to teach the network admins is BGP :) f. Based on c, how would you say that it makes things more complicated to run iBGP only compared to IGP+0.0.0.0/0 (default originate and originate always) and all those things taken into consideration? would be great if you could help clarify this. -Smith You could certainly run BGP and statics without another protocol for the IGP, but why would you want to? Convergence times, CPU load on RPs, etc., during changes would be rather unsatisfactory. If you want to run one dynamic protocol at all costs, then what you describe below will work, and has worked for some, but people with real traffic don't waste their time with it. Ben On Mar 15, 2004, at 8:24 PM, John Smith wrote: Hi, I am very clear with the concept that IGPs cannot be used to carry the entire BGP feed as they cant be scaled to carry so many prefixes (even assuming we add enough TLVs to make them carry the BGP attributes). What is not very clear to me is, why cant we use IBGP inside an AS to completely do away with IGPs. IGPs compute the best path to reach a particular neighbor based on the link metric. This can be achieved in BGP also, if we include a TLV to carry the link cost. Moreover, it is *mandatory* to run BGP on all the routers if we are transiting traffic, because if a router isnt speaking BGP then it cant forward BGP traffic. Cant we do away with IGPs (say in some small networks) and run only IBGP there? Any help/clues/pointers in this regard will be really appreciated. Regards, Smith _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 23 17:37:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07582 for ; Tue, 23 Mar 2004 17:37:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uWh-0004GC-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 17:37:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5uVh-0004C4-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 17:36:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5uVH-00048c-00; Tue, 23 Mar 2004 17:36:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uV8-0006k7-71; Tue, 23 Mar 2004 17:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uUi-0006jF-4X for idr@optimus.ietf.org; Tue, 23 Mar 2004 17:35:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07537 for ; Tue, 23 Mar 2004 17:35:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uUf-00047m-00 for idr@ietf.org; Tue, 23 Mar 2004 17:35:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5uTk-000456-00 for idr@ietf.org; Tue, 23 Mar 2004 17:34:37 -0500 Received: from law9-f45.law9.hotmail.com ([64.4.9.45] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B5uTZ-00041y-00 for idr@ietf.org; Tue, 23 Mar 2004 17:34:26 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 23 Mar 2004 14:33:55 -0800 Received: from 64.38.138.134 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 23 Mar 2004 22:33:55 GMT X-Originating-IP: [64.38.138.134] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: ben@layer8.net Cc: idr@ietf.org Subject: Re: [Idr] IBGP to replace IGP Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Mar 2004 22:33:55.0800 (UTC) FILETIME=[ED20DD80:01C41126] Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 22:33:55 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS autolearn=no version=2.60 Hi Ben, Thank you for your reply, > >a) scheduling is a minor concern. > I thought as much. CPU overload was something you mentioned. If you consider the point that OSPF carries only your IGP routes and BGP carries a lot more than that, the CPU overload problem will definately be there with BGP. But then assume we were to do away with BGP what would be the problem? would an IGP like OSPF be able to do a better job with the whole routing table? >b) certainly carrying a default helps reduce the size of the table, but >that is orthogonal to the question. it is not common practice to carry >much in the igp (meaning bgp is not redistributed into the igp), so >carrying a default really is reducing the size of your bgp ribs which is >something you can do regardless of whether you have a second protocol for >the igp. Exactly, so why add one more "protocol" to the network? What was wrong with just one? As you see, 2 can load the RP and the CPU and lead to convergence issues a lot more :) that one (but that apparently now is hardly a concern?) > >c) yes, flapping routes are a problem regardless of protocol, so you >generally want one that converges very quickly. a good link-state protocol >like ospf converges in seconds vs minutes for bgp in a reasonably complex >network. again, the igp is only carrying limited information (links and >loops being a very common scenario) and has very detailed knowledge of the >network (handling per-link metrics in bgp would get very ugly very fast) so >it can do things that are inconvenient or impossible with bgp. That is beause of the size of the routes handled by the protocol. What else do you think makes BGP slower? On the other hand, link state would have a lot more LSAs to compute the SPF against. So if my "intermediate" nodes did not have the complete table but I was to use 0.0.0.0/0 just like I do for OSPF (seems like thats what was your intended IGP) Would not BGP on the intermediate nodes (the part that was covering my IGP) converge equally fast? Incase you have a difference of opinion, please do tell me the reason. > >d) i don't know what benefits you mean. decoupling the churn of the >"global view" from the stability of your internal network supports using an >independent igp. which *may( work out if one was to use the same principals of IGP when using BGP as the IGP (0.0.0.0/0 to eBGP nodes etc?) > >e) if they can't understand ospf they shouldn't be touching the routers >anyway. > (Fine, I shall tell them that.) >f) i'm not suggesting the use of a default route. > I am considering that as a possibility. -Smith _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 23 17:38:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07613 for ; Tue, 23 Mar 2004 17:38:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uWk-00075Q-Hk for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 17:37:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NMbgdE027229 for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 17:37:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uWk-000756-D0 for idr-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 17:37:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07599 for ; Tue, 23 Mar 2004 17:37:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uWh-0004GH-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 17:37:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5uVi-0004CB-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 17:36:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5uVH-00048c-00; Tue, 23 Mar 2004 17:36:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uV8-0006k7-71; Tue, 23 Mar 2004 17:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uUi-0006jF-4X for idr@optimus.ietf.org; Tue, 23 Mar 2004 17:35:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07537 for ; Tue, 23 Mar 2004 17:35:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uUf-00047m-00 for idr@ietf.org; Tue, 23 Mar 2004 17:35:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5uTk-000456-00 for idr@ietf.org; Tue, 23 Mar 2004 17:34:37 -0500 Received: from law9-f45.law9.hotmail.com ([64.4.9.45] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B5uTZ-00041y-00 for idr@ietf.org; Tue, 23 Mar 2004 17:34:26 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 23 Mar 2004 14:33:55 -0800 Received: from 64.38.138.134 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 23 Mar 2004 22:33:55 GMT X-Originating-IP: [64.38.138.134] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: ben@layer8.net Cc: idr@ietf.org Subject: Re: [Idr] IBGP to replace IGP Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Mar 2004 22:33:55.0800 (UTC) FILETIME=[ED20DD80:01C41126] Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 22:33:55 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS autolearn=no version=2.60 Hi Ben, Thank you for your reply, > >a) scheduling is a minor concern. > I thought as much. CPU overload was something you mentioned. If you consider the point that OSPF carries only your IGP routes and BGP carries a lot more than that, the CPU overload problem will definately be there with BGP. But then assume we were to do away with BGP what would be the problem? would an IGP like OSPF be able to do a better job with the whole routing table? >b) certainly carrying a default helps reduce the size of the table, but >that is orthogonal to the question. it is not common practice to carry >much in the igp (meaning bgp is not redistributed into the igp), so >carrying a default really is reducing the size of your bgp ribs which is >something you can do regardless of whether you have a second protocol for >the igp. Exactly, so why add one more "protocol" to the network? What was wrong with just one? As you see, 2 can load the RP and the CPU and lead to convergence issues a lot more :) that one (but that apparently now is hardly a concern?) > >c) yes, flapping routes are a problem regardless of protocol, so you >generally want one that converges very quickly. a good link-state protocol >like ospf converges in seconds vs minutes for bgp in a reasonably complex >network. again, the igp is only carrying limited information (links and >loops being a very common scenario) and has very detailed knowledge of the >network (handling per-link metrics in bgp would get very ugly very fast) so >it can do things that are inconvenient or impossible with bgp. That is beause of the size of the routes handled by the protocol. What else do you think makes BGP slower? On the other hand, link state would have a lot more LSAs to compute the SPF against. So if my "intermediate" nodes did not have the complete table but I was to use 0.0.0.0/0 just like I do for OSPF (seems like thats what was your intended IGP) Would not BGP on the intermediate nodes (the part that was covering my IGP) converge equally fast? Incase you have a difference of opinion, please do tell me the reason. > >d) i don't know what benefits you mean. decoupling the churn of the >"global view" from the stability of your internal network supports using an >independent igp. which *may( work out if one was to use the same principals of IGP when using BGP as the IGP (0.0.0.0/0 to eBGP nodes etc?) > >e) if they can't understand ospf they shouldn't be touching the routers >anyway. > (Fine, I shall tell them that.) >f) i'm not suggesting the use of a default route. > I am considering that as a possibility. -Smith _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 23 17:40:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07761 for ; Tue, 23 Mar 2004 17:40:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uZW-0004UE-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 17:40:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5uYc-0004R6-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 17:39:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5uY3-0004NT-00; Tue, 23 Mar 2004 17:39:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uY1-0007Pd-Tt; Tue, 23 Mar 2004 17:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uXc-0007Ok-GK for idr@optimus.ietf.org; Tue, 23 Mar 2004 17:38:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07656 for ; Tue, 23 Mar 2004 17:38:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uXZ-0004L6-00 for idr@ietf.org; Tue, 23 Mar 2004 17:38:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5uWf-0004Fz-00 for idr@ietf.org; Tue, 23 Mar 2004 17:37:38 -0500 Received: from entmail.gnilink.net ([199.45.47.10]) by ietf-mx with esmtp (Exim 4.12) id 1B5uVg-00048a-00 for idr@ietf.org; Tue, 23 Mar 2004 17:36:36 -0500 Received: by entmail.gnilink.net with Internet Mail Service (5.5.2656.59) id ; Tue, 23 Mar 2004 17:36:04 -0500 Message-ID: <94B9091E1149D411A45C00508BACEB35071A32DC@entmail.gnilink.net> From: "Martin, Christian" To: "'john smith'" , "'idr@ietf.org'" Subject: RE: [Idr] IBGP to replace IGP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 17:35:58 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Smith, Comments inline, as I have been following this thread. >It would be great if you could share some more information on >the "issues" >of convergence time, CPU loads, and RP overloads. Convergence is typically nonlienearly proportionate to CPU load, and vice-versa, and they often feed off each other in a negative way. Network meltdowns are typically the result of routing loads disrupting topology maintenance mechanisms, thereby causing adjacency loss, which causes more routing load, which inhibits adjacency recreation, etc. I've seen networks stay in persistent "ditches" because the convergence-adjacency-divergence-adjaceny-...loop stayed closed due to loading. Not fun to have to rebuild all of your routers or reattach them to the network one by one... >From my understanding >a. it makes more sense to have 1 routing protocol as we dont >have multiple >daemons scheduled on the CPU. (which ofcourse is not a problem >but then so >is the point you mentioned below) In either case, BGP will consume the vast majority of CPU cycles. IGPs that are properly tuned in stable environments hardly tickle the CPU, let alone heat it up. Take LSA/P refresh out of the picture, and all the IGP does is send hellos and occasionally flood an LSA/P and compute an SPT once in a rare while. In the Internet, BGP is constantly processing updates and withdrawals, all day, every day. Sometimes, we see 100s of updates per minute, sometimes just a few, but they are always there. >b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we >inject 0.0.0.0/0 into IGP to make unknown prefixes go to the >nearest BGP >node.So does that help reduce the size of your routing table? Large SPs must run a full BGP load, at a minimum, to give routes to their customers. Unless you are talking about enterprise routing, we should avoid discussions of default routes... >c. The cases u mention of changes, I presume you mean >route-flaps. Well in >that case, we eitherways have issues when IGP flaps, we >eitherways wait for >IGP to converge for BGP to converge etc? (I am sure "real >traffic" operators >do that) Modern IGPs, properly tuned, converge way faster than BGP. BGP convergence is designed to be slow, so as not to place too much load on the global routing system. Since BGP carries so many routes, and since the topological density of the Internet Autonomous System graph increases every day, BGP can often take minutes to converge. IGPs take seconds, partly because they are usually lightweight. >d. We have the benefits of not having the "global view" dependent on 1 >protocol while the internal topology dependent on another This is actually a sound design. Think of the IGP as a topology discovery mechanism. All BGP routes have a next-hop. The goal of BGP is to take traffic to and from the "edges" of the network. Sometimes, the edge is within your network, like a server farm. IGPs are very good at discovering a topology and identifying the shortest path to each edge. BGP is not designed for this, and to make it do so requires considerable planning and lots of policy. >e. all i need to teach the network admins is BGP :) It is much easier to learn simple IS-IS and OSPF than BGP. Link State IGPs, when employed for topology discovery, are exceedingly simple (particularly IS-IS in a single area). BGP, on the otherhand, is a much bigger protocol that requires a lot of policy engineering in order for it to be effective. >f. Based on c, how would you say that it makes things more >complicated to >run iBGP only compared to IGP+0.0.0.0/0 (default originate and >originate >always) and all those things taken into consideration? Are you talking about running in an enterprise? Default routes will not work in any large environment for next-hop discovery of your iBGP peer IP's. Loops would abound... One of the problems with your proposal, and the primary reason this is not done, is that iBGP does not provide for transitive route dissemination in a network. All 'other' IGPs do this. This means your network topology must be highly symmetrical and/or fully meshed at layer 3 (at least in subsections) to allow for end-to-end route propagation. Unless you can employ lots of confeds (ie, each router in a confed subAS), lots of route-reflectors, or a full-mesh topology at layer 3 (and layer 2 if you consider multiaccess networks fully-meshed), then this approach is not possible. BGP also has race-condition mitigation rules that prevent a BGP route from being learned from a next-hop that is known via BGP, so injecting routes into BGP and hoping to bootstrap the next-hops would be problematic. This restriction is subtle and perhaps vendor specific, but usually, the next-hop is recursed through an IGP or connected interface. If this were possible, in any event, it would be slow-converging, as iBGP updates are typically spaced at 5 second intervals (depending on the event type). Also, you will have to peer with every interface on the device, thus forcing traffic to take certain paths that may not be the best path available, as most BGP attributes are non-accumulating (ie, u have to statically increase, say, local-pref via policy as routes propagate along a set of routers in your AS). The reality is that even if such an approach _were_ possible, the drawbacks are much more severe than simply turning on an IGP and having it discover your topology. Then, you may do what you with with iBGP. The best philosophy, IMO, is to place loopbacks and links in your IGP, and carry externals (either self-originated or from another AS) in your iBGP. Route-reflectors are useful if regionalized, as they make best path decisions before reflecting (so u want to be careful who peers with what to ensure path selection optimality). Confeds afford more control, TE, etc., but at what some claim to be a higher admin cost. Use them based on what you are trying to do. HTH, Chris >would be great if you could help clarify this. > >-Smith > > > > > >You could certainly run BGP and statics without another >protocol for the >IGP, but why would you want to? Convergence times, CPU load on >RPs, etc., >during changes would be rather unsatisfactory. If you want to run one >dynamic protocol at all costs, then what you describe below >will work, and >has worked for some, but people with real traffic don't waste >their time >with it. > > >Ben > >On Mar 15, 2004, at 8:24 PM, John Smith wrote: > > >Hi, > >I am very clear with the concept that IGPs cannot be used to carry the >entire BGP feed as >they cant be scaled to carry so many prefixes (even assuming >we add enough >TLVs to make >them carry the BGP attributes). > >What is not very clear to me is, why cant we use IBGP inside an AS to >completely do away >with IGPs. IGPs compute the best path to reach a particular >neighbor based >on the link >metric. This can be achieved in BGP also, if we include a TLV >to carry the >link cost. >Moreover, it is *mandatory* to run BGP on all the routers if we are >transiting traffic, >because if a router isnt speaking BGP then it cant forward BGP traffic. > >Cant we do away with IGPs (say in some small networks) and run >only IBGP >there? > >Any help/clues/pointers in this regard will be really appreciated. > >Regards, >Smith > >_________________________________________________________________ >Tired of spam? Get advanced junk mail protection with MSN 8. >http://join.msn.com/?page=features/junkmail > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 23 17:41:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07793 for ; Tue, 23 Mar 2004 17:41:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uZZ-0007i6-Ad for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 17:40:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NMebVk029632 for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 17:40:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uZZ-0007hr-6c for idr-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 17:40:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07776 for ; Tue, 23 Mar 2004 17:40:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uZW-0004UJ-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 17:40:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5uYd-0004RE-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 17:39:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5uY3-0004NT-00; Tue, 23 Mar 2004 17:39:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uY1-0007Pd-Tt; Tue, 23 Mar 2004 17:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uXc-0007Ok-GK for idr@optimus.ietf.org; Tue, 23 Mar 2004 17:38:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07656 for ; Tue, 23 Mar 2004 17:38:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uXZ-0004L6-00 for idr@ietf.org; Tue, 23 Mar 2004 17:38:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5uWf-0004Fz-00 for idr@ietf.org; Tue, 23 Mar 2004 17:37:38 -0500 Received: from entmail.gnilink.net ([199.45.47.10]) by ietf-mx with esmtp (Exim 4.12) id 1B5uVg-00048a-00 for idr@ietf.org; Tue, 23 Mar 2004 17:36:36 -0500 Received: by entmail.gnilink.net with Internet Mail Service (5.5.2656.59) id ; Tue, 23 Mar 2004 17:36:04 -0500 Message-ID: <94B9091E1149D411A45C00508BACEB35071A32DC@entmail.gnilink.net> From: "Martin, Christian" To: "'john smith'" , "'idr@ietf.org'" Subject: RE: [Idr] IBGP to replace IGP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 17:35:58 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Smith, Comments inline, as I have been following this thread. >It would be great if you could share some more information on >the "issues" >of convergence time, CPU loads, and RP overloads. Convergence is typically nonlienearly proportionate to CPU load, and vice-versa, and they often feed off each other in a negative way. Network meltdowns are typically the result of routing loads disrupting topology maintenance mechanisms, thereby causing adjacency loss, which causes more routing load, which inhibits adjacency recreation, etc. I've seen networks stay in persistent "ditches" because the convergence-adjacency-divergence-adjaceny-...loop stayed closed due to loading. Not fun to have to rebuild all of your routers or reattach them to the network one by one... >From my understanding >a. it makes more sense to have 1 routing protocol as we dont >have multiple >daemons scheduled on the CPU. (which ofcourse is not a problem >but then so >is the point you mentioned below) In either case, BGP will consume the vast majority of CPU cycles. IGPs that are properly tuned in stable environments hardly tickle the CPU, let alone heat it up. Take LSA/P refresh out of the picture, and all the IGP does is send hellos and occasionally flood an LSA/P and compute an SPT once in a rare while. In the Internet, BGP is constantly processing updates and withdrawals, all day, every day. Sometimes, we see 100s of updates per minute, sometimes just a few, but they are always there. >b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we >inject 0.0.0.0/0 into IGP to make unknown prefixes go to the >nearest BGP >node.So does that help reduce the size of your routing table? Large SPs must run a full BGP load, at a minimum, to give routes to their customers. Unless you are talking about enterprise routing, we should avoid discussions of default routes... >c. The cases u mention of changes, I presume you mean >route-flaps. Well in >that case, we eitherways have issues when IGP flaps, we >eitherways wait for >IGP to converge for BGP to converge etc? (I am sure "real >traffic" operators >do that) Modern IGPs, properly tuned, converge way faster than BGP. BGP convergence is designed to be slow, so as not to place too much load on the global routing system. Since BGP carries so many routes, and since the topological density of the Internet Autonomous System graph increases every day, BGP can often take minutes to converge. IGPs take seconds, partly because they are usually lightweight. >d. We have the benefits of not having the "global view" dependent on 1 >protocol while the internal topology dependent on another This is actually a sound design. Think of the IGP as a topology discovery mechanism. All BGP routes have a next-hop. The goal of BGP is to take traffic to and from the "edges" of the network. Sometimes, the edge is within your network, like a server farm. IGPs are very good at discovering a topology and identifying the shortest path to each edge. BGP is not designed for this, and to make it do so requires considerable planning and lots of policy. >e. all i need to teach the network admins is BGP :) It is much easier to learn simple IS-IS and OSPF than BGP. Link State IGPs, when employed for topology discovery, are exceedingly simple (particularly IS-IS in a single area). BGP, on the otherhand, is a much bigger protocol that requires a lot of policy engineering in order for it to be effective. >f. Based on c, how would you say that it makes things more >complicated to >run iBGP only compared to IGP+0.0.0.0/0 (default originate and >originate >always) and all those things taken into consideration? Are you talking about running in an enterprise? Default routes will not work in any large environment for next-hop discovery of your iBGP peer IP's. Loops would abound... One of the problems with your proposal, and the primary reason this is not done, is that iBGP does not provide for transitive route dissemination in a network. All 'other' IGPs do this. This means your network topology must be highly symmetrical and/or fully meshed at layer 3 (at least in subsections) to allow for end-to-end route propagation. Unless you can employ lots of confeds (ie, each router in a confed subAS), lots of route-reflectors, or a full-mesh topology at layer 3 (and layer 2 if you consider multiaccess networks fully-meshed), then this approach is not possible. BGP also has race-condition mitigation rules that prevent a BGP route from being learned from a next-hop that is known via BGP, so injecting routes into BGP and hoping to bootstrap the next-hops would be problematic. This restriction is subtle and perhaps vendor specific, but usually, the next-hop is recursed through an IGP or connected interface. If this were possible, in any event, it would be slow-converging, as iBGP updates are typically spaced at 5 second intervals (depending on the event type). Also, you will have to peer with every interface on the device, thus forcing traffic to take certain paths that may not be the best path available, as most BGP attributes are non-accumulating (ie, u have to statically increase, say, local-pref via policy as routes propagate along a set of routers in your AS). The reality is that even if such an approach _were_ possible, the drawbacks are much more severe than simply turning on an IGP and having it discover your topology. Then, you may do what you with with iBGP. The best philosophy, IMO, is to place loopbacks and links in your IGP, and carry externals (either self-originated or from another AS) in your iBGP. Route-reflectors are useful if regionalized, as they make best path decisions before reflecting (so u want to be careful who peers with what to ensure path selection optimality). Confeds afford more control, TE, etc., but at what some claim to be a higher admin cost. Use them based on what you are trying to do. HTH, Chris >would be great if you could help clarify this. > >-Smith > > > > > >You could certainly run BGP and statics without another >protocol for the >IGP, but why would you want to? Convergence times, CPU load on >RPs, etc., >during changes would be rather unsatisfactory. If you want to run one >dynamic protocol at all costs, then what you describe below >will work, and >has worked for some, but people with real traffic don't waste >their time >with it. > > >Ben > >On Mar 15, 2004, at 8:24 PM, John Smith wrote: > > >Hi, > >I am very clear with the concept that IGPs cannot be used to carry the >entire BGP feed as >they cant be scaled to carry so many prefixes (even assuming >we add enough >TLVs to make >them carry the BGP attributes). > >What is not very clear to me is, why cant we use IBGP inside an AS to >completely do away >with IGPs. IGPs compute the best path to reach a particular >neighbor based >on the link >metric. This can be achieved in BGP also, if we include a TLV >to carry the >link cost. >Moreover, it is *mandatory* to run BGP on all the routers if we are >transiting traffic, >because if a router isnt speaking BGP then it cant forward BGP traffic. > >Cant we do away with IGPs (say in some small networks) and run >only IBGP >there? > >Any help/clues/pointers in this regard will be really appreciated. > >Regards, >Smith > >_________________________________________________________________ >Tired of spam? Get advanced junk mail protection with MSN 8. >http://join.msn.com/?page=features/junkmail > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 23 17:45:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07954 for ; Tue, 23 Mar 2004 17:45:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ueQ-0004wM-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 17:45:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5udS-0004sI-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 17:44:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5uct-0004oW-00; Tue, 23 Mar 2004 17:44:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ucr-00081T-Gu; Tue, 23 Mar 2004 17:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ucX-00080K-G9 for idr@optimus.ietf.org; Tue, 23 Mar 2004 17:43:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07912 for ; Tue, 23 Mar 2004 17:43:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ucU-0004nB-00 for idr@ietf.org; Tue, 23 Mar 2004 17:43:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5ubb-0004hU-00 for idr@ietf.org; Tue, 23 Mar 2004 17:42:43 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1B5uak-0004d1-00 for idr@ietf.org; Tue, 23 Mar 2004 17:41:50 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i2NMcLbZ012648; Tue, 23 Mar 2004 17:38:21 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403232238.i2NMcLbZ012648@workhorse.fictitious.org> To: Pekka Savola cc: idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes (fwd) In-reply-to: Your message of "Tue, 23 Mar 2004 16:42:36 +0200." From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 17:38:20 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message , Pekka Savola w rites: > There were no follow-ups to this and the spec has entered IETF Last > Call. > > So, let me ask again; is there opposition for adding a clarification > like: > > If a route's (Rte1) next-hop (Rte2) or next-hop interface would > lead to packets being discarded by the same router, the route > (Rte1) SHOULD be considered unresolvable. > > or: > > When considering resolvable routes or referenced interfaces, > if packets through the route would be discarded by the router, > the route SHOULD be considered unresolvable. > > in 9.1.2.1, after the two points about the route resolvability > condition (as justified by below) ? There was plenty of response to your repeated messages on this topic. There is no need to change the BGP spec. If you want more details look at the long threads on list and the threads off list. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 23 17:46:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07986 for ; Tue, 23 Mar 2004 17:46:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ueU-0008Dd-AP for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 17:45:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NMjgON031587 for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 17:45:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ueT-0008DO-FG for idr-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 17:45:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07972 for ; Tue, 23 Mar 2004 17:45:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ueQ-0004wR-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 17:45:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5udT-0004sP-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 17:44:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5uct-0004oW-00; Tue, 23 Mar 2004 17:44:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ucr-00081T-Gu; Tue, 23 Mar 2004 17:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ucX-00080K-G9 for idr@optimus.ietf.org; Tue, 23 Mar 2004 17:43:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07912 for ; Tue, 23 Mar 2004 17:43:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ucU-0004nB-00 for idr@ietf.org; Tue, 23 Mar 2004 17:43:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5ubb-0004hU-00 for idr@ietf.org; Tue, 23 Mar 2004 17:42:43 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1B5uak-0004d1-00 for idr@ietf.org; Tue, 23 Mar 2004 17:41:50 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i2NMcLbZ012648; Tue, 23 Mar 2004 17:38:21 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403232238.i2NMcLbZ012648@workhorse.fictitious.org> To: Pekka Savola cc: idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes (fwd) In-reply-to: Your message of "Tue, 23 Mar 2004 16:42:36 +0200." From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 17:38:20 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message , Pekka Savola w rites: > There were no follow-ups to this and the spec has entered IETF Last > Call. > > So, let me ask again; is there opposition for adding a clarification > like: > > If a route's (Rte1) next-hop (Rte2) or next-hop interface would > lead to packets being discarded by the same router, the route > (Rte1) SHOULD be considered unresolvable. > > or: > > When considering resolvable routes or referenced interfaces, > if packets through the route would be discarded by the router, > the route SHOULD be considered unresolvable. > > in 9.1.2.1, after the two points about the route resolvability > condition (as justified by below) ? There was plenty of response to your repeated messages on this topic. There is no need to change the BGP spec. If you want more details look at the long threads on list and the threads off list. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 23 17:47:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08092 for ; Tue, 23 Mar 2004 17:47:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ugN-00056X-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 17:47:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5ufT-000521-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 17:46:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5uev-0004xd-00; Tue, 23 Mar 2004 17:46:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uem-0008Er-LH; Tue, 23 Mar 2004 17:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ueM-0008D5-PQ for idr@optimus.ietf.org; Tue, 23 Mar 2004 17:45:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07948 for ; Tue, 23 Mar 2004 17:45:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ueK-0004vU-00 for idr@ietf.org; Tue, 23 Mar 2004 17:45:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5udM-0004rI-00 for idr@ietf.org; Tue, 23 Mar 2004 17:44:33 -0500 Received: from law9-f28.law9.hotmail.com ([64.4.9.28] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B5ucW-0004kA-00 for idr@ietf.org; Tue, 23 Mar 2004 17:43:40 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 23 Mar 2004 14:43:10 -0800 Received: from 64.38.138.134 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 23 Mar 2004 22:43:10 GMT X-Originating-IP: [64.38.138.134] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: cmartin@gnilink.net Cc: idr@ietf.org Subject: RE: [Idr] IBGP to replace IGP Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Mar 2004 22:43:10.0650 (UTC) FILETIME=[37D841A0:01C41128] Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 22:43:10 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Check my reply to Ben, it covers a lot of commong ground I think you missed out the point that I was planning to put 0.0.0.0/0 in the intermediate nodes to cover the internet. It is nothing buy my IGP replaced with BGP. 0.0.0.0/0 and all that being considered for intermediate nodes. Route flaps are a result of "actualy flaps somewhere" and if you were to follow the 0.0.0.0/0 principal neither would your intermediate nodes give a problem. The loops would abound in case of any IGP too when u inject 0.0.0.0/0 into the IGP, so maybe I didnt quite get that point >From: "Martin, Christian" >To: 'john smith' , "'idr@ietf.org'" > >Subject: RE: [Idr] IBGP to replace IGP >Date: Tue, 23 Mar 2004 17:35:58 -0500 > >Smith, > >Comments inline, as I have been following this thread. > > > >It would be great if you could share some more information on > >the "issues" > >of convergence time, CPU loads, and RP overloads. > >Convergence is typically nonlienearly proportionate to CPU load, and >vice-versa, and they often feed off each other in a negative way. Network >meltdowns are typically the result of routing loads disrupting topology >maintenance mechanisms, thereby causing adjacency loss, which causes more >routing load, which inhibits adjacency recreation, etc. I've seen networks >stay in persistent "ditches" because the >convergence-adjacency-divergence-adjaceny-...loop stayed closed due to >loading. Not fun to have to rebuild all of your routers or reattach them >to >the network one by one... > > >From my understanding > >a. it makes more sense to have 1 routing protocol as we dont > >have multiple > >daemons scheduled on the CPU. (which ofcourse is not a problem > >but then so > >is the point you mentioned below) > >In either case, BGP will consume the vast majority of CPU cycles. IGPs >that >are properly tuned in stable environments hardly tickle the CPU, let alone >heat it up. Take LSA/P refresh out of the picture, and all the IGP does is >send hellos and occasionally flood an LSA/P and compute an SPT once in a >rare while. In the Internet, BGP is constantly processing updates and >withdrawals, all day, every day. Sometimes, we see 100s of updates per >minute, sometimes just a few, but they are always there. > > >b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we > >inject 0.0.0.0/0 into IGP to make unknown prefixes go to the > >nearest BGP > >node.So does that help reduce the size of your routing table? > >Large SPs must run a full BGP load, at a minimum, to give routes to their >customers. Unless you are talking about enterprise routing, we should >avoid >discussions of default routes... > > >c. The cases u mention of changes, I presume you mean > >route-flaps. Well in > >that case, we eitherways have issues when IGP flaps, we > >eitherways wait for > >IGP to converge for BGP to converge etc? (I am sure "real > >traffic" operators > >do that) > >Modern IGPs, properly tuned, converge way faster than BGP. BGP convergence >is designed to be slow, so as not to place too much load on the global >routing system. Since BGP carries so many routes, and since the >topological >density of the Internet Autonomous System graph increases every day, BGP >can >often take minutes to converge. IGPs take seconds, partly because they are >usually lightweight. > > >d. We have the benefits of not having the "global view" dependent on 1 > >protocol while the internal topology dependent on another > >This is actually a sound design. Think of the IGP as a topology discovery >mechanism. All BGP routes have a next-hop. The goal of BGP is to take >traffic to and from the "edges" of the network. Sometimes, the edge is >within your network, like a server farm. IGPs are very good at discovering >a topology and identifying the shortest path to each edge. BGP is not >designed for this, and to make it do so requires considerable planning and >lots of policy. > > >e. all i need to teach the network admins is BGP :) > >It is much easier to learn simple IS-IS and OSPF than BGP. Link State >IGPs, >when employed for topology discovery, are exceedingly simple (particularly >IS-IS in a single area). BGP, on the otherhand, is a much bigger protocol >that requires a lot of policy engineering in order for it to be effective. > > >f. Based on c, how would you say that it makes things more > >complicated to > >run iBGP only compared to IGP+0.0.0.0/0 (default originate and > >originate > >always) and all those things taken into consideration? > >Are you talking about running in an enterprise? Default routes will not >work in any large environment for next-hop discovery of your iBGP peer >IP's. >Loops would abound... > > >One of the problems with your proposal, and the primary reason this is not >done, is that iBGP does not provide for transitive route dissemination in a >network. All 'other' IGPs do this. This means your network topology must >be highly symmetrical and/or fully meshed at layer 3 (at least in >subsections) to allow for end-to-end route propagation. Unless you can >employ lots of confeds (ie, each router in a confed subAS), lots of >route-reflectors, or a full-mesh topology at layer 3 (and layer 2 if you >consider multiaccess networks fully-meshed), then this approach is not >possible. > >BGP also has race-condition mitigation rules that prevent a BGP route from >being learned from a next-hop that is known via BGP, so injecting routes >into BGP and hoping to bootstrap the next-hops would be problematic. This >restriction is subtle and perhaps vendor specific, but usually, the >next-hop >is recursed through an IGP or connected interface. If this were possible, >in any event, it would be slow-converging, as iBGP updates are typically >spaced at 5 second intervals (depending on the event type). Also, you will >have to peer with every interface on the device, thus forcing traffic to >take certain paths that may not be the best path available, as most BGP >attributes are non-accumulating (ie, u have to statically increase, say, >local-pref via policy as routes propagate along a set of routers in your >AS). > >The reality is that even if such an approach _were_ possible, the drawbacks >are much more severe than simply turning on an IGP and having it discover >your topology. Then, you may do what you with with iBGP. > >The best philosophy, IMO, is to place loopbacks and links in your IGP, and >carry externals (either self-originated or from another AS) in your iBGP. >Route-reflectors are useful if regionalized, as they make best path >decisions before reflecting (so u want to be careful who peers with what to >ensure path selection optimality). Confeds afford more control, TE, etc., >but at what some claim to be a higher admin cost. Use them based on what >you are trying to do. > >HTH, >Chris > > >would be great if you could help clarify this. > > > >-Smith > > > > > > > > > > > > > > > > > >You could certainly run BGP and statics without another > >protocol for the > >IGP, but why would you want to? Convergence times, CPU load on > >RPs, etc., > >during changes would be rather unsatisfactory. If you want to run one > >dynamic protocol at all costs, then what you describe below > >will work, and > >has worked for some, but people with real traffic don't waste > >their time > >with it. > > > > > >Ben > > > >On Mar 15, 2004, at 8:24 PM, John Smith wrote: > > > > > >Hi, > > > >I am very clear with the concept that IGPs cannot be used to carry the > >entire BGP feed as > >they cant be scaled to carry so many prefixes (even assuming > >we add enough > >TLVs to make > >them carry the BGP attributes). > > > >What is not very clear to me is, why cant we use IBGP inside an AS to > >completely do away > >with IGPs. IGPs compute the best path to reach a particular > >neighbor based > >on the link > >metric. This can be achieved in BGP also, if we include a TLV > >to carry the > >link cost. > >Moreover, it is *mandatory* to run BGP on all the routers if we are > >transiting traffic, > >because if a router isnt speaking BGP then it cant forward BGP traffic. > > > >Cant we do away with IGPs (say in some small networks) and run > >only IBGP > >there? > > > >Any help/clues/pointers in this regard will be really appreciated. > > > >Regards, > >Smith > > > >_________________________________________________________________ > >Tired of spam? Get advanced junk mail protection with MSN 8. > >http://join.msn.com/?page=features/junkmail > > > > > >_______________________________________________ > >Idr mailing list > >Idr@ietf.org > >https://www1.ietf.org/mailman/listinfo/idr > > _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 23 17:48:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08121 for ; Tue, 23 Mar 2004 17:48:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ugS-00009V-7b for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 17:47:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NMliNu000579 for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 17:47:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ugS-00009G-23 for idr-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 17:47:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08110 for ; Tue, 23 Mar 2004 17:47:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ugP-00056m-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 17:47:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5ufV-00052B-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 17:46:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5uev-0004xd-00; Tue, 23 Mar 2004 17:46:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uem-0008Er-LH; Tue, 23 Mar 2004 17:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ueM-0008D5-PQ for idr@optimus.ietf.org; Tue, 23 Mar 2004 17:45:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07948 for ; Tue, 23 Mar 2004 17:45:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ueK-0004vU-00 for idr@ietf.org; Tue, 23 Mar 2004 17:45:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5udM-0004rI-00 for idr@ietf.org; Tue, 23 Mar 2004 17:44:33 -0500 Received: from law9-f28.law9.hotmail.com ([64.4.9.28] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B5ucW-0004kA-00 for idr@ietf.org; Tue, 23 Mar 2004 17:43:40 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 23 Mar 2004 14:43:10 -0800 Received: from 64.38.138.134 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 23 Mar 2004 22:43:10 GMT X-Originating-IP: [64.38.138.134] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: cmartin@gnilink.net Cc: idr@ietf.org Subject: RE: [Idr] IBGP to replace IGP Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Mar 2004 22:43:10.0650 (UTC) FILETIME=[37D841A0:01C41128] Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 22:43:10 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Check my reply to Ben, it covers a lot of commong ground I think you missed out the point that I was planning to put 0.0.0.0/0 in the intermediate nodes to cover the internet. It is nothing buy my IGP replaced with BGP. 0.0.0.0/0 and all that being considered for intermediate nodes. Route flaps are a result of "actualy flaps somewhere" and if you were to follow the 0.0.0.0/0 principal neither would your intermediate nodes give a problem. The loops would abound in case of any IGP too when u inject 0.0.0.0/0 into the IGP, so maybe I didnt quite get that point >From: "Martin, Christian" >To: 'john smith' , "'idr@ietf.org'" > >Subject: RE: [Idr] IBGP to replace IGP >Date: Tue, 23 Mar 2004 17:35:58 -0500 > >Smith, > >Comments inline, as I have been following this thread. > > > >It would be great if you could share some more information on > >the "issues" > >of convergence time, CPU loads, and RP overloads. > >Convergence is typically nonlienearly proportionate to CPU load, and >vice-versa, and they often feed off each other in a negative way. Network >meltdowns are typically the result of routing loads disrupting topology >maintenance mechanisms, thereby causing adjacency loss, which causes more >routing load, which inhibits adjacency recreation, etc. I've seen networks >stay in persistent "ditches" because the >convergence-adjacency-divergence-adjaceny-...loop stayed closed due to >loading. Not fun to have to rebuild all of your routers or reattach them >to >the network one by one... > > >From my understanding > >a. it makes more sense to have 1 routing protocol as we dont > >have multiple > >daemons scheduled on the CPU. (which ofcourse is not a problem > >but then so > >is the point you mentioned below) > >In either case, BGP will consume the vast majority of CPU cycles. IGPs >that >are properly tuned in stable environments hardly tickle the CPU, let alone >heat it up. Take LSA/P refresh out of the picture, and all the IGP does is >send hellos and occasionally flood an LSA/P and compute an SPT once in a >rare while. In the Internet, BGP is constantly processing updates and >withdrawals, all day, every day. Sometimes, we see 100s of updates per >minute, sometimes just a few, but they are always there. > > >b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we > >inject 0.0.0.0/0 into IGP to make unknown prefixes go to the > >nearest BGP > >node.So does that help reduce the size of your routing table? > >Large SPs must run a full BGP load, at a minimum, to give routes to their >customers. Unless you are talking about enterprise routing, we should >avoid >discussions of default routes... > > >c. The cases u mention of changes, I presume you mean > >route-flaps. Well in > >that case, we eitherways have issues when IGP flaps, we > >eitherways wait for > >IGP to converge for BGP to converge etc? (I am sure "real > >traffic" operators > >do that) > >Modern IGPs, properly tuned, converge way faster than BGP. BGP convergence >is designed to be slow, so as not to place too much load on the global >routing system. Since BGP carries so many routes, and since the >topological >density of the Internet Autonomous System graph increases every day, BGP >can >often take minutes to converge. IGPs take seconds, partly because they are >usually lightweight. > > >d. We have the benefits of not having the "global view" dependent on 1 > >protocol while the internal topology dependent on another > >This is actually a sound design. Think of the IGP as a topology discovery >mechanism. All BGP routes have a next-hop. The goal of BGP is to take >traffic to and from the "edges" of the network. Sometimes, the edge is >within your network, like a server farm. IGPs are very good at discovering >a topology and identifying the shortest path to each edge. BGP is not >designed for this, and to make it do so requires considerable planning and >lots of policy. > > >e. all i need to teach the network admins is BGP :) > >It is much easier to learn simple IS-IS and OSPF than BGP. Link State >IGPs, >when employed for topology discovery, are exceedingly simple (particularly >IS-IS in a single area). BGP, on the otherhand, is a much bigger protocol >that requires a lot of policy engineering in order for it to be effective. > > >f. Based on c, how would you say that it makes things more > >complicated to > >run iBGP only compared to IGP+0.0.0.0/0 (default originate and > >originate > >always) and all those things taken into consideration? > >Are you talking about running in an enterprise? Default routes will not >work in any large environment for next-hop discovery of your iBGP peer >IP's. >Loops would abound... > > >One of the problems with your proposal, and the primary reason this is not >done, is that iBGP does not provide for transitive route dissemination in a >network. All 'other' IGPs do this. This means your network topology must >be highly symmetrical and/or fully meshed at layer 3 (at least in >subsections) to allow for end-to-end route propagation. Unless you can >employ lots of confeds (ie, each router in a confed subAS), lots of >route-reflectors, or a full-mesh topology at layer 3 (and layer 2 if you >consider multiaccess networks fully-meshed), then this approach is not >possible. > >BGP also has race-condition mitigation rules that prevent a BGP route from >being learned from a next-hop that is known via BGP, so injecting routes >into BGP and hoping to bootstrap the next-hops would be problematic. This >restriction is subtle and perhaps vendor specific, but usually, the >next-hop >is recursed through an IGP or connected interface. If this were possible, >in any event, it would be slow-converging, as iBGP updates are typically >spaced at 5 second intervals (depending on the event type). Also, you will >have to peer with every interface on the device, thus forcing traffic to >take certain paths that may not be the best path available, as most BGP >attributes are non-accumulating (ie, u have to statically increase, say, >local-pref via policy as routes propagate along a set of routers in your >AS). > >The reality is that even if such an approach _were_ possible, the drawbacks >are much more severe than simply turning on an IGP and having it discover >your topology. Then, you may do what you with with iBGP. > >The best philosophy, IMO, is to place loopbacks and links in your IGP, and >carry externals (either self-originated or from another AS) in your iBGP. >Route-reflectors are useful if regionalized, as they make best path >decisions before reflecting (so u want to be careful who peers with what to >ensure path selection optimality). Confeds afford more control, TE, etc., >but at what some claim to be a higher admin cost. Use them based on what >you are trying to do. > >HTH, >Chris > > >would be great if you could help clarify this. > > > >-Smith > > > > > > > > > > > > > > > > > >You could certainly run BGP and statics without another > >protocol for the > >IGP, but why would you want to? Convergence times, CPU load on > >RPs, etc., > >during changes would be rather unsatisfactory. If you want to run one > >dynamic protocol at all costs, then what you describe below > >will work, and > >has worked for some, but people with real traffic don't waste > >their time > >with it. > > > > > >Ben > > > >On Mar 15, 2004, at 8:24 PM, John Smith wrote: > > > > > >Hi, > > > >I am very clear with the concept that IGPs cannot be used to carry the > >entire BGP feed as > >they cant be scaled to carry so many prefixes (even assuming > >we add enough > >TLVs to make > >them carry the BGP attributes). > > > >What is not very clear to me is, why cant we use IBGP inside an AS to > >completely do away > >with IGPs. IGPs compute the best path to reach a particular > >neighbor based > >on the link > >metric. This can be achieved in BGP also, if we include a TLV > >to carry the > >link cost. > >Moreover, it is *mandatory* to run BGP on all the routers if we are > >transiting traffic, > >because if a router isnt speaking BGP then it cant forward BGP traffic. > > > >Cant we do away with IGPs (say in some small networks) and run > >only IBGP > >there? > > > >Any help/clues/pointers in this regard will be really appreciated. > > > >Regards, > >Smith > > > >_________________________________________________________________ > >Tired of spam? Get advanced junk mail protection with MSN 8. > >http://join.msn.com/?page=features/junkmail > > > > > >_______________________________________________ > >Idr mailing list > >Idr@ietf.org > >https://www1.ietf.org/mailman/listinfo/idr > > _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 23 18:04:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09256 for ; Tue, 23 Mar 2004 18:04:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uwk-0006j3-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 18:04:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5uvs-0006fZ-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 18:03:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5uvH-0006c8-00; Tue, 23 Mar 2004 18:03:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uvF-0003GI-9l; Tue, 23 Mar 2004 18:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uur-0002pY-58 for idr@optimus.ietf.org; Tue, 23 Mar 2004 18:02:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09076 for ; Tue, 23 Mar 2004 18:02:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uuo-0006aT-00 for idr@ietf.org; Tue, 23 Mar 2004 18:02:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5utv-0006XX-00 for idr@ietf.org; Tue, 23 Mar 2004 18:01:40 -0500 Received: from entmail.gnilink.net ([199.45.47.10]) by ietf-mx with esmtp (Exim 4.12) id 1B5utj-0006Tk-00 for idr@ietf.org; Tue, 23 Mar 2004 18:01:27 -0500 Received: by entmail.gnilink.net with Internet Mail Service (5.5.2656.59) id ; Tue, 23 Mar 2004 18:00:58 -0500 Message-ID: <94B9091E1149D411A45C00508BACEB35071A32DE@entmail.gnilink.net> From: "Martin, Christian" To: "'john smith'" Cc: "'idr@ietf.org'" Subject: RE: [Idr] IBGP to replace IGP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 18:00:54 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 John, We are drifting off topic for this list here. Perhaps you should take this up on a list that covers fundamental routing concepts. Contact me privately if you wish to engage further. Thanks, chris >Check my reply to Ben, it covers a lot of commong ground > >I think you missed out the point that I was planning to put >0.0.0.0/0 in the >intermediate nodes to cover the internet. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 23 18:05:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09328 for ; Tue, 23 Mar 2004 18:05:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uwo-0003qa-1z for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 18:04:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NN4cfo014782 for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 18:04:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uwn-0003qL-Ta for idr-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 18:04:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09271 for ; Tue, 23 Mar 2004 18:04:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uwk-0006j8-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 18:04:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5uvs-0006fg-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 18:03:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5uvH-0006c8-00; Tue, 23 Mar 2004 18:03:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uvF-0003GI-9l; Tue, 23 Mar 2004 18:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uur-0002pY-58 for idr@optimus.ietf.org; Tue, 23 Mar 2004 18:02:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09076 for ; Tue, 23 Mar 2004 18:02:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uuo-0006aT-00 for idr@ietf.org; Tue, 23 Mar 2004 18:02:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5utv-0006XX-00 for idr@ietf.org; Tue, 23 Mar 2004 18:01:40 -0500 Received: from entmail.gnilink.net ([199.45.47.10]) by ietf-mx with esmtp (Exim 4.12) id 1B5utj-0006Tk-00 for idr@ietf.org; Tue, 23 Mar 2004 18:01:27 -0500 Received: by entmail.gnilink.net with Internet Mail Service (5.5.2656.59) id ; Tue, 23 Mar 2004 18:00:58 -0500 Message-ID: <94B9091E1149D411A45C00508BACEB35071A32DE@entmail.gnilink.net> From: "Martin, Christian" To: "'john smith'" Cc: "'idr@ietf.org'" Subject: RE: [Idr] IBGP to replace IGP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 18:00:54 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 John, We are drifting off topic for this list here. Perhaps you should take this up on a list that covers fundamental routing concepts. Contact me privately if you wish to engage further. Thanks, chris >Check my reply to Ben, it covers a lot of commong ground > >I think you missed out the point that I was planning to put >0.0.0.0/0 in the >intermediate nodes to cover the internet. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 23 18:15:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10555 for ; Tue, 23 Mar 2004 18:15:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5v7T-0007ZY-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 18:15:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5v6V-0007WA-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 18:14:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5v5w-0007Sj-00; Tue, 23 Mar 2004 18:14:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5v5t-0007fS-6k; Tue, 23 Mar 2004 18:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5v4u-0007SL-TL for idr@optimus.ietf.org; Tue, 23 Mar 2004 18:13:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10226 for ; Tue, 23 Mar 2004 18:12:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5v4s-0007Mz-00 for idr@ietf.org; Tue, 23 Mar 2004 18:12:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5v3r-0007Gs-00 for idr@ietf.org; Tue, 23 Mar 2004 18:11:56 -0500 Received: from law9-f21.law9.hotmail.com ([64.4.9.21] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B5v3N-000799-00 for idr@ietf.org; Tue, 23 Mar 2004 18:11:26 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 23 Mar 2004 15:10:54 -0800 Received: from 64.38.138.134 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 23 Mar 2004 23:10:54 GMT X-Originating-IP: [64.38.138.134] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: ben@layer8.net Cc: cmartin@gnilink.net, idr@ietf.org Subject: Re: [Idr] IBGP to replace IGP Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Mar 2004 23:10:54.0117 (UTC) FILETIME=[17592D50:01C4112C] Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 23:10:54 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 I am not saying that you do not need BGP "at all". The default route to a node "with complete information" only covers the case where you have intermediate nodes which cannot handle the complete routing table due to certain limitations highlighted by you. The reason we use BGP today is the very reason we still need to use BGP. Some one"has to be the *upstream*". There has to be a point in the network where you decide if A or B is the best way to send traffic outside your AS. All I am asking is why do we need IGP when the same things that are done by IGP can be done within BGP. If you plan to extend an IGP like OSPF (LinkState) to do the same things that BGP does today (provides a point in the network which has complete and accurate information), and you believe the performance will be better, I would be really curious to see the results and would be thankful if you could share the same. >From: Benjamin Black >To: "john smith" >CC: cmartin@gnilink.net, idr@ietf.org >Subject: Re: [Idr] IBGP to replace IGP >Date: Tue, 23 Mar 2004 15:01:43 -0800 > >from the sound of things you don't need bgp at all, except to announce >routes to your upstreams. rejecting all routes from a peer tends to limit >the size of adj-rib-in as well as reduce the cpu load of route flaps. >handle the rest with an igp and a default and you are done (and your >network admins need know almost nothing about bgp). > > >ben > >On Mar 23, 2004, at 2:43 PM, john smith wrote: > >>Check my reply to Ben, it covers a lot of commong ground >> >>I think you missed out the point that I was planning to put 0.0.0.0/0 in >>the intermediate nodes to cover the internet. >> >>It is nothing buy my IGP replaced with BGP. 0.0.0.0/0 and all that being >>considered for intermediate nodes. >> >>Route flaps are a result of "actualy flaps somewhere" and if you were to >>follow the 0.0.0.0/0 principal neither would your intermediate nodes give >>a problem. >> >>The loops would abound in case of any IGP too when u inject 0.0.0.0/0 into >>the IGP, so maybe I didnt quite get that point >> >>>From: "Martin, Christian" >>>To: 'john smith' , "'idr@ietf.org'" >>> >>>Subject: RE: [Idr] IBGP to replace IGP >>>Date: Tue, 23 Mar 2004 17:35:58 -0500 >>> >>>Smith, >>> >>>Comments inline, as I have been following this thread. >>> >>> >>> >It would be great if you could share some more information on >>> >the "issues" >>> >of convergence time, CPU loads, and RP overloads. >>> >>>Convergence is typically nonlienearly proportionate to CPU load, and >>>vice-versa, and they often feed off each other in a negative way. >>>Network >>>meltdowns are typically the result of routing loads disrupting topology >>>maintenance mechanisms, thereby causing adjacency loss, which causes more >>>routing load, which inhibits adjacency recreation, etc. I've seen >>>networks >>>stay in persistent "ditches" because the >>>convergence-adjacency-divergence-adjaceny-...loop stayed closed due to >>>loading. Not fun to have to rebuild all of your routers or reattach them >>>to >>>the network one by one... >>> >>> >From my understanding >>> >a. it makes more sense to have 1 routing protocol as we dont >>> >have multiple >>> >daemons scheduled on the CPU. (which ofcourse is not a problem >>> >but then so >>> >is the point you mentioned below) >>> >>>In either case, BGP will consume the vast majority of CPU cycles. IGPs >>>that >>>are properly tuned in stable environments hardly tickle the CPU, let >>>alone >>>heat it up. Take LSA/P refresh out of the picture, and all the IGP does >>>is >>>send hellos and occasionally flood an LSA/P and compute an SPT once in a >>>rare while. In the Internet, BGP is constantly processing updates and >>>withdrawals, all day, every day. Sometimes, we see 100s of updates per >>>minute, sometimes just a few, but they are always there. >>> >>> >b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we >>> >inject 0.0.0.0/0 into IGP to make unknown prefixes go to the >>> >nearest BGP >>> >node.So does that help reduce the size of your routing table? >>> >>>Large SPs must run a full BGP load, at a minimum, to give routes to their >>>customers. Unless you are talking about enterprise routing, we should >>>avoid >>>discussions of default routes... >>> >>> >c. The cases u mention of changes, I presume you mean >>> >route-flaps. Well in >>> >that case, we eitherways have issues when IGP flaps, we >>> >eitherways wait for >>> >IGP to converge for BGP to converge etc? (I am sure "real >>> >traffic" operators >>> >do that) >>> >>>Modern IGPs, properly tuned, converge way faster than BGP. BGP >>>convergence >>>is designed to be slow, so as not to place too much load on the global >>>routing system. Since BGP carries so many routes, and since the >>>topological >>>density of the Internet Autonomous System graph increases every day, BGP >>>can >>>often take minutes to converge. IGPs take seconds, partly because they >>>are >>>usually lightweight. >>> >>> >d. We have the benefits of not having the "global view" dependent on 1 >>> >protocol while the internal topology dependent on another >>> >>>This is actually a sound design. Think of the IGP as a topology >>>discovery >>>mechanism. All BGP routes have a next-hop. The goal of BGP is to take >>>traffic to and from the "edges" of the network. Sometimes, the edge is >>>within your network, like a server farm. IGPs are very good at >>>discovering >>>a topology and identifying the shortest path to each edge. BGP is not >>>designed for this, and to make it do so requires considerable planning >>>and >>>lots of policy. >>> >>> >e. all i need to teach the network admins is BGP :) >>> >>>It is much easier to learn simple IS-IS and OSPF than BGP. Link State >>>IGPs, >>>when employed for topology discovery, are exceedingly simple >>>(particularly >>>IS-IS in a single area). BGP, on the otherhand, is a much bigger >>>protocol >>>that requires a lot of policy engineering in order for it to be >>>effective. >>> >>> >f. Based on c, how would you say that it makes things more >>> >complicated to >>> >run iBGP only compared to IGP+0.0.0.0/0 (default originate and >>> >originate >>> >always) and all those things taken into consideration? >>> >>>Are you talking about running in an enterprise? Default routes will not >>>work in any large environment for next-hop discovery of your iBGP peer >>>IP's. >>>Loops would abound... >>> >>> >>>One of the problems with your proposal, and the primary reason this is >>>not >>>done, is that iBGP does not provide for transitive route dissemination in >>>a >>>network. All 'other' IGPs do this. This means your network topology >>>must >>>be highly symmetrical and/or fully meshed at layer 3 (at least in >>>subsections) to allow for end-to-end route propagation. Unless you can >>>employ lots of confeds (ie, each router in a confed subAS), lots of >>>route-reflectors, or a full-mesh topology at layer 3 (and layer 2 if you >>>consider multiaccess networks fully-meshed), then this approach is not >>>possible. >>> >>>BGP also has race-condition mitigation rules that prevent a BGP route >>>from >>>being learned from a next-hop that is known via BGP, so injecting routes >>>into BGP and hoping to bootstrap the next-hops would be problematic. >>>This >>>restriction is subtle and perhaps vendor specific, but usually, the >>>next-hop >>>is recursed through an IGP or connected interface. If this were >>>possible, >>>in any event, it would be slow-converging, as iBGP updates are typically >>>spaced at 5 second intervals (depending on the event type). Also, you >>>will >>>have to peer with every interface on the device, thus forcing traffic to >>>take certain paths that may not be the best path available, as most BGP >>>attributes are non-accumulating (ie, u have to statically increase, say, >>>local-pref via policy as routes propagate along a set of routers in your >>>AS). >>> >>>The reality is that even if such an approach _were_ possible, the >>>drawbacks >>>are much more severe than simply turning on an IGP and having it discover >>>your topology. Then, you may do what you with with iBGP. >>> >>>The best philosophy, IMO, is to place loopbacks and links in your IGP, >>>and >>>carry externals (either self-originated or from another AS) in your iBGP. >>>Route-reflectors are useful if regionalized, as they make best path >>>decisions before reflecting (so u want to be careful who peers with what >>>to >>>ensure path selection optimality). Confeds afford more control, TE, >>>etc., >>>but at what some claim to be a higher admin cost. Use them based on what >>>you are trying to do. >>> >>>HTH, >>>Chris >>> >>> >would be great if you could help clarify this. >>> > >>> >-Smith >>> > >>> >>> >>> >>> >>> >>> >>> > >>> > >>> > >>> > >>> >You could certainly run BGP and statics without another >>> >protocol for the >>> >IGP, but why would you want to? Convergence times, CPU load on >>> >RPs, etc., >>> >during changes would be rather unsatisfactory. If you want to run one >>> >dynamic protocol at all costs, then what you describe below >>> >will work, and >>> >has worked for some, but people with real traffic don't waste >>> >their time >>> >with it. >>> > >>> > >>> >Ben >>> > >>> >On Mar 15, 2004, at 8:24 PM, John Smith wrote: >>> > >>> > >>> >Hi, >>> > >>> >I am very clear with the concept that IGPs cannot be used to carry the >>> >entire BGP feed as >>> >they cant be scaled to carry so many prefixes (even assuming >>> >we add enough >>> >TLVs to make >>> >them carry the BGP attributes). >>> > >>> >What is not very clear to me is, why cant we use IBGP inside an AS to >>> >completely do away >>> >with IGPs. IGPs compute the best path to reach a particular >>> >neighbor based >>> >on the link >>> >metric. This can be achieved in BGP also, if we include a TLV >>> >to carry the >>> >link cost. >>> >Moreover, it is *mandatory* to run BGP on all the routers if we are >>> >transiting traffic, >>> >because if a router isnt speaking BGP then it cant forward BGP traffic. >>> > >>> >Cant we do away with IGPs (say in some small networks) and run >>> >only IBGP >>> >there? >>> > >>> >Any help/clues/pointers in this regard will be really appreciated. >>> > >>> >Regards, >>> >Smith >>> > >>> >_________________________________________________________________ >>> >Tired of spam? Get advanced junk mail protection with MSN 8. >>> >http://join.msn.com/?page=features/junkmail >>> > >>> > >>> >_______________________________________________ >>> >Idr mailing list >>> >Idr@ietf.org >>> >https://www1.ietf.org/mailman/listinfo/idr >>> > >> >>_________________________________________________________________ >>MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. >>http://join.msn.com/?page=features/virus >> >> >>_______________________________________________ >>Idr mailing list >>Idr@ietf.org >>https://www1.ietf.org/mailman/listinfo/idr >> >> > _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 23 18:16:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10626 for ; Tue, 23 Mar 2004 18:16:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5v7X-0008BV-MF for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 18:15:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NNFhjw031460 for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 18:15:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5v7X-0008BL-08 for idr-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 18:15:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10570 for ; Tue, 23 Mar 2004 18:15:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5v7T-0007Zd-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 18:15:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5v6W-0007WH-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 18:14:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5v5w-0007Sj-00; Tue, 23 Mar 2004 18:14:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5v5t-0007fS-6k; Tue, 23 Mar 2004 18:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5v4u-0007SL-TL for idr@optimus.ietf.org; Tue, 23 Mar 2004 18:13:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10226 for ; Tue, 23 Mar 2004 18:12:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5v4s-0007Mz-00 for idr@ietf.org; Tue, 23 Mar 2004 18:12:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5v3r-0007Gs-00 for idr@ietf.org; Tue, 23 Mar 2004 18:11:56 -0500 Received: from law9-f21.law9.hotmail.com ([64.4.9.21] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B5v3N-000799-00 for idr@ietf.org; Tue, 23 Mar 2004 18:11:26 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 23 Mar 2004 15:10:54 -0800 Received: from 64.38.138.134 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 23 Mar 2004 23:10:54 GMT X-Originating-IP: [64.38.138.134] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: ben@layer8.net Cc: cmartin@gnilink.net, idr@ietf.org Subject: Re: [Idr] IBGP to replace IGP Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Mar 2004 23:10:54.0117 (UTC) FILETIME=[17592D50:01C4112C] Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 23:10:54 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 I am not saying that you do not need BGP "at all". The default route to a node "with complete information" only covers the case where you have intermediate nodes which cannot handle the complete routing table due to certain limitations highlighted by you. The reason we use BGP today is the very reason we still need to use BGP. Some one"has to be the *upstream*". There has to be a point in the network where you decide if A or B is the best way to send traffic outside your AS. All I am asking is why do we need IGP when the same things that are done by IGP can be done within BGP. If you plan to extend an IGP like OSPF (LinkState) to do the same things that BGP does today (provides a point in the network which has complete and accurate information), and you believe the performance will be better, I would be really curious to see the results and would be thankful if you could share the same. >From: Benjamin Black >To: "john smith" >CC: cmartin@gnilink.net, idr@ietf.org >Subject: Re: [Idr] IBGP to replace IGP >Date: Tue, 23 Mar 2004 15:01:43 -0800 > >from the sound of things you don't need bgp at all, except to announce >routes to your upstreams. rejecting all routes from a peer tends to limit >the size of adj-rib-in as well as reduce the cpu load of route flaps. >handle the rest with an igp and a default and you are done (and your >network admins need know almost nothing about bgp). > > >ben > >On Mar 23, 2004, at 2:43 PM, john smith wrote: > >>Check my reply to Ben, it covers a lot of commong ground >> >>I think you missed out the point that I was planning to put 0.0.0.0/0 in >>the intermediate nodes to cover the internet. >> >>It is nothing buy my IGP replaced with BGP. 0.0.0.0/0 and all that being >>considered for intermediate nodes. >> >>Route flaps are a result of "actualy flaps somewhere" and if you were to >>follow the 0.0.0.0/0 principal neither would your intermediate nodes give >>a problem. >> >>The loops would abound in case of any IGP too when u inject 0.0.0.0/0 into >>the IGP, so maybe I didnt quite get that point >> >>>From: "Martin, Christian" >>>To: 'john smith' , "'idr@ietf.org'" >>> >>>Subject: RE: [Idr] IBGP to replace IGP >>>Date: Tue, 23 Mar 2004 17:35:58 -0500 >>> >>>Smith, >>> >>>Comments inline, as I have been following this thread. >>> >>> >>> >It would be great if you could share some more information on >>> >the "issues" >>> >of convergence time, CPU loads, and RP overloads. >>> >>>Convergence is typically nonlienearly proportionate to CPU load, and >>>vice-versa, and they often feed off each other in a negative way. >>>Network >>>meltdowns are typically the result of routing loads disrupting topology >>>maintenance mechanisms, thereby causing adjacency loss, which causes more >>>routing load, which inhibits adjacency recreation, etc. I've seen >>>networks >>>stay in persistent "ditches" because the >>>convergence-adjacency-divergence-adjaceny-...loop stayed closed due to >>>loading. Not fun to have to rebuild all of your routers or reattach them >>>to >>>the network one by one... >>> >>> >From my understanding >>> >a. it makes more sense to have 1 routing protocol as we dont >>> >have multiple >>> >daemons scheduled on the CPU. (which ofcourse is not a problem >>> >but then so >>> >is the point you mentioned below) >>> >>>In either case, BGP will consume the vast majority of CPU cycles. IGPs >>>that >>>are properly tuned in stable environments hardly tickle the CPU, let >>>alone >>>heat it up. Take LSA/P refresh out of the picture, and all the IGP does >>>is >>>send hellos and occasionally flood an LSA/P and compute an SPT once in a >>>rare while. In the Internet, BGP is constantly processing updates and >>>withdrawals, all day, every day. Sometimes, we see 100s of updates per >>>minute, sometimes just a few, but they are always there. >>> >>> >b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we >>> >inject 0.0.0.0/0 into IGP to make unknown prefixes go to the >>> >nearest BGP >>> >node.So does that help reduce the size of your routing table? >>> >>>Large SPs must run a full BGP load, at a minimum, to give routes to their >>>customers. Unless you are talking about enterprise routing, we should >>>avoid >>>discussions of default routes... >>> >>> >c. The cases u mention of changes, I presume you mean >>> >route-flaps. Well in >>> >that case, we eitherways have issues when IGP flaps, we >>> >eitherways wait for >>> >IGP to converge for BGP to converge etc? (I am sure "real >>> >traffic" operators >>> >do that) >>> >>>Modern IGPs, properly tuned, converge way faster than BGP. BGP >>>convergence >>>is designed to be slow, so as not to place too much load on the global >>>routing system. Since BGP carries so many routes, and since the >>>topological >>>density of the Internet Autonomous System graph increases every day, BGP >>>can >>>often take minutes to converge. IGPs take seconds, partly because they >>>are >>>usually lightweight. >>> >>> >d. We have the benefits of not having the "global view" dependent on 1 >>> >protocol while the internal topology dependent on another >>> >>>This is actually a sound design. Think of the IGP as a topology >>>discovery >>>mechanism. All BGP routes have a next-hop. The goal of BGP is to take >>>traffic to and from the "edges" of the network. Sometimes, the edge is >>>within your network, like a server farm. IGPs are very good at >>>discovering >>>a topology and identifying the shortest path to each edge. BGP is not >>>designed for this, and to make it do so requires considerable planning >>>and >>>lots of policy. >>> >>> >e. all i need to teach the network admins is BGP :) >>> >>>It is much easier to learn simple IS-IS and OSPF than BGP. Link State >>>IGPs, >>>when employed for topology discovery, are exceedingly simple >>>(particularly >>>IS-IS in a single area). BGP, on the otherhand, is a much bigger >>>protocol >>>that requires a lot of policy engineering in order for it to be >>>effective. >>> >>> >f. Based on c, how would you say that it makes things more >>> >complicated to >>> >run iBGP only compared to IGP+0.0.0.0/0 (default originate and >>> >originate >>> >always) and all those things taken into consideration? >>> >>>Are you talking about running in an enterprise? Default routes will not >>>work in any large environment for next-hop discovery of your iBGP peer >>>IP's. >>>Loops would abound... >>> >>> >>>One of the problems with your proposal, and the primary reason this is >>>not >>>done, is that iBGP does not provide for transitive route dissemination in >>>a >>>network. All 'other' IGPs do this. This means your network topology >>>must >>>be highly symmetrical and/or fully meshed at layer 3 (at least in >>>subsections) to allow for end-to-end route propagation. Unless you can >>>employ lots of confeds (ie, each router in a confed subAS), lots of >>>route-reflectors, or a full-mesh topology at layer 3 (and layer 2 if you >>>consider multiaccess networks fully-meshed), then this approach is not >>>possible. >>> >>>BGP also has race-condition mitigation rules that prevent a BGP route >>>from >>>being learned from a next-hop that is known via BGP, so injecting routes >>>into BGP and hoping to bootstrap the next-hops would be problematic. >>>This >>>restriction is subtle and perhaps vendor specific, but usually, the >>>next-hop >>>is recursed through an IGP or connected interface. If this were >>>possible, >>>in any event, it would be slow-converging, as iBGP updates are typically >>>spaced at 5 second intervals (depending on the event type). Also, you >>>will >>>have to peer with every interface on the device, thus forcing traffic to >>>take certain paths that may not be the best path available, as most BGP >>>attributes are non-accumulating (ie, u have to statically increase, say, >>>local-pref via policy as routes propagate along a set of routers in your >>>AS). >>> >>>The reality is that even if such an approach _were_ possible, the >>>drawbacks >>>are much more severe than simply turning on an IGP and having it discover >>>your topology. Then, you may do what you with with iBGP. >>> >>>The best philosophy, IMO, is to place loopbacks and links in your IGP, >>>and >>>carry externals (either self-originated or from another AS) in your iBGP. >>>Route-reflectors are useful if regionalized, as they make best path >>>decisions before reflecting (so u want to be careful who peers with what >>>to >>>ensure path selection optimality). Confeds afford more control, TE, >>>etc., >>>but at what some claim to be a higher admin cost. Use them based on what >>>you are trying to do. >>> >>>HTH, >>>Chris >>> >>> >would be great if you could help clarify this. >>> > >>> >-Smith >>> > >>> >>> >>> >>> >>> >>> >>> > >>> > >>> > >>> > >>> >You could certainly run BGP and statics without another >>> >protocol for the >>> >IGP, but why would you want to? Convergence times, CPU load on >>> >RPs, etc., >>> >during changes would be rather unsatisfactory. If you want to run one >>> >dynamic protocol at all costs, then what you describe below >>> >will work, and >>> >has worked for some, but people with real traffic don't waste >>> >their time >>> >with it. >>> > >>> > >>> >Ben >>> > >>> >On Mar 15, 2004, at 8:24 PM, John Smith wrote: >>> > >>> > >>> >Hi, >>> > >>> >I am very clear with the concept that IGPs cannot be used to carry the >>> >entire BGP feed as >>> >they cant be scaled to carry so many prefixes (even assuming >>> >we add enough >>> >TLVs to make >>> >them carry the BGP attributes). >>> > >>> >What is not very clear to me is, why cant we use IBGP inside an AS to >>> >completely do away >>> >with IGPs. IGPs compute the best path to reach a particular >>> >neighbor based >>> >on the link >>> >metric. This can be achieved in BGP also, if we include a TLV >>> >to carry the >>> >link cost. >>> >Moreover, it is *mandatory* to run BGP on all the routers if we are >>> >transiting traffic, >>> >because if a router isnt speaking BGP then it cant forward BGP traffic. >>> > >>> >Cant we do away with IGPs (say in some small networks) and run >>> >only IBGP >>> >there? >>> > >>> >Any help/clues/pointers in this regard will be really appreciated. >>> > >>> >Regards, >>> >Smith >>> > >>> >_________________________________________________________________ >>> >Tired of spam? Get advanced junk mail protection with MSN 8. >>> >http://join.msn.com/?page=features/junkmail >>> > >>> > >>> >_______________________________________________ >>> >Idr mailing list >>> >Idr@ietf.org >>> >https://www1.ietf.org/mailman/listinfo/idr >>> > >> >>_________________________________________________________________ >>MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. >>http://join.msn.com/?page=features/virus >> >> >>_______________________________________________ >>Idr mailing list >>Idr@ietf.org >>https://www1.ietf.org/mailman/listinfo/idr >> >> > _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 23 19:13:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13671 for ; Tue, 23 Mar 2004 19:13:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5w1d-0004nX-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 19:13:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5w0a-0004h7-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 19:12:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5vzj-0004cc-00; Tue, 23 Mar 2004 19:11:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vz5-0006Jv-GT; Tue, 23 Mar 2004 19:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uvt-0003Z0-79 for idr@optimus.ietf.org; Tue, 23 Mar 2004 18:03:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09151 for ; Tue, 23 Mar 2004 18:03:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uvq-0006fC-00 for idr@ietf.org; Tue, 23 Mar 2004 18:03:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5uus-0006bK-00 for idr@ietf.org; Tue, 23 Mar 2004 18:02:39 -0500 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx with smtp (Exim 4.12) id 1B5uuO-0006XA-00 for idr@ietf.org; Tue, 23 Mar 2004 18:02:08 -0500 Received: (qmail 55861 invoked from network); 23 Mar 2004 23:01:38 -0000 Received: from 207-171-180-101.amazon.com (HELO ?10.21.134.173?) (ben@207.171.180.101) by layer8.net with SMTP; 23 Mar 2004 23:01:38 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0D84F406-7D1E-11D8-9C3C-000A95DA7468@layer8.net> Content-Transfer-Encoding: 7bit Cc: cmartin@gnilink.net, idr@ietf.org From: Benjamin Black Subject: Re: [Idr] IBGP to replace IGP To: "john smith" X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 15:01:43 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit from the sound of things you don't need bgp at all, except to announce routes to your upstreams. rejecting all routes from a peer tends to limit the size of adj-rib-in as well as reduce the cpu load of route flaps. handle the rest with an igp and a default and you are done (and your network admins need know almost nothing about bgp). ben On Mar 23, 2004, at 2:43 PM, john smith wrote: > Check my reply to Ben, it covers a lot of commong ground > > I think you missed out the point that I was planning to put 0.0.0.0/0 > in the intermediate nodes to cover the internet. > > It is nothing buy my IGP replaced with BGP. 0.0.0.0/0 and all that > being considered for intermediate nodes. > > Route flaps are a result of "actualy flaps somewhere" and if you were > to follow the 0.0.0.0/0 principal neither would your intermediate > nodes give a problem. > > The loops would abound in case of any IGP too when u inject 0.0.0.0/0 > into the IGP, so maybe I didnt quite get that point > >> From: "Martin, Christian" >> To: 'john smith' , "'idr@ietf.org'" >> >> Subject: RE: [Idr] IBGP to replace IGP >> Date: Tue, 23 Mar 2004 17:35:58 -0500 >> >> Smith, >> >> Comments inline, as I have been following this thread. >> >> >> >It would be great if you could share some more information on >> >the "issues" >> >of convergence time, CPU loads, and RP overloads. >> >> Convergence is typically nonlienearly proportionate to CPU load, and >> vice-versa, and they often feed off each other in a negative way. >> Network >> meltdowns are typically the result of routing loads disrupting >> topology >> maintenance mechanisms, thereby causing adjacency loss, which causes >> more >> routing load, which inhibits adjacency recreation, etc. I've seen >> networks >> stay in persistent "ditches" because the >> convergence-adjacency-divergence-adjaceny-...loop stayed closed due to >> loading. Not fun to have to rebuild all of your routers or reattach >> them to >> the network one by one... >> >> >From my understanding >> >a. it makes more sense to have 1 routing protocol as we dont >> >have multiple >> >daemons scheduled on the CPU. (which ofcourse is not a problem >> >but then so >> >is the point you mentioned below) >> >> In either case, BGP will consume the vast majority of CPU cycles. >> IGPs that >> are properly tuned in stable environments hardly tickle the CPU, let >> alone >> heat it up. Take LSA/P refresh out of the picture, and all the IGP >> does is >> send hellos and occasionally flood an LSA/P and compute an SPT once >> in a >> rare while. In the Internet, BGP is constantly processing updates and >> withdrawals, all day, every day. Sometimes, we see 100s of updates >> per >> minute, sometimes just a few, but they are always there. >> >> >b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like >> we >> >inject 0.0.0.0/0 into IGP to make unknown prefixes go to the >> >nearest BGP >> >node.So does that help reduce the size of your routing table? >> >> Large SPs must run a full BGP load, at a minimum, to give routes to >> their >> customers. Unless you are talking about enterprise routing, we >> should avoid >> discussions of default routes... >> >> >c. The cases u mention of changes, I presume you mean >> >route-flaps. Well in >> >that case, we eitherways have issues when IGP flaps, we >> >eitherways wait for >> >IGP to converge for BGP to converge etc? (I am sure "real >> >traffic" operators >> >do that) >> >> Modern IGPs, properly tuned, converge way faster than BGP. BGP >> convergence >> is designed to be slow, so as not to place too much load on the global >> routing system. Since BGP carries so many routes, and since the >> topological >> density of the Internet Autonomous System graph increases every day, >> BGP can >> often take minutes to converge. IGPs take seconds, partly because >> they are >> usually lightweight. >> >> >d. We have the benefits of not having the "global view" dependent on >> 1 >> >protocol while the internal topology dependent on another >> >> This is actually a sound design. Think of the IGP as a topology >> discovery >> mechanism. All BGP routes have a next-hop. The goal of BGP is to >> take >> traffic to and from the "edges" of the network. Sometimes, the edge >> is >> within your network, like a server farm. IGPs are very good at >> discovering >> a topology and identifying the shortest path to each edge. BGP is not >> designed for this, and to make it do so requires considerable >> planning and >> lots of policy. >> >> >e. all i need to teach the network admins is BGP :) >> >> It is much easier to learn simple IS-IS and OSPF than BGP. Link >> State IGPs, >> when employed for topology discovery, are exceedingly simple >> (particularly >> IS-IS in a single area). BGP, on the otherhand, is a much bigger >> protocol >> that requires a lot of policy engineering in order for it to be >> effective. >> >> >f. Based on c, how would you say that it makes things more >> >complicated to >> >run iBGP only compared to IGP+0.0.0.0/0 (default originate and >> >originate >> >always) and all those things taken into consideration? >> >> Are you talking about running in an enterprise? Default routes will >> not >> work in any large environment for next-hop discovery of your iBGP >> peer IP's. >> Loops would abound... >> >> >> One of the problems with your proposal, and the primary reason this >> is not >> done, is that iBGP does not provide for transitive route >> dissemination in a >> network. All 'other' IGPs do this. This means your network topology >> must >> be highly symmetrical and/or fully meshed at layer 3 (at least in >> subsections) to allow for end-to-end route propagation. Unless you >> can >> employ lots of confeds (ie, each router in a confed subAS), lots of >> route-reflectors, or a full-mesh topology at layer 3 (and layer 2 if >> you >> consider multiaccess networks fully-meshed), then this approach is not >> possible. >> >> BGP also has race-condition mitigation rules that prevent a BGP route >> from >> being learned from a next-hop that is known via BGP, so injecting >> routes >> into BGP and hoping to bootstrap the next-hops would be problematic. >> This >> restriction is subtle and perhaps vendor specific, but usually, the >> next-hop >> is recursed through an IGP or connected interface. If this were >> possible, >> in any event, it would be slow-converging, as iBGP updates are >> typically >> spaced at 5 second intervals (depending on the event type). Also, >> you will >> have to peer with every interface on the device, thus forcing traffic >> to >> take certain paths that may not be the best path available, as most >> BGP >> attributes are non-accumulating (ie, u have to statically increase, >> say, >> local-pref via policy as routes propagate along a set of routers in >> your >> AS). >> >> The reality is that even if such an approach _were_ possible, the >> drawbacks >> are much more severe than simply turning on an IGP and having it >> discover >> your topology. Then, you may do what you with with iBGP. >> >> The best philosophy, IMO, is to place loopbacks and links in your >> IGP, and >> carry externals (either self-originated or from another AS) in your >> iBGP. >> Route-reflectors are useful if regionalized, as they make best path >> decisions before reflecting (so u want to be careful who peers with >> what to >> ensure path selection optimality). Confeds afford more control, TE, >> etc., >> but at what some claim to be a higher admin cost. Use them based on >> what >> you are trying to do. >> >> HTH, >> Chris >> >> >would be great if you could help clarify this. >> > >> >-Smith >> > >> >> >> >> >> >> >> > >> > >> > >> > >> >You could certainly run BGP and statics without another >> >protocol for the >> >IGP, but why would you want to? Convergence times, CPU load on >> >RPs, etc., >> >during changes would be rather unsatisfactory. If you want to run one >> >dynamic protocol at all costs, then what you describe below >> >will work, and >> >has worked for some, but people with real traffic don't waste >> >their time >> >with it. >> > >> > >> >Ben >> > >> >On Mar 15, 2004, at 8:24 PM, John Smith wrote: >> > >> > >> >Hi, >> > >> >I am very clear with the concept that IGPs cannot be used to carry >> the >> >entire BGP feed as >> >they cant be scaled to carry so many prefixes (even assuming >> >we add enough >> >TLVs to make >> >them carry the BGP attributes). >> > >> >What is not very clear to me is, why cant we use IBGP inside an AS to >> >completely do away >> >with IGPs. IGPs compute the best path to reach a particular >> >neighbor based >> >on the link >> >metric. This can be achieved in BGP also, if we include a TLV >> >to carry the >> >link cost. >> >Moreover, it is *mandatory* to run BGP on all the routers if we are >> >transiting traffic, >> >because if a router isnt speaking BGP then it cant forward BGP >> traffic. >> > >> >Cant we do away with IGPs (say in some small networks) and run >> >only IBGP >> >there? >> > >> >Any help/clues/pointers in this regard will be really appreciated. >> > >> >Regards, >> >Smith >> > >> >_________________________________________________________________ >> >Tired of spam? Get advanced junk mail protection with MSN 8. >> >http://join.msn.com/?page=features/junkmail >> > >> > >> >_______________________________________________ >> >Idr mailing list >> >Idr@ietf.org >> >https://www1.ietf.org/mailman/listinfo/idr >> > > > _________________________________________________________________ > MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. > http://join.msn.com/?page=features/virus > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 23 19:14:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13733 for ; Tue, 23 Mar 2004 19:14:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5w1h-0006o4-O3 for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 19:13:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O0Djak026158 for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 19:13:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5w1h-0006np-KZ for idr-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 19:13:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13707 for ; Tue, 23 Mar 2004 19:13:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5w1g-0004nu-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 19:13:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5w0d-0004hT-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 19:12:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5vzj-0004cd-00; Tue, 23 Mar 2004 19:11:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vz4-0006Jk-Re; Tue, 23 Mar 2004 19:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5u9Q-0005Mg-AF for idr@optimus.ietf.org; Tue, 23 Mar 2004 17:13:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06601 for ; Tue, 23 Mar 2004 17:13:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5u9O-00024f-00 for idr@ietf.org; Tue, 23 Mar 2004 17:13:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5u8V-000216-00 for idr@ietf.org; Tue, 23 Mar 2004 17:12:40 -0500 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx with smtp (Exim 4.12) id 1B5u7v-0001vf-00 for idr@ietf.org; Tue, 23 Mar 2004 17:12:03 -0500 Received: (qmail 54988 invoked from network); 23 Mar 2004 22:11:33 -0000 Received: from 207-171-180-101.amazon.com (HELO ?10.21.134.173?) (ben@207.171.180.101) by layer8.net with SMTP; 23 Mar 2004 22:11:33 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0FA21A83-7D17-11D8-98C8-000A95DA7468@layer8.net> Content-Transfer-Encoding: 7bit Cc: idr@ietf.org From: Benjamin Black Subject: Re: [Idr] IBGP to replace IGP To: "john smith" X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 14:11:40 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit a) scheduling is a minor concern. b) certainly carrying a default helps reduce the size of the table, but that is orthogonal to the question. it is not common practice to carry much in the igp (meaning bgp is not redistributed into the igp), so carrying a default really is reducing the size of your bgp ribs which is something you can do regardless of whether you have a second protocol for the igp. c) yes, flapping routes are a problem regardless of protocol, so you generally want one that converges very quickly. a good link-state protocol like ospf converges in seconds vs minutes for bgp in a reasonably complex network. again, the igp is only carrying limited information (links and loops being a very common scenario) and has very detailed knowledge of the network (handling per-link metrics in bgp would get very ugly very fast) so it can do things that are inconvenient or impossible with bgp. d) i don't know what benefits you mean. decoupling the churn of the "global view" from the stability of your internal network supports using an independent igp. e) if they can't understand ospf they shouldn't be touching the routers anyway. f) i'm not suggesting the use of a default route. your questions (and name) seem more like someone lost from nanog looking to do some trolling than someone interested in discussing protocols, but i could be wrong. ben On Mar 22, 2004, at 7:22 PM, john smith wrote: > Hi Ben, > > It would be great if you could share some more information on the > "issues" of convergence time, CPU loads, and RP overloads. > > From my understanding > a. it makes more sense to have 1 routing protocol as we dont have > multiple daemons scheduled on the CPU. (which ofcourse is not a > problem but then so is the point you mentioned below) > > b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we > inject 0.0.0.0/0 into IGP to make unknown prefixes go to the nearest > BGP node.So does that help reduce the size of your routing table? > > c. The cases u mention of changes, I presume you mean route-flaps. > Well in that case, we eitherways have issues when IGP flaps, we > eitherways wait for IGP to converge for BGP to converge etc? (I am > sure "real traffic" operators do that) > > d. We have the benefits of not having the "global view" dependent on 1 > protocol while the internal topology dependent on another > > e. all i need to teach the network admins is BGP :) > > f. Based on c, how would you say that it makes things more complicated > to run iBGP only compared to IGP+0.0.0.0/0 (default originate and > originate always) and all those things taken into consideration? > > would be great if you could help clarify this. > > -Smith > > > > > > > You could certainly run BGP and statics without another protocol for > the IGP, but why would you want to? Convergence times, CPU load on > RPs, etc., during changes would be rather unsatisfactory. If you want > to run one dynamic protocol at all costs, then what you describe below > will work, and has worked for some, but people with real traffic don't > waste their time with it. > > > Ben > > On Mar 15, 2004, at 8:24 PM, John Smith wrote: > > > Hi, > > I am very clear with the concept that IGPs cannot be used to carry the > entire BGP feed as > they cant be scaled to carry so many prefixes (even assuming we add > enough TLVs to make > them carry the BGP attributes). > > What is not very clear to me is, why cant we use IBGP inside an AS to > completely do away > with IGPs. IGPs compute the best path to reach a particular neighbor > based on the link > metric. This can be achieved in BGP also, if we include a TLV to carry > the link cost. > Moreover, it is *mandatory* to run BGP on all the routers if we are > transiting traffic, > because if a router isnt speaking BGP then it cant forward BGP traffic. > > Cant we do away with IGPs (say in some small networks) and run only > IBGP there? > > Any help/clues/pointers in this regard will be really appreciated. > > Regards, > Smith > > _________________________________________________________________ > Tired of spam? Get advanced junk mail protection with MSN 8. > http://join.msn.com/?page=features/junkmail > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 23 19:14:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13732 for ; Tue, 23 Mar 2004 19:14:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5w1g-0006nh-P8 for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 19:13:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O0DiV7026142 for idr-archive@odin.ietf.org; Tue, 23 Mar 2004 19:13:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5w1g-0006nZ-Jp for idr-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 19:13:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13674 for ; Tue, 23 Mar 2004 19:13:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5w1d-0004nc-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 19:13:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5w0b-0004hE-00 for idr-web-archive@ietf.org; Tue, 23 Mar 2004 19:12:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5vzj-0004cc-00; Tue, 23 Mar 2004 19:11:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vz5-0006Jv-GT; Tue, 23 Mar 2004 19:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uvt-0003Z0-79 for idr@optimus.ietf.org; Tue, 23 Mar 2004 18:03:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09151 for ; Tue, 23 Mar 2004 18:03:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uvq-0006fC-00 for idr@ietf.org; Tue, 23 Mar 2004 18:03:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5uus-0006bK-00 for idr@ietf.org; Tue, 23 Mar 2004 18:02:39 -0500 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx with smtp (Exim 4.12) id 1B5uuO-0006XA-00 for idr@ietf.org; Tue, 23 Mar 2004 18:02:08 -0500 Received: (qmail 55861 invoked from network); 23 Mar 2004 23:01:38 -0000 Received: from 207-171-180-101.amazon.com (HELO ?10.21.134.173?) (ben@207.171.180.101) by layer8.net with SMTP; 23 Mar 2004 23:01:38 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0D84F406-7D1E-11D8-9C3C-000A95DA7468@layer8.net> Content-Transfer-Encoding: 7bit Cc: cmartin@gnilink.net, idr@ietf.org From: Benjamin Black Subject: Re: [Idr] IBGP to replace IGP To: "john smith" X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 15:01:43 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit from the sound of things you don't need bgp at all, except to announce routes to your upstreams. rejecting all routes from a peer tends to limit the size of adj-rib-in as well as reduce the cpu load of route flaps. handle the rest with an igp and a default and you are done (and your network admins need know almost nothing about bgp). ben On Mar 23, 2004, at 2:43 PM, john smith wrote: > Check my reply to Ben, it covers a lot of commong ground > > I think you missed out the point that I was planning to put 0.0.0.0/0 > in the intermediate nodes to cover the internet. > > It is nothing buy my IGP replaced with BGP. 0.0.0.0/0 and all that > being considered for intermediate nodes. > > Route flaps are a result of "actualy flaps somewhere" and if you were > to follow the 0.0.0.0/0 principal neither would your intermediate > nodes give a problem. > > The loops would abound in case of any IGP too when u inject 0.0.0.0/0 > into the IGP, so maybe I didnt quite get that point > >> From: "Martin, Christian" >> To: 'john smith' , "'idr@ietf.org'" >> >> Subject: RE: [Idr] IBGP to replace IGP >> Date: Tue, 23 Mar 2004 17:35:58 -0500 >> >> Smith, >> >> Comments inline, as I have been following this thread. >> >> >> >It would be great if you could share some more information on >> >the "issues" >> >of convergence time, CPU loads, and RP overloads. >> >> Convergence is typically nonlienearly proportionate to CPU load, and >> vice-versa, and they often feed off each other in a negative way. >> Network >> meltdowns are typically the result of routing loads disrupting >> topology >> maintenance mechanisms, thereby causing adjacency loss, which causes >> more >> routing load, which inhibits adjacency recreation, etc. I've seen >> networks >> stay in persistent "ditches" because the >> convergence-adjacency-divergence-adjaceny-...loop stayed closed due to >> loading. Not fun to have to rebuild all of your routers or reattach >> them to >> the network one by one... >> >> >From my understanding >> >a. it makes more sense to have 1 routing protocol as we dont >> >have multiple >> >daemons scheduled on the CPU. (which ofcourse is not a problem >> >but then so >> >is the point you mentioned below) >> >> In either case, BGP will consume the vast majority of CPU cycles. >> IGPs that >> are properly tuned in stable environments hardly tickle the CPU, let >> alone >> heat it up. Take LSA/P refresh out of the picture, and all the IGP >> does is >> send hellos and occasionally flood an LSA/P and compute an SPT once >> in a >> rare while. In the Internet, BGP is constantly processing updates and >> withdrawals, all day, every day. Sometimes, we see 100s of updates >> per >> minute, sometimes just a few, but they are always there. >> >> >b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like >> we >> >inject 0.0.0.0/0 into IGP to make unknown prefixes go to the >> >nearest BGP >> >node.So does that help reduce the size of your routing table? >> >> Large SPs must run a full BGP load, at a minimum, to give routes to >> their >> customers. Unless you are talking about enterprise routing, we >> should avoid >> discussions of default routes... >> >> >c. The cases u mention of changes, I presume you mean >> >route-flaps. Well in >> >that case, we eitherways have issues when IGP flaps, we >> >eitherways wait for >> >IGP to converge for BGP to converge etc? (I am sure "real >> >traffic" operators >> >do that) >> >> Modern IGPs, properly tuned, converge way faster than BGP. BGP >> convergence >> is designed to be slow, so as not to place too much load on the global >> routing system. Since BGP carries so many routes, and since the >> topological >> density of the Internet Autonomous System graph increases every day, >> BGP can >> often take minutes to converge. IGPs take seconds, partly because >> they are >> usually lightweight. >> >> >d. We have the benefits of not having the "global view" dependent on >> 1 >> >protocol while the internal topology dependent on another >> >> This is actually a sound design. Think of the IGP as a topology >> discovery >> mechanism. All BGP routes have a next-hop. The goal of BGP is to >> take >> traffic to and from the "edges" of the network. Sometimes, the edge >> is >> within your network, like a server farm. IGPs are very good at >> discovering >> a topology and identifying the shortest path to each edge. BGP is not >> designed for this, and to make it do so requires considerable >> planning and >> lots of policy. >> >> >e. all i need to teach the network admins is BGP :) >> >> It is much easier to learn simple IS-IS and OSPF than BGP. Link >> State IGPs, >> when employed for topology discovery, are exceedingly simple >> (particularly >> IS-IS in a single area). BGP, on the otherhand, is a much bigger >> protocol >> that requires a lot of policy engineering in order for it to be >> effective. >> >> >f. Based on c, how would you say that it makes things more >> >complicated to >> >run iBGP only compared to IGP+0.0.0.0/0 (default originate and >> >originate >> >always) and all those things taken into consideration? >> >> Are you talking about running in an enterprise? Default routes will >> not >> work in any large environment for next-hop discovery of your iBGP >> peer IP's. >> Loops would abound... >> >> >> One of the problems with your proposal, and the primary reason this >> is not >> done, is that iBGP does not provide for transitive route >> dissemination in a >> network. All 'other' IGPs do this. This means your network topology >> must >> be highly symmetrical and/or fully meshed at layer 3 (at least in >> subsections) to allow for end-to-end route propagation. Unless you >> can >> employ lots of confeds (ie, each router in a confed subAS), lots of >> route-reflectors, or a full-mesh topology at layer 3 (and layer 2 if >> you >> consider multiaccess networks fully-meshed), then this approach is not >> possible. >> >> BGP also has race-condition mitigation rules that prevent a BGP route >> from >> being learned from a next-hop that is known via BGP, so injecting >> routes >> into BGP and hoping to bootstrap the next-hops would be problematic. >> This >> restriction is subtle and perhaps vendor specific, but usually, the >> next-hop >> is recursed through an IGP or connected interface. If this were >> possible, >> in any event, it would be slow-converging, as iBGP updates are >> typically >> spaced at 5 second intervals (depending on the event type). Also, >> you will >> have to peer with every interface on the device, thus forcing traffic >> to >> take certain paths that may not be the best path available, as most >> BGP >> attributes are non-accumulating (ie, u have to statically increase, >> say, >> local-pref via policy as routes propagate along a set of routers in >> your >> AS). >> >> The reality is that even if such an approach _were_ possible, the >> drawbacks >> are much more severe than simply turning on an IGP and having it >> discover >> your topology. Then, you may do what you with with iBGP. >> >> The best philosophy, IMO, is to place loopbacks and links in your >> IGP, and >> carry externals (either self-originated or from another AS) in your >> iBGP. >> Route-reflectors are useful if regionalized, as they make best path >> decisions before reflecting (so u want to be careful who peers with >> what to >> ensure path selection optimality). Confeds afford more control, TE, >> etc., >> but at what some claim to be a higher admin cost. Use them based on >> what >> you are trying to do. >> >> HTH, >> Chris >> >> >would be great if you could help clarify this. >> > >> >-Smith >> > >> >> >> >> >> >> >> > >> > >> > >> > >> >You could certainly run BGP and statics without another >> >protocol for the >> >IGP, but why would you want to? Convergence times, CPU load on >> >RPs, etc., >> >during changes would be rather unsatisfactory. If you want to run one >> >dynamic protocol at all costs, then what you describe below >> >will work, and >> >has worked for some, but people with real traffic don't waste >> >their time >> >with it. >> > >> > >> >Ben >> > >> >On Mar 15, 2004, at 8:24 PM, John Smith wrote: >> > >> > >> >Hi, >> > >> >I am very clear with the concept that IGPs cannot be used to carry >> the >> >entire BGP feed as >> >they cant be scaled to carry so many prefixes (even assuming >> >we add enough >> >TLVs to make >> >them carry the BGP attributes). >> > >> >What is not very clear to me is, why cant we use IBGP inside an AS to >> >completely do away >> >with IGPs. IGPs compute the best path to reach a particular >> >neighbor based >> >on the link >> >metric. This can be achieved in BGP also, if we include a TLV >> >to carry the >> >link cost. >> >Moreover, it is *mandatory* to run BGP on all the routers if we are >> >transiting traffic, >> >because if a router isnt speaking BGP then it cant forward BGP >> traffic. >> > >> >Cant we do away with IGPs (say in some small networks) and run >> >only IBGP >> >there? >> > >> >Any help/clues/pointers in this regard will be really appreciated. >> > >> >Regards, >> >Smith >> > >> >_________________________________________________________________ >> >Tired of spam? Get advanced junk mail protection with MSN 8. >> >http://join.msn.com/?page=features/junkmail >> > >> > >> >_______________________________________________ >> >Idr mailing list >> >Idr@ietf.org >> >https://www1.ietf.org/mailman/listinfo/idr >> > > > _________________________________________________________________ > MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. > http://join.msn.com/?page=features/virus > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Tue Mar 23 20:03:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13677 for ; Tue, 23 Mar 2004 19:13:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5w1e-0004nh-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 19:13:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5w0c-0004hM-00 for idr-archive@ietf.org; Tue, 23 Mar 2004 19:12:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5vzj-0004cd-00; Tue, 23 Mar 2004 19:11:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vz4-0006Jk-Re; Tue, 23 Mar 2004 19:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5u9Q-0005Mg-AF for idr@optimus.ietf.org; Tue, 23 Mar 2004 17:13:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06601 for ; Tue, 23 Mar 2004 17:13:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5u9O-00024f-00 for idr@ietf.org; Tue, 23 Mar 2004 17:13:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5u8V-000216-00 for idr@ietf.org; Tue, 23 Mar 2004 17:12:40 -0500 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx with smtp (Exim 4.12) id 1B5u7v-0001vf-00 for idr@ietf.org; Tue, 23 Mar 2004 17:12:03 -0500 Received: (qmail 54988 invoked from network); 23 Mar 2004 22:11:33 -0000 Received: from 207-171-180-101.amazon.com (HELO ?10.21.134.173?) (ben@207.171.180.101) by layer8.net with SMTP; 23 Mar 2004 22:11:33 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0FA21A83-7D17-11D8-98C8-000A95DA7468@layer8.net> Content-Transfer-Encoding: 7bit Cc: idr@ietf.org From: Benjamin Black Subject: Re: [Idr] IBGP to replace IGP To: "john smith" X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 14:11:40 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit a) scheduling is a minor concern. b) certainly carrying a default helps reduce the size of the table, but that is orthogonal to the question. it is not common practice to carry much in the igp (meaning bgp is not redistributed into the igp), so carrying a default really is reducing the size of your bgp ribs which is something you can do regardless of whether you have a second protocol for the igp. c) yes, flapping routes are a problem regardless of protocol, so you generally want one that converges very quickly. a good link-state protocol like ospf converges in seconds vs minutes for bgp in a reasonably complex network. again, the igp is only carrying limited information (links and loops being a very common scenario) and has very detailed knowledge of the network (handling per-link metrics in bgp would get very ugly very fast) so it can do things that are inconvenient or impossible with bgp. d) i don't know what benefits you mean. decoupling the churn of the "global view" from the stability of your internal network supports using an independent igp. e) if they can't understand ospf they shouldn't be touching the routers anyway. f) i'm not suggesting the use of a default route. your questions (and name) seem more like someone lost from nanog looking to do some trolling than someone interested in discussing protocols, but i could be wrong. ben On Mar 22, 2004, at 7:22 PM, john smith wrote: > Hi Ben, > > It would be great if you could share some more information on the > "issues" of convergence time, CPU loads, and RP overloads. > > From my understanding > a. it makes more sense to have 1 routing protocol as we dont have > multiple daemons scheduled on the CPU. (which ofcourse is not a > problem but then so is the point you mentioned below) > > b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we > inject 0.0.0.0/0 into IGP to make unknown prefixes go to the nearest > BGP node.So does that help reduce the size of your routing table? > > c. The cases u mention of changes, I presume you mean route-flaps. > Well in that case, we eitherways have issues when IGP flaps, we > eitherways wait for IGP to converge for BGP to converge etc? (I am > sure "real traffic" operators do that) > > d. We have the benefits of not having the "global view" dependent on 1 > protocol while the internal topology dependent on another > > e. all i need to teach the network admins is BGP :) > > f. Based on c, how would you say that it makes things more complicated > to run iBGP only compared to IGP+0.0.0.0/0 (default originate and > originate always) and all those things taken into consideration? > > would be great if you could help clarify this. > > -Smith > > > > > > > You could certainly run BGP and statics without another protocol for > the IGP, but why would you want to? Convergence times, CPU load on > RPs, etc., during changes would be rather unsatisfactory. If you want > to run one dynamic protocol at all costs, then what you describe below > will work, and has worked for some, but people with real traffic don't > waste their time with it. > > > Ben > > On Mar 15, 2004, at 8:24 PM, John Smith wrote: > > > Hi, > > I am very clear with the concept that IGPs cannot be used to carry the > entire BGP feed as > they cant be scaled to carry so many prefixes (even assuming we add > enough TLVs to make > them carry the BGP attributes). > > What is not very clear to me is, why cant we use IBGP inside an AS to > completely do away > with IGPs. IGPs compute the best path to reach a particular neighbor > based on the link > metric. This can be achieved in BGP also, if we include a TLV to carry > the link cost. > Moreover, it is *mandatory* to run BGP on all the routers if we are > transiting traffic, > because if a router isnt speaking BGP then it cant forward BGP traffic. > > Cant we do away with IGPs (say in some small networks) and run only > IBGP there? > > Any help/clues/pointers in this regard will be really appreciated. > > Regards, > Smith > > _________________________________________________________________ > Tired of spam? Get advanced junk mail protection with MSN 8. > http://join.msn.com/?page=features/junkmail > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Thu Mar 25 17:18:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27789 for ; Thu, 25 Mar 2004 17:18:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6dBD-0007IE-00 for idr-archive@ietf.org; Thu, 25 Mar 2004 17:18:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6d9b-00073e-00 for idr-archive@ietf.org; Thu, 25 Mar 2004 17:16:48 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6d8N-0006tn-01; Thu, 25 Mar 2004 17:15:31 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B6cx1-0006FX-TI; Thu, 25 Mar 2004 17:03:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cwH-0006yD-B5; Thu, 25 Mar 2004 17:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cvY-0006sH-LS for idr@optimus.ietf.org; Thu, 25 Mar 2004 17:02:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27185 for ; Thu, 25 Mar 2004 17:02:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6cvW-0006M9-00 for idr@ietf.org; Thu, 25 Mar 2004 17:02:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ctt-0006Cg-00 for idr@ietf.org; Thu, 25 Mar 2004 17:00:34 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1B6ct5-00069R-00 for idr@ietf.org; Thu, 25 Mar 2004 16:59:43 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id B1F2880F683; Thu, 25 Mar 2004 13:59:43 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23881-09; Thu, 25 Mar 2004 13:59:43 -0800 (PST) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id 5C70280F682; Thu, 25 Mar 2004 13:59:43 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv2.redback.com (Postfix) with ESMTP id 1EE54979C1; Thu, 25 Mar 2004 13:59:43 -0800 (PST) To: idr@ietf.org Cc: enke@redback.com From: Enke Chen Message-Id: <20040325215943.1EE54979C1@popserv2.redback.com> X-Virus-Scanned: by amavisd-new at redback.com Subject: [Idr] Implementation survey for BGP Cease Subcodes Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 25 Mar 2004 13:59:43 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, folks: In order to progress the BGP Cease Subcodes, we need an implementation report. For folks that have implemented the draft, could you please fill out the simple survey (attached), and send to me by April 9, 2004? Thanks. -- Enke --------------------------------------------------------------------- Implementation Report for BGP Cease Subcodes (draft-ietf-idr-cease-subcode-05.txt) Organization: Person filling out this form: Does your implementation recognize all the subcodes defined in the document? (If not, list the subcodes that your implementation recognizes.) List the subcodes that your implementation may send as part of a NOTIFICATION message. Does your implementation include the Address Family information and the upper bound in the "Data" field of a NOTIFICATION message for the subcode "maximum number of prefixes reached"? Does your implementation implement a backoff mechanism in re-trying a BGP connection, as recommended in the document? List other implementations that you have tested for BGP Cease Subcodes interoperability. --------------------------------------------------------------------- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Thu Mar 25 17:18:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28015 for ; Thu, 25 Mar 2004 17:18:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6dBH-0001K7-9m for idr-archive@odin.ietf.org; Thu, 25 Mar 2004 17:18:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PMIVth005086 for idr-archive@odin.ietf.org; Thu, 25 Mar 2004 17:18:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6dBH-0001Jx-5o for idr-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 17:18:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27809 for ; Thu, 25 Mar 2004 17:18:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6dBE-0007IT-00 for idr-web-archive@ietf.org; Thu, 25 Mar 2004 17:18:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6d9c-00073m-00 for idr-web-archive@ietf.org; Thu, 25 Mar 2004 17:16:49 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6d8N-0006tn-01; Thu, 25 Mar 2004 17:15:31 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B6cx1-0006FX-TI; Thu, 25 Mar 2004 17:03:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cwH-0006yD-B5; Thu, 25 Mar 2004 17:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cvY-0006sH-LS for idr@optimus.ietf.org; Thu, 25 Mar 2004 17:02:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27185 for ; Thu, 25 Mar 2004 17:02:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6cvW-0006M9-00 for idr@ietf.org; Thu, 25 Mar 2004 17:02:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ctt-0006Cg-00 for idr@ietf.org; Thu, 25 Mar 2004 17:00:34 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1B6ct5-00069R-00 for idr@ietf.org; Thu, 25 Mar 2004 16:59:43 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id B1F2880F683; Thu, 25 Mar 2004 13:59:43 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23881-09; Thu, 25 Mar 2004 13:59:43 -0800 (PST) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id 5C70280F682; Thu, 25 Mar 2004 13:59:43 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv2.redback.com (Postfix) with ESMTP id 1EE54979C1; Thu, 25 Mar 2004 13:59:43 -0800 (PST) To: idr@ietf.org Cc: enke@redback.com From: Enke Chen Message-Id: <20040325215943.1EE54979C1@popserv2.redback.com> X-Virus-Scanned: by amavisd-new at redback.com Subject: [Idr] Implementation survey for BGP Cease Subcodes Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 25 Mar 2004 13:59:43 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, folks: In order to progress the BGP Cease Subcodes, we need an implementation report. For folks that have implemented the draft, could you please fill out the simple survey (attached), and send to me by April 9, 2004? Thanks. -- Enke --------------------------------------------------------------------- Implementation Report for BGP Cease Subcodes (draft-ietf-idr-cease-subcode-05.txt) Organization: Person filling out this form: Does your implementation recognize all the subcodes defined in the document? (If not, list the subcodes that your implementation recognizes.) List the subcodes that your implementation may send as part of a NOTIFICATION message. Does your implementation include the Address Family information and the upper bound in the "Data" field of a NOTIFICATION message for the subcode "maximum number of prefixes reached"? Does your implementation implement a backoff mechanism in re-trying a BGP connection, as recommended in the document? List other implementations that you have tested for BGP Cease Subcodes interoperability. --------------------------------------------------------------------- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Fri Mar 26 15:46:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13736 for ; Fri, 26 Mar 2004 15:46:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6yDS-0005Zj-00 for idr-archive@ietf.org; Fri, 26 Mar 2004 15:46:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6yCV-0005Vs-00 for idr-archive@ietf.org; Fri, 26 Mar 2004 15:45:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6yBb-0005Re-00; Fri, 26 Mar 2004 15:44:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6yBM-0003Un-79; Fri, 26 Mar 2004 15:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6yB6-0003UR-FS for idr@optimus.ietf.org; Fri, 26 Mar 2004 15:43:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13683 for ; Fri, 26 Mar 2004 15:43:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6yB5-0005Ny-00 for idr@ietf.org; Fri, 26 Mar 2004 15:43:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6yA5-0005H5-00 for idr@ietf.org; Fri, 26 Mar 2004 15:42:41 -0500 Received: from bay8-f6.bay8.hotmail.com ([64.4.27.6] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B6y9L-000584-00 for idr@ietf.org; Fri, 26 Mar 2004 15:41:55 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 26 Mar 2004 12:41:24 -0800 Received: from 81.178.20.174 by by8fd.bay8.hotmail.msn.com with HTTP; Fri, 26 Mar 2004 20:41:24 GMT X-Originating-IP: [81.178.20.174] X-Originating-Email: [bob_arthurs@hotmail.com] X-Sender: bob_arthurs@hotmail.com From: "Bob Arthurs" To: idr@ietf.org Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2004 20:41:24.0911 (UTC) FILETIME=[B48633F0:01C41372] Subject: [Idr] Question on draft-ietf-idr-bgp-ext-communities-06 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 26 Mar 2004 20:41:24 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 hello i am doing some research on bgp and i wonder if someone can confirm a point or two on bgp extended communities (specifically route targets in draft-ietf-idr-bgp-ext-communities-06.txt). many thanks for any help in advance. are the following points true? 1. a route target has an extended Type field which is 2 octets long. 2. when the low order octet in the Type field is 0x02 this means that it is a Route Target. 3. When the high order octect in the Type field is 0x00 or 0x02 then the Global Administrator in the Value field is 2 or 4 octets respectively (depending on high order Type value being 0x00 or 0x02). The Local Administrator in this case is 4 or 2 octets respectively. 4. If the high order octet in the Type field is 0x00 or 0x02 then an AS number (either 2 or 4 bytes) is carried in the Global Administrator. 5. If the high order octet in the Type field is 0x01 then an IP address is carried in the Global Administrator part of the Value field. The Global Administrator and Local Administrator in this case are 4 and 2 octets respectively. thanks again, bob _________________________________________________________________ Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Fri Mar 26 15:46:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13781 for ; Fri, 26 Mar 2004 15:46:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6yDU-0003go-HB for idr-archive@odin.ietf.org; Fri, 26 Mar 2004 15:46:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QKkChu014178 for idr-archive@odin.ietf.org; Fri, 26 Mar 2004 15:46:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6yDU-0003gb-DY for idr-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 15:46:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13753 for ; Fri, 26 Mar 2004 15:46:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6yDS-0005Zo-00 for idr-web-archive@ietf.org; Fri, 26 Mar 2004 15:46:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6yCW-0005Vz-00 for idr-web-archive@ietf.org; Fri, 26 Mar 2004 15:45:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6yBb-0005Re-00; Fri, 26 Mar 2004 15:44:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6yBM-0003Un-79; Fri, 26 Mar 2004 15:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6yB6-0003UR-FS for idr@optimus.ietf.org; Fri, 26 Mar 2004 15:43:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13683 for ; Fri, 26 Mar 2004 15:43:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6yB5-0005Ny-00 for idr@ietf.org; Fri, 26 Mar 2004 15:43:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6yA5-0005H5-00 for idr@ietf.org; Fri, 26 Mar 2004 15:42:41 -0500 Received: from bay8-f6.bay8.hotmail.com ([64.4.27.6] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B6y9L-000584-00 for idr@ietf.org; Fri, 26 Mar 2004 15:41:55 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 26 Mar 2004 12:41:24 -0800 Received: from 81.178.20.174 by by8fd.bay8.hotmail.msn.com with HTTP; Fri, 26 Mar 2004 20:41:24 GMT X-Originating-IP: [81.178.20.174] X-Originating-Email: [bob_arthurs@hotmail.com] X-Sender: bob_arthurs@hotmail.com From: "Bob Arthurs" To: idr@ietf.org Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2004 20:41:24.0911 (UTC) FILETIME=[B48633F0:01C41372] Subject: [Idr] Question on draft-ietf-idr-bgp-ext-communities-06 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 26 Mar 2004 20:41:24 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 hello i am doing some research on bgp and i wonder if someone can confirm a point or two on bgp extended communities (specifically route targets in draft-ietf-idr-bgp-ext-communities-06.txt). many thanks for any help in advance. are the following points true? 1. a route target has an extended Type field which is 2 octets long. 2. when the low order octet in the Type field is 0x02 this means that it is a Route Target. 3. When the high order octect in the Type field is 0x00 or 0x02 then the Global Administrator in the Value field is 2 or 4 octets respectively (depending on high order Type value being 0x00 or 0x02). The Local Administrator in this case is 4 or 2 octets respectively. 4. If the high order octet in the Type field is 0x00 or 0x02 then an AS number (either 2 or 4 bytes) is carried in the Global Administrator. 5. If the high order octet in the Type field is 0x01 then an IP address is carried in the Global Administrator part of the Value field. The Global Administrator and Local Administrator in this case are 4 and 2 octets respectively. thanks again, bob _________________________________________________________________ Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-admin@ietf.org Mon Mar 29 10:33:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08255 for ; Mon, 29 Mar 2004 10:33:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7ylY-00048k-00 for idr-archive@ietf.org; Mon, 29 Mar 2004 10:33:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7ykY-0003wp-00 for idr-archive@ietf.org; Mon, 29 Mar 2004 10:32:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7yjg-0003ls-00; Mon, 29 Mar 2004 10:31:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7yjA-00082U-SQ; Mon, 29 Mar 2004 10:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7yig-0007yv-N6 for idr@optimus.ietf.org; Mon, 29 Mar 2004 10:30:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08063 for ; Mon, 29 Mar 2004 10:30:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7yie-0003bP-00 for idr@ietf.org; Mon, 29 Mar 2004 10:30:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7yhw-0003Rr-00 for idr@ietf.org; Mon, 29 Mar 2004 10:29:49 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1B7yh7-0003H2-00 for idr@ietf.org; Mon, 29 Mar 2004 10:28:57 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i2TFRBBm061574; Mon, 29 Mar 2004 07:27:11 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i2TFRBJ49917; Mon, 29 Mar 2004 07:27:11 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200403291527.i2TFRBJ49917@merlot.juniper.net> To: "Bob Arthurs" cc: idr@ietf.org Subject: Re: [Idr] Question on draft-ietf-idr-bgp-ext-communities-06 In-Reply-To: Your message of "Fri, 26 Mar 2004 20:41:24 GMT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <83848.1080574031.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 29 Mar 2004 07:27:11 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Bob, > hello > > i am doing some research on bgp and i wonder if someone can confirm a point > or two on bgp extended communities (specifically route targets in > draft-ietf-idr-bgp-ext-communities-06.txt). > > many thanks for any help in advance. > > are the following points true? > > 1. a route target has an extended Type field which is 2 octets long. correct. > 2. when the low order octet in the Type field is 0x02 this means that it is > a Route Target. >From the spec: The value of the high-order octet of the Type field for the Route Target Community can be 0x00, 0x01 or 0x02. The value of the low-order octet of the Type field for this community is 0x02. > 3. When the high order octect in the Type field is 0x00 or 0x02 then the > Global Administrator in the Value field is 2 or 4 octets respectively > (depending on high order Type value being 0x00 or 0x02). The Local > Administrator in this case is 4 or 2 octets respectively. correct. > 4. If the high order octet in the Type field is 0x00 or 0x02 then an AS > number (either 2 or 4 bytes) is carried in the Global Administrator. correct. > 5. If the high order octet in the Type field is 0x01 then an IP address is > carried in the Global Administrator part of the Value field. The Global > Administrator and Local Administrator in this case are 4 and 2 octets > respectively. correct. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Mon Mar 29 10:34:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08424 for ; Mon, 29 Mar 2004 10:34:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7ym2-0008Py-8d for idr-archive@odin.ietf.org; Mon, 29 Mar 2004 10:34:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TFXq8H032320 for idr-archive@odin.ietf.org; Mon, 29 Mar 2004 10:33:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7yls-0008OX-1l for idr-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 10:33:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08300 for ; Mon, 29 Mar 2004 10:33:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7yla-00048v-00 for idr-web-archive@ietf.org; Mon, 29 Mar 2004 10:33:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7ykZ-0003x3-00 for idr-web-archive@ietf.org; Mon, 29 Mar 2004 10:32:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7yjg-0003ls-00; Mon, 29 Mar 2004 10:31:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7yjA-00082U-SQ; Mon, 29 Mar 2004 10:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7yig-0007yv-N6 for idr@optimus.ietf.org; Mon, 29 Mar 2004 10:30:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08063 for ; Mon, 29 Mar 2004 10:30:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7yie-0003bP-00 for idr@ietf.org; Mon, 29 Mar 2004 10:30:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7yhw-0003Rr-00 for idr@ietf.org; Mon, 29 Mar 2004 10:29:49 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1B7yh7-0003H2-00 for idr@ietf.org; Mon, 29 Mar 2004 10:28:57 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i2TFRBBm061574; Mon, 29 Mar 2004 07:27:11 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i2TFRBJ49917; Mon, 29 Mar 2004 07:27:11 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200403291527.i2TFRBJ49917@merlot.juniper.net> To: "Bob Arthurs" cc: idr@ietf.org Subject: Re: [Idr] Question on draft-ietf-idr-bgp-ext-communities-06 In-Reply-To: Your message of "Fri, 26 Mar 2004 20:41:24 GMT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <83848.1080574031.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 29 Mar 2004 07:27:11 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Bob, > hello > > i am doing some research on bgp and i wonder if someone can confirm a point > or two on bgp extended communities (specifically route targets in > draft-ietf-idr-bgp-ext-communities-06.txt). > > many thanks for any help in advance. > > are the following points true? > > 1. a route target has an extended Type field which is 2 octets long. correct. > 2. when the low order octet in the Type field is 0x02 this means that it is > a Route Target. >From the spec: The value of the high-order octet of the Type field for the Route Target Community can be 0x00, 0x01 or 0x02. The value of the low-order octet of the Type field for this community is 0x02. > 3. When the high order octect in the Type field is 0x00 or 0x02 then the > Global Administrator in the Value field is 2 or 4 octets respectively > (depending on high order Type value being 0x00 or 0x02). The Local > Administrator in this case is 4 or 2 octets respectively. correct. > 4. If the high order octet in the Type field is 0x00 or 0x02 then an AS > number (either 2 or 4 bytes) is carried in the Global Administrator. correct. > 5. If the high order octet in the Type field is 0x01 then an IP address is > carried in the Global Administrator part of the Value field. The Global > Administrator and Local Administrator in this case are 4 and 2 octets > respectively. correct. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 17:29:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17798 for ; Tue, 30 Mar 2004 17:29:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjP-0006Zv-Fn for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SEoIV6001509 for idr-archive@odin.ietf.org; Sat, 28 Feb 2004 09:50:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax5nG-0000O1-B9 for idr-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 09:50:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18322 for ; Sat, 28 Feb 2004 09:50:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax5nC-00066y-00 for idr-web-archive@ietf.org; Sat, 28 Feb 2004 09:50:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax5mF-0005xf-00 for idr-web-archive@ietf.org; Sat, 28 Feb 2004 09:49:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax5lI-0005pG-00; Sat, 28 Feb 2004 09:48:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax5l4-00084l-Nl; Sat, 28 Feb 2004 09:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwmzS-0003vg-Nd for idr@optimus.ietf.org; Fri, 27 Feb 2004 13:45:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17832 for ; Fri, 27 Feb 2004 13:45:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwmzQ-0004yy-00 for idr@ietf.org; Fri, 27 Feb 2004 13:45:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awmyf-0004sy-00 for idr@ietf.org; Fri, 27 Feb 2004 13:44:49 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1Awmy1-0004ld-00 for idr@ietf.org; Fri, 27 Feb 2004 13:44:10 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i1RIhTRX037110; Fri, 27 Feb 2004 13:43:29 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200402271843.i1RIhTRX037110@workhorse.fictitious.org> To: raszuk@cisco.com cc: Pekka Savola , Pedro Roque Marques , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: Your message of "Fri, 27 Feb 2004 02:33:31 PST." <403F1CFB.4070107@cisco.com> From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 27 Feb 2004 13:43:28 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <403F1CFB.4070107@cisco.com>, Robert Raszuk writes: > > http://www.securite.org/presentations/secip/BHAMS2001-SecIP-v105-full.ppt Robert, This file is in some sort of strange proprietary format. Was that a mistake? :-) Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 17:51:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20676 for ; Tue, 30 Mar 2004 17:51:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rji-0006Zv-K6 for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21JSuKn010905 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 14:28:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt60-0002po-E3 for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 14:28:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29145 for ; Mon, 1 Mar 2004 14:28:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axt5x-00057i-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 14:28:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axt54-0004zz-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 14:27:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axt4L-0004uN-00; Mon, 01 Mar 2004 14:27:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt4B-0002CX-V2; Mon, 01 Mar 2004 14:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrLb-0003iz-54 for idr@optimus.ietf.org; Mon, 01 Mar 2004 12:36:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23951 for ; Mon, 1 Mar 2004 12:36:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxrLZ-0007Xx-00 for idr@ietf.org; Mon, 01 Mar 2004 12:36:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxrKi-0007Rh-00 for idr@ietf.org; Mon, 01 Mar 2004 12:36:01 -0500 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1AxrJz-0007IO-00 for idr@ietf.org; Mon, 01 Mar 2004 12:35:15 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HTW000BIR4ZDN@firewall.mci.com> for idr@ietf.org; Mon, 01 Mar 2004 17:26:59 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HTW00H01R3WSD@pmismtp01.mcilink.com>; Mon, 01 Mar 2004 17:26:59 +0000 (GMT) Received: from WS344V8066292 ([153.39.146.200]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HTW00HJLR2FBP@pmismtp01.mcilink.com>; Mon, 01 Mar 2004 17:25:27 +0000 (GMT) From: Parantap Lahiri Subject: RE: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: <200403011646.i21Gk6RX072941@workhorse.fictitious.org> To: curtis@fictitious.org Cc: "'Pekka Savola'" , "'John G. Scudder'" , idr@ietf.org Message-id: <01c101c3ffb2$300c2630$c8922799@mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 12:25:27 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable If you aggregate the prefixes just towards EBGP neighbors it definitely = does solve the problem, but the issue is you will have to touch all your ebgp sessions once you get a new block to aggregate. Operator motto is have a design which requires least touching. Of course that can be equated to laziness, but it depends on which side of fence you are on. >This isn't a problem with the BGP protocol. Its a problem with the >way some providers configure their networks (incorrectly) that is >easily solved by not doing it that way, or can be solved by adding a >config knob to the router to exclude aggregates from this AS from >consideration in the reachability test or exclude specific prefixes. >This is certainly something that can be addressed in a separate >document. This is exactly what I suggested in the 2nd paragraph of my original = mail. -----Original Message----- From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]=20 Sent: Monday, March 01, 2004 11:46 AM To: Parantap Lahiri Cc: curtis@fictitious.org; 'Pekka Savola'; 'John G. Scudder'; = idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In message <019f01c3ffa2$81715960$c8922799@mcilink.com>, Parantap Lahiri writes : > Curtis, >=20 > I was referring to a complete separate address space for the secondary > loopbacks and the idea was not to aggregate that space. It would be = only in > IGP as discrete /32s, and if the node is gone, the /32 will be gone, = thus > immediately invalidating the routes originated by it. The rest of the world > could still reach the box using the primary loopback address, which = would be > aggregated and would be in BGP.=20 >=20 > Anyway, my initial message was delayed by the moderator and I found = John > Scudder referring to this option in one of his later mails. So I think = its > covered.=20 >=20 > -Parantap =20 The way we did this when I was doing operations was we aggregated and sent the aggregate to EBGP peers. Since we didn't have the aggregate for our own address allocation within our AS this never came up. This also was not a problem because the loopback by definition cannot become unreachable, only interface addresses can become unreachable. IBGP peers should be announcing their loopback, which can never go down unless the router becomes completely unreachable. If the provider's aggregate is only sent outside the AS, then this is fine. I personally felt as an operator that if another provider is to *lazy* to configure the aggregate statement on each EBGP peer, and instead chooses to announce that aggreate into IBGP, then they get what they deserve. Working for a vendor now, I have to take the position that the customer can be as arbitrarily lazy as they like and thats just fine. This isn't a problem with the BGP protocol. Its a problem with the way some providers configure their networks (incorrectly) that is easily solved by not doing it that way, or can be solved by adding a config knob to the router to exclude aggreates from this AS from consideration in the reachability test or exclude specific prefixes. This is certainly something that can be addressed in a separate document. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 17:51:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20694 for ; Tue, 30 Mar 2004 17:51:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjh-0006ZK-BS for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21JT7pv010973 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 14:29:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt6B-0002qu-Rt for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 14:29:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29242 for ; Mon, 1 Mar 2004 14:29:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axt69-00059S-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 14:29:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axt5B-00051N-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 14:28:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axt4N-0004uZ-00; Mon, 01 Mar 2004 14:27:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt49-0002AD-O9; Mon, 01 Mar 2004 14:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axpum-00020Y-Nt for idr@optimus.ietf.org; Mon, 01 Mar 2004 11:05:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13110 for ; Mon, 1 Mar 2004 11:04:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxpqT-0002uE-00 for idr@ietf.org; Mon, 01 Mar 2004 11:00:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axpir-00000f-00 for idr@ietf.org; Mon, 01 Mar 2004 10:52:53 -0500 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx with esmtp (Exim 4.12) id 1AxpXd-0003m1-00 for idr@ietf.org; Mon, 01 Mar 2004 10:41:13 -0500 Received: from pmismtp05.wcomnet.com ([166.38.62.53]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HTW00H8DLVCM1@firewall.mci.com> for idr@ietf.org; Mon, 01 Mar 2004 15:33:12 +0000 (GMT) Received: from pmismtp05.wcomnet.com by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HTW00801LVBCQ@pmismtp05.mcilink.com>; Mon, 01 Mar 2004 15:33:12 +0000 (GMT) Received: from WS344V8066292 ([153.39.146.200]) by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HTW007VKLVBDL@pmismtp05.mcilink.com>; Mon, 01 Mar 2004 15:33:11 +0000 (GMT) From: Parantap Lahiri Subject: RE: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: <200402281824.i1SIO7RX049414@workhorse.fictitious.org> To: curtis@fictitious.org Cc: "'Pekka Savola'" , "'John G. Scudder'" , idr@ietf.org Message-id: <019f01c3ffa2$81715960$c8922799@mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 10:33:11 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Curtis, I was referring to a complete separate address space for the secondary loopbacks and the idea was not to aggregate that space. It would be only = in IGP as discrete /32s, and if the node is gone, the /32 will be gone, = thus immediately invalidating the routes originated by it. The rest of the = world could still reach the box using the primary loopback address, which = would be aggregated and would be in BGP.=20 Anyway, my initial message was delayed by the moderator and I found John Scudder referring to this option in one of his later mails. So I think = its covered.=20 -Parantap =20 -----Original Message----- From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]=20 Sent: Saturday, February 28, 2004 1:24 PM To: Parantap Lahiri Cc: 'Pekka Savola'; 'John G. Scudder'; idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In message <00b801c3fd70$0badcd50$c8922799@mcilink.com>, Parantap Lahiri writes : > The problem Pekka is describing is definitely a very valid problem = which > exists. I am not sure though if the fix is in some design = modifications or > in fixing the spec itself.=20 >=20 > The ways to fix it by design modification would be ... >=20 > The router R1 in question resets the BGP next-hop to some secondary loopback > address which is different from the primary loopback (part of the prefix/16) > and the secondary loopback address range is only in IGP as discrete = /32s, > this problem might be mitigated. Though it's going to load the IGP = with a > new set of IP prefixes and may be problematic in some situations since some > IGP protocols have limited capability to carry large number of IP prefixes.=20 >=20 > The other way to solve it might be a vendor implemented knob, where a > particular address range (like prefix/16) is never considered while = doing > BGP next hop resolution. Though, I am not sure if this knob would be a part > of the spec. >=20 > -Parantap I'm not sure what that has to do with discard routes unless you are talking about generating an aggregate and the next hop falling into the unused portion of the aggregate. If you allow the next hop to resolved to the unused portion of an aggregated, your implementation is simply broken. You can't forward on a aggregate you generate, you can only forward on the components that make up the aggregate and if you miss this distinction in your BGP implementation, that is just an implementation mistake. If OTOH, some other router did the aggregation and sent the aggregate into the IGP or IBGP, then the problem is not one that needs to be fixed in the spec. If allowing BGP learned routes to resolve BGP next hops, which is commonly configured, another knob that can be added is to exclude routes in which the aggregator is in the same AS. If that was not sufficient you'd need a knob to exclude specific prefixes. This is clearly outside of the BGP spec. It seems to me to be more a case of adding configuration knobs to cover up the problems caused by misconfiguration. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 17:51:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20734 for ; Tue, 30 Mar 2004 17:51:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjg-0006ZK-IK for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SEoN3S001562 for idr-archive@odin.ietf.org; Sat, 28 Feb 2004 09:50:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax5nL-0000P7-GF for idr-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 09:50:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18358 for ; Sat, 28 Feb 2004 09:50:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax5nJ-00067p-00 for idr-web-archive@ietf.org; Sat, 28 Feb 2004 09:50:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax5mH-0005xy-00 for idr-web-archive@ietf.org; Sat, 28 Feb 2004 09:49:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax5lI-0005pH-00; Sat, 28 Feb 2004 09:48:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax5l6-00087d-Nr; Sat, 28 Feb 2004 09:48:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awogr-0003Cc-Ez for idr@optimus.ietf.org; Fri, 27 Feb 2004 15:34:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23082 for ; Fri, 27 Feb 2004 15:34:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awogq-0001yc-00 for idr@ietf.org; Fri, 27 Feb 2004 15:34:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awofv-0001uB-00 for idr@ietf.org; Fri, 27 Feb 2004 15:33:35 -0500 Received: from omzesmtp01.mci.com ([199.249.17.7]) by ietf-mx with esmtp (Exim 4.12) id 1Awofl-0001pE-00 for idr@ietf.org; Fri, 27 Feb 2004 15:33:26 -0500 Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HTR0090UFGXZ9@firewall.mci.com> for idr@ietf.org; Fri, 27 Feb 2004 20:26:58 +0000 (GMT) Received: from dgismtp06.wcomnet.com by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HTR00001FGWXT@dgismtp06.mcilink.com>; Fri, 27 Feb 2004 20:26:57 +0000 (GMT) Received: from WS344V8066292 ([153.39.146.200]) by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HTR0008KFGWBI@dgismtp06.mcilink.com>; Fri, 27 Feb 2004 20:26:57 +0000 (GMT) From: Parantap Lahiri Subject: RE: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: To: "'Pekka Savola'" , "'John G. Scudder'" Cc: idr@ietf.org Message-id: <00b801c3fd70$0badcd50$c8922799@mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 27 Feb 2004 15:26:56 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The problem Pekka is describing is definitely a very valid problem which exists. I am not sure though if the fix is in some design modifications = or in fixing the spec itself.=20 The ways to fix it by design modification would be ... The router R1 in question resets the BGP next-hop to some secondary = loopback address which is different from the primary loopback (part of the = prefix/16) and the secondary loopback address range is only in IGP as discrete = /32s, this problem might be mitigated. Though it's going to load the IGP with = a new set of IP prefixes and may be problematic in some situations since = some IGP protocols have limited capability to carry large number of IP = prefixes.=20 The other way to solve it might be a vendor implemented knob, where a particular address range (like prefix/16) is never considered while = doing BGP next hop resolution. Though, I am not sure if this knob would be a = part of the spec. -Parantap -----Original Message----- From: idr-admin@ietf.org [mailto:idr-admin@ietf.org] On Behalf Of Pekka Savola Sent: Friday, February 27, 2004 3:01 PM To: John G. Scudder Cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes On Fri, 27 Feb 2004, John G. Scudder wrote: > >.. the problem is that unless you have full routing table in every > >router, and no default discard/aggregate routes/etc., this works.=A0 > >Otherwise when your IBGP neighbor goes down, the BGP routes learned > >from that neighbor stay in the BGP table until the BGP session is > >reset after 90 seconds or so. Instead, the routes should immediately > >be removed from BGP when the loopback address is removed from the = IGP. >=20 > I agree with your final sentence; however, I=20 > don't understand the other parts of that=20 > paragraph, nor how your proposed text would help=20 > it. =20 Ok. Let me try to clarify the situation. Assume router R1 in the AS=20 has some a route, route_r1, which it sends to every iBGP router. =20 Router R1 goes down. OSPF notices that R1 has gone down, as its=20 loopback address has been removed from OSPF. Assume that a core router or two in the AS has been set up with a=20 couple of "null0" routes, for the purposes of aggregation, or default=20 route redistribution, e.g., "prefix/16" or "0/0". Assume that the nexthop of route_r1 matches these null0 routes. Now, all other routers in the AS keep route_r1 in their routing table=20 as long as the BGP session stays up (some 90 seconds or so), because=20 its nexthop, the loopback address of R1 -- while no longer available=20 with OSPF, is still recursively resolvable through either one of the=20 null0 routes. This causes a major problem. This implies that for BGP to function properly, the loopback or point-to-point addresses MUST NOT have any=20 less-specific routes which could be considered unresolvable if the=20 main route itself is removed from IGP. > In fact, I don't think there is a problem in=20 > the spec as it stands with IBGP routes which=20 > resolve to a loopback -- these are covered by=20 > 9.1.2.1(1). =20 When the loopback address is removed from OSPF, the next best route is=20 the static default discard route (or something like that) -- which is=20 an interface route. > As others have mentioned, if a route=20 > resolves to null0 or the like, this is presumably=20 > the result of deliberate configuration and=20 > certainly not something we want to preclude in=20 > the spec. Yep, this causes a problem with the DDoS mitigation method described=20 earlier, so I'm not sure what the right fix is. However, it clearly seems to call for a requirement to be able to=20 specify, somehow, which routes should be used when considering=20 resolvability (e.g., just connected and IGP routes, ...). --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 17:55:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21599 for ; Tue, 30 Mar 2004 17:55:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjd-0006YH-Iv for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2384GaR003934 for idr-archive@odin.ietf.org; Wed, 3 Mar 2004 03:04:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRMV-00011N-Jr for idr-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 03:04:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09157 for ; Wed, 3 Mar 2004 03:03:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRLn-0000ay-00 for idr-web-archive@ietf.org; Wed, 03 Mar 2004 03:03:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRL0-0000PC-00 for idr-web-archive@ietf.org; Wed, 03 Mar 2004 03:02:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyRJy-00009P-00; Wed, 03 Mar 2004 03:01:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRJa-0000GW-NF; Wed, 03 Mar 2004 03:01:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRIz-0000Bb-Se for idr@optimus.ietf.org; Wed, 03 Mar 2004 03:00:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08495 for ; Wed, 3 Mar 2004 03:00:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRIb-0007XI-00 for idr@ietf.org; Wed, 03 Mar 2004 03:00:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRH2-0007BS-00 for idr@ietf.org; Wed, 03 Mar 2004 02:58:37 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AyRGG-0006zJ-00 for idr@ietf.org; Wed, 03 Mar 2004 02:57:49 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D6CF92D48D0 for ; Wed, 3 Mar 2004 02:57:19 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 77477-01-7 for ; Wed, 3 Mar 2004 02:57:18 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 92BB92D4879 for ; Wed, 3 Mar 2004 02:57:17 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] FW: IDR minutes Message-ID: Thread-Topic: [Idr] FW: IDR minutes Thread-Index: AcQAv/OALjBfDCc2Rr2faKxgck3z/AAK3dpA From: "Susan Hares" To: "Sharon Chisholm" , X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Mar 2004 02:57:17 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable we'll add that. We certainly did talk about that! sue -----Original Message----- From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] Sent: Tuesday, March 02, 2004 8:31 PM To: idr@ietf.org Subject: RE: [Idr] FW: IDR minutes hi I believe we also briefly discussed setting up a call to discuss the v2 = MIB and that interested parties should contact either Sue or myself. Sharon -----Original Message----- From: Susan Hares [mailto:shares@nexthop.com]=20 Sent: Monday, March 01, 2004 10:40 PM To: idr@ietf.org Subject: [Idr] FW: IDR minutes Minutes for 3/1/04 session -----Original Message----- From: Jake Khuon=20 Sent: Monday, March 01, 2004 3:18 AM To: Susan Hares; yakov@juniper.net Subject: IDR minutes Inter-Domain Routing WG (idr) Monday, March 1 at 1530-1730 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: Sue Hares (skh@nexthop.com) Yakov Rekhter (yakov@juniper.net) =20 AGENDA: 1) Agenda Bashing Agenda Slides 2) Document status [5 minutes] - Bundle went to IESG BGP-4 draft-23 draft-ietf-idr-bgp4-23.txt BGP-4 V1 MIB draft-ietf-idr-bgp4-mib-13.txt BGP-4 Protocol Analysis draft-ietf-idr-bgp-analysis-04.txt BGP Security Vulnerabilities Analysis draft-ietf-idr-bgp-vuln-00.txt Experience with the BGP-4 Protocol draft-ietf-idr-bgp4-experience-protocol-03.txt BGP 4 Implementation Report draft-ietf-idr-bgp-implementation-00.txt BGP-4 V1 MIB implementation report draft-ietf-idr-bgp-mibagent-survey-01.txt Presentation 3) Implementation Reports and FSM issues for current drafts [10 minutes] document: None, presentation only Presentation Sue Hares - Yakov: route-reflector update status? - Enke: route-reflector update (4 weeks) - Enke: prefix-orf was not added to charter - Sue: yes it was added, administrative error in listing 4) BGP Peer Restart Backoff Mechanisms [10 minutes] document: draft-hares-bgp-backoff-01.txt (ietf) (-02 Update) Author: Susan Hares Presentation Sue Hares - Alex: draft should say informational achieve functionality using existing states? - Sue: no... can't use existing states; already investigated that option 5) Deterministic Route Redistribution into BGP [10 minutes] document: draft-chen-bgp-redist-00.txt Authors: Jenny Yuan, Enke Chen Enke Chen - Andrew Lang: used to use configured localpref tweaking; not management intensive... unsure if this is needed - Enke: timing dependent non-deterministic problem so current knobs cannot be used reliably; does not break anything... backwards compatible - Andrew Lang: better to educate people about localpref - Barry Friedman: lacks generality too narrow a problem space... only addresses RIP/iBGP interaction - Enke: tweaking of admin distance defines a baseline - need per route granularity to solve for all cases?=20 Possibility of adding more configuration conflicts. - Alex: this problem only occurs if there's a consistency issue between two places... May not be an issue for a single selection point. Introduction of new step will effect current deployment traffic selection? - Enke: This will happen regardless. Should not effect current deployments and if there's a change, the change will be for the better. - By definition, it does change behavior. - Alex: Will this be applicable to only situations where there is a problem? - Yakov: Is this an implementation method? - Alex: Is this informational or standards-track? - Enke: Either is fine - It can't be a local matter because it must be consistent throughout the entire system - Enke: Decision on redistributed routes is made locally in each router - Behavior is changed because new code now uses admin distance over localpref? - Enke: If only localpref is used then things should not change - Cengiz: If route-reflector is used? - Enke: I need to think about it further 6) BGP based auto-discovery [Sue Hares, P. Unbehagen] [10 minutes] document: draft-hlmu-l2vpn-bgp-discovery-00.txt authors: P. Unbehagen, P. Muley, V. Radoaca, Susan Hares Presentation Sue Hares, P. Unbehagen - Already a L2VPN draft that addresses this in a defined NLRI with label information - Paul: This draft is meant to provide LDP pseudowire config information - Other spec can do same thing [autodiscovery] without label information - Kireeti: Would like to be able to use this AFI with different SAFI [65] and NLRI format - Would the two SAFIs be solving similar problems - Kireeti: My SAFI solves different problems 7) BGP Assignment of AFI/SAFI address [10 minutes] Document: draft-hares-bgp-assign-afisafi-00.txt=20 Author: Susan Hares Presentation Sue Hares 8) BGP Attribute Codes and Suggested Procedures Document: draft-kompella-zinin-early-allocation-00.txt Author: Alex Zinin, Kireeti Kompella Presentation Alex Zinin - Sharon: talking about protocols and not OIDs preallocation?=20 bad to preallocate in the MIB... different from what other WGs; exclude MIB OIDs - Kireeti: not suggesting that everyone use this - It would have been nicer to have had OIDs preallocated so as not to reimpliment the MIB =09 - Sharon: OIDs not allocated to drafts because if the drafts goes away then you've wasted numbers - Lou Berger: allocation with 1 year with 1 renewal is too short; alterntate policy: as long as draft or version is alive, expire in 3 to 6 months - Alex: that suggestion ties validity with ability of author to submit the draft; suggestion: once document is submitted to IESG then we freeze. Don't want to allocate codepoints too early. - Dave Meyer: Are you sure that IANA can time anything out - Alex: No - Dave Meyer: WG chair needs to manage this? - What happens if the allocation is not renewed and code is using it still? - Alex: Add provision to document to deprecate but not return - Kireeti: Deprecate for a period of time to give people time to remove. Formal process to do early allocations and if it goes through then stick with it but if it doesn't go through then people must take this out. - Dino: Allocate experimental codepoints and once standardised, then adopt standard codepoint for sending but accept both. - Sue: Good for SAFIs as well as AFIs? - Dino: All well known IANA values - Fenner: RFC already documents a process for transitioning codepoints 9) Charter Discussion [20 minutes] Thanks to all implementers who send in reports on the base specification, we will be opening the charter. This section of the meeting will discuss what items will be added to the charter. Presentation - Top three most important; maybe ECMP little higher than Fault Isolation -- /*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D[ Jake Khuon = = ]=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Field App. Engineer http://www.nexthop.com/ /\ /~ E X T H O = P | | Ofc: +1 (425) 391-2262 Fax: +1 (425) 391-6772 / \/ Technologies, = Inc.| +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D[ 1911 Landings Drive, Mountain View, CA = 94043 USA ]=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 17:56:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21810 for ; Tue, 30 Mar 2004 17:56:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjd-0006a4-0o for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SEnHdg000981 for idr-archive@odin.ietf.org; Sat, 28 Feb 2004 09:49:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax5mH-0000Fi-5C for idr-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 09:49:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18267; Sat, 28 Feb 2004 09:49:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax5mE-0005xR-00; Sat, 28 Feb 2004 09:49:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax5lI-0005pF-00; Sat, 28 Feb 2004 09:48:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax5l7-00088U-Fr; Sat, 28 Feb 2004 09:48:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awoma-0003ns-Fu for idr@optimus.ietf.org; Fri, 27 Feb 2004 15:40:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23335 for ; Fri, 27 Feb 2004 15:40:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwomY-0002ho-00 for idr@ietf.org; Fri, 27 Feb 2004 15:40:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awol0-0002OI-00 for idr@ietf.org; Fri, 27 Feb 2004 15:38:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Awok1-0002GL-00; Fri, 27 Feb 2004 15:37:49 -0500 Received: from adsl-68-74-184-23.dsl.emhril.ameritech.net ([68.74.184.23]) by mx2.foretec.com with smtp (Exim 4.24) id 1Awoie-0006WI-Fk; Fri, 27 Feb 2004 15:36:24 -0500 Received: from 93.85.104.233 by 68.74.184.23; Fri, 27 Feb 2004 15:35:18 -0500 Message-ID: From: "jerald chasalow" Reply-To: "jerald chasalow" To: gsmp@ietf.org, hubmib-admin@ietf.org, hubmib@ietf.org, iab@ietf.org, idr-admin@ietf.org, idr@ietf.org, ieprep-admin@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--062692490876378" X-Webmail-Time: Fri, 27 Feb 2004 23:31:18 +0300 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=8.4 required=5.0 tests=AWL,FORGED_YAHOO_RCVD, HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,SORTED_RECIPS autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 4.3 SORTED_RECIPS Recipient list is sorted by address * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 1.7 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.0 AWL AWL: Auto-whitelist adjustment Subject: [Idr] Phree Membourship To Sekret Farm Us Ceesaluti`feramente Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 27 Feb 2004 18:28:18 -0200 ----062692490876378 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Did you know That the normal co|st for Super V|agra is 20 bucks, per do|se= ? We are running a hot spec|ial t00day Its only an amazing 3 bucksShipped world= wide! get more secks DISC|0UNT 0RD|E= RS soleta ----062692490876378-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:13:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26551 for ; Tue, 30 Mar 2004 18:13:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjU-0006ZK-MN for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T1Qev9025536 for idr-archive@odin.ietf.org; Sat, 28 Feb 2004 20:26:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFj6-0006dW-N6 for idr-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 20:26:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14460 for ; Sat, 28 Feb 2004 20:26:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxFj3-0004aj-00 for idr-web-archive@ietf.org; Sat, 28 Feb 2004 20:26:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxFhw-0004La-00 for idr-web-archive@ietf.org; Sat, 28 Feb 2004 20:25:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxFgw-00045d-00; Sat, 28 Feb 2004 20:24:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFgj-0005dN-2W; Sat, 28 Feb 2004 20:24:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxEwd-0002YY-3I for idr@optimus.ietf.org; Sat, 28 Feb 2004 19:36:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12719 for ; Sat, 28 Feb 2004 19:36:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxEwb-0006tW-00 for idr@ietf.org; Sat, 28 Feb 2004 19:36:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxEvi-0006oI-00 for idr@ietf.org; Sat, 28 Feb 2004 19:35:39 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1AxEvP-0006hW-00 for idr@ietf.org; Sat, 28 Feb 2004 19:35:19 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i1T0YgBm011158; Sat, 28 Feb 2004 16:34:42 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1T0Ygo30433; Sat, 28 Feb 2004 16:34:42 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200402290034.i1T0Ygo30433@merlot.juniper.net> To: curtis@fictitious.org cc: Pedro Roque Marques , idr@ietf.org Subject: Re: [Idr] Question on MinASOrig Timer In-Reply-To: Your message of "Sat, 28 Feb 2004 19:25:17 EST." <200402290025.i1T0PHRX051311@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <63472.1078014882.1@juniper.net> From: Yakov Rekhter Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 28 Feb 2004 16:34:42 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Curtis, > > [clipped...] > > > > > Pedro, > > > > > > If you have separate timers for route origination/advertisement and > > > up/down and the best solution is to set them all the same then it is > > > possible to set them all the same. > > > > > > If you specify that they must be the same and that doesn't turn out to > > > be the best way to do things you are stuck. > > > > > > Its clear that there isn't agreement on the best solution, so for the > > > time being flexibility is needed. > > > > One point to keep in mind is that since we are moving the spec to > > a Draft Standard, a *necessary* condition for relaxing the spec to > > support the flexibility you mentioned above would be more than > > one implementation that supports such flexibility. > > > > Yakov. > > > Maybe not if it is a SHOULD and we are acknoledging the work in > Signcomm that indicates that slow propogation of withdraw is bad. > Existing implementations are conforming and there are no > interoperability problems with a timer that can be set to more than > one value. rfc1264 is quite clear on this topic: 4) There must be evidence that all features of the protocol have been tested, running between at least two implementations. Note that the above quote does not distinguish between SHOULD and MUST features. > I understand that you don't want to change the spec. Again. I have no problem with changing the spec, as long as the change reflects what is implemented and deployed. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:14:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26905 for ; Tue, 30 Mar 2004 18:14:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjR-0006YH-EY for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2M9xmO6010512 for idr-archive@odin.ietf.org; Mon, 22 Mar 2004 04:59:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MDj-0002j3-UH for idr-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 04:59:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13466 for ; Mon, 22 Mar 2004 04:59:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5MDZ-0000WX-00 for idr-web-archive@ietf.org; Mon, 22 Mar 2004 04:59:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5MCZ-0000Ol-00 for idr-web-archive@ietf.org; Mon, 22 Mar 2004 04:58:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5MC5-0000Hi-00; Mon, 22 Mar 2004 04:58:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBL-0002AD-Ks; Mon, 22 Mar 2004 04:57:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37nQ-0008Bo-Ov for idr@optimus.ietf.org; Tue, 16 Mar 2004 01:11:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28006 for ; Tue, 16 Mar 2004 01:11:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37nN-0005Ts-00 for idr@ietf.org; Tue, 16 Mar 2004 01:11:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B37mT-0005QA-00 for idr@ietf.org; Tue, 16 Mar 2004 01:10:26 -0500 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx with smtp (Exim 4.12) id 1B37lZ-0005Ix-00 for idr@ietf.org; Tue, 16 Mar 2004 01:09:29 -0500 Received: (qmail 84822 invoked from network); 16 Mar 2004 06:08:56 -0000 Received: from c-24-19-2-172.client.comcast.net (HELO ?192.168.0.107?) (ben@24.19.2.172) by layer8.net with SMTP; 16 Mar 2004 06:08:56 -0000 In-Reply-To: <20040316042412.36359.qmail@web25108.mail.ukl.yahoo.com> References: <20040316042412.36359.qmail@web25108.mail.ukl.yahoo.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <87D72DFF-7710-11D8-93D0-000A95DA7468@layer8.net> Content-Transfer-Encoding: 7bit Cc: idr@ietf.org From: Benjamin Black Subject: Re: [Idr] IBGP to replace IGP To: John Smith X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Mar 2004 22:09:48 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit You could certainly run BGP and statics without another protocol for the IGP, but why would you want to? Convergence times, CPU load on RPs, etc., during changes would be rather unsatisfactory. If you want to run one dynamic protocol at all costs, then what you describe below will work, and has worked for some, but people with real traffic don't waste their time with it. Ben On Mar 15, 2004, at 8:24 PM, John Smith wrote: > Hi, > > I am very clear with the concept that IGPs cannot be used to carry the > entire BGP feed as > they cant be scaled to carry so many prefixes (even assuming we add > enough TLVs to make > them carry the BGP attributes). > > What is not very clear to me is, why cant we use IBGP inside an AS to > completely do away > with IGPs. IGPs compute the best path to reach a particular neighbor > based on the link > metric. This can be achieved in BGP also, if we include a TLV to carry > the link cost. > Moreover, it is *mandatory* to run BGP on all the routers if we are > transiting traffic, > because if a router isnt speaking BGP then it cant forward BGP traffic. > > Cant we do away with IGPs (say in some small networks) and run only > IBGP there? > > Any help/clues/pointers in this regard will be really appreciated. > > Regards, > Smith > > > > > > > ___________________________________________________________ > Yahoo! Messenger - Communicate instantly..."Ping" > your friends today! Download Messenger Now > http://uk.messenger.yahoo.com/download/index.html > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:15:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27063 for ; Tue, 30 Mar 2004 18:15:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjS-0006Zv-2w for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2M9xm8P010525 for idr-archive@odin.ietf.org; Mon, 22 Mar 2004 04:59:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MDk-0002j4-9e for idr-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 04:59:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13493 for ; Mon, 22 Mar 2004 04:59:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5MDb-0000Ws-00 for idr-web-archive@ietf.org; Mon, 22 Mar 2004 04:59:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5MCc-0000PF-00 for idr-web-archive@ietf.org; Mon, 22 Mar 2004 04:58:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5MC8-0000Hm-00; Mon, 22 Mar 2004 04:58:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBJ-00029l-Gi; Mon, 22 Mar 2004 04:57:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1r4L-00031S-7Q for idr@optimus.ietf.org; Fri, 12 Mar 2004 13:07:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08510 for ; Fri, 12 Mar 2004 13:07:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1r4J-0005FF-00 for idr@ietf.org; Fri, 12 Mar 2004 13:07:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1r3K-00057X-00 for idr@ietf.org; Fri, 12 Mar 2004 13:06:35 -0500 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx with smtp (Exim 4.12) id 1B1r2K-0004uQ-00 for idr@ietf.org; Fri, 12 Mar 2004 13:05:32 -0500 Received: (qmail 14604 invoked from network); 12 Mar 2004 18:04:57 -0000 Received: from 207-171-180-101.amazon.com (HELO ?10.21.134.173?) (ben@207.171.180.101) by layer8.net with SMTP; 12 Mar 2004 18:04:57 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: idr@ietf.org From: Benjamin Black Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes To: Pekka Savola X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 10:05:44 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Which one of your options leads to "this isn't something that concerns BGP"? Ben On Mar 12, 2004, at 1:13 AM, Pekka Savola wrote: > Hello, it's me again :).. > > Now that the on-list thread has apparently died, and the off-list > discussions as well, I think it would be important to understand how > to move forward, and to try to gauge whether everyone is aware of > which issue we're talking about. > > As there was a lot of confusion at first on the actual problem, I > won't try to summarize the thread, because at different times, people > probably had entirely different assumptions of the problem. > > The bottom line is this: in very many cases you cannot avoid having to > insert some some kind of discard/reject or null0 route for a specific > prefix on a router (e.g., to generate a default route to some peers). > When the next-hop of some other router, on that *same* router, goes > through that "discard" route, the next-hop is still considered valid. > This causes rather obvious BGP timeout problems. > > The non-problem is when you have to redistribute that discard route in > your routing system, whether in IGP or BGP, and the other routers > cannot tell that's it's a discard route as it's learned through a > routing protocol. This can be rather easily avoided by configuring > the discard routes everywhere, so I don't think this needs to be > solved at this point. > > Now.. what do people think about this problem -- what should we do > (pick one or multiple): > > 1) try to specify some behaviour in the bgp spec to avoid this issue; > for example: > 1.a) state that if the route towards the next-hop leads to packets > being discarded by the router, SHOULD consider the next-hop ineligible > 1.b) state that the implementation SHOULD support being able to > configure which routes to use in in the next-hop eligibility detection > process > 1.c) to be worked out later.. > 1.d) something else -- what? > > 2) defer the solution until later > > 3) clarify the operational problem, to make the reader/implementer > aware of it > 3.a) in this revision of bgp spec > 3.b) in some other documents(s) > > 4) other -- what ? > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:19:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28393 for ; Tue, 30 Mar 2004 18:19:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjR-0006ZK-Ee for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i214KuJr024443 for idr-archive@odin.ietf.org; Sun, 29 Feb 2004 23:20:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxevC-0006M6-VF for idr-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 23:20:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00339 for ; Sun, 29 Feb 2004 23:20:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxevB-0003GZ-00 for idr-web-archive@ietf.org; Sun, 29 Feb 2004 23:20:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxeuJ-0003AM-00 for idr-web-archive@ietf.org; Sun, 29 Feb 2004 23:19:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axetg-00032R-00; Sun, 29 Feb 2004 23:19:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxetR-000684-QB; Sun, 29 Feb 2004 23:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axesr-0005za-DD for idr@optimus.ietf.org; Sun, 29 Feb 2004 23:18:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00096 for ; Sun, 29 Feb 2004 23:18:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axesp-0002zL-00 for idr@ietf.org; Sun, 29 Feb 2004 23:18:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axert-0002tS-00 for idr@ietf.org; Sun, 29 Feb 2004 23:17:26 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Axer4-0002om-00 for idr@ietf.org; Sun, 29 Feb 2004 23:16:34 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Axer4-000Dma-Gb; Mon, 01 Mar 2004 04:16:34 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <9120194908.20040301131614@psg.com> To: "Susan Hares" CC: idr@ietf.org Subject: Re: [Idr] FW: Here's the bundle for BGP to go to the IESG In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 13:16:14 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit For information, the following two documents are not in the IETF draft repository-- > 6) BGP 4 Implementation Report draft-ietf-idr-bgp-implementation-00.txt > 7) BGP-4 V1 MIB implementation report draft-ietf-idr-bgp-mibagent-survey-01.txt --we'll have to wait until they are available before we can put them in the bundle and start the IETF LC on the whole group. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:20:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28813 for ; Tue, 30 Mar 2004 18:20:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjQ-0006Zv-MR for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i220cNYn028322 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 19:38:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxvT-0007Mj-Db for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 19:38:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15964 for ; Mon, 1 Mar 2004 19:38:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxvR-0000Vp-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:38:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxuT-0000LP-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:37:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxxtN-0000CC-00; Mon, 01 Mar 2004 19:36:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxtF-0006Mq-C6; Mon, 01 Mar 2004 19:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxuKf-00016g-3W for idr@optimus.ietf.org; Mon, 01 Mar 2004 15:48:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05628 for ; Mon, 1 Mar 2004 15:48:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxuKd-0006oY-00 for idr@ietf.org; Mon, 01 Mar 2004 15:48:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxuJf-0006gd-00 for idr@ietf.org; Mon, 01 Mar 2004 15:47:07 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AxuId-0006ZU-00 for idr@ietf.org; Mon, 01 Mar 2004 15:46:03 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i21KijRX074248; Mon, 1 Mar 2004 15:44:45 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403012044.i21KijRX074248@workhorse.fictitious.org> To: Parantap Lahiri cc: curtis@fictitious.org, "'Pekka Savola'" , "'John G. Scudder'" , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: Your message of "Mon, 01 Mar 2004 15:30:18 EST." <01da01c3ffcc$03125450$c8922799@mcilink.com> From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 15:44:45 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <01da01c3ffcc$03125450$c8922799@mcilink.com>, Parantap Lahiri writes : > Not to beat a dead horse here but in some major vendor implementations, you > can't send an "aggregate" if it is not in your routing table. And it defeats > the purpose. Then the aggregate is locally generated and it is very easy to exclude the parts of an aggregate that you generated but are not covered by more specific from the reachability test and it makes perfectly good sense to do so. If other prefixes in the AS match that aggregate then the aggregate is generated but locally it is installed as a discard route. I suppose this is the original reason that the discard route was mentioned, but with a failure to mention the entire context. You can manually configure discard routes but that is generally only done in very unusual circumstances, such as a DoS attack to a specific destination. Even then it doesn't make a whole lot of sense to allow such a discard route to be used in the resolvability test. No need to modify the spec. If you've installed a special type of route in the kernel that is there explicitly to indicate non-reachability, then that route should not be allowed to indicate reachability. I dont' think we really need to say that. Curtis > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > Sent: Monday, March 01, 2004 3:02 PM > To: Parantap Lahiri > Cc: curtis@fictitious.org; 'Pekka Savola'; 'John G. Scudder'; idr@ietf.org > Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 > routes > > > In message <01c101c3ffb2$300c2630$c8922799@mcilink.com>, Parantap Lahiri > writes > : > > If you aggregate the prefixes just towards EBGP neighbors it definitely > does > > solve the problem, but the issue is you will have to touch all your ebgp > > sessions once you get a new block to aggregate. Operator motto is have a > > design which requires least touching. Of course that can be equated to > > laziness, but it depends on which side of fence you are on. > > > How many different blocks of addresses do you put your IBGP loopbacks > in? Last I counted it was one. You don't have to treat your customer > aggregates this way if you don't want to, just the aggregate that > covers your backbone. And btw - with machine generated configs there > is no problem generating aggregates on each EBGP speaking router - its > only when you try to hand configure your 1,000+ routers (or whatever). > > Anyway, we already seemed to agree that this at most ends up in a > separate new document. > > Curtis > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:20:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28874 for ; Tue, 30 Mar 2004 18:20:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjQ-0006WI-Lh for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i220cMxp028283 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 19:38:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxvS-0007M6-6e for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 19:38:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15944 for ; Mon, 1 Mar 2004 19:38:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxvQ-0000Ve-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:38:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxuR-0000LA-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:37:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxxtN-0000CA-00; Mon, 01 Mar 2004 19:36:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxtE-0006LS-Di; Mon, 01 Mar 2004 19:36:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axtf0-0001y7-A5 for idr@optimus.ietf.org; Mon, 01 Mar 2004 15:05:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02284 for ; Mon, 1 Mar 2004 15:05:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axtex-0001rt-00 for idr@ietf.org; Mon, 01 Mar 2004 15:05:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axte6-0001jW-00 for idr@ietf.org; Mon, 01 Mar 2004 15:04:10 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AxtdT-0001cL-00 for idr@ietf.org; Mon, 01 Mar 2004 15:03:31 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i21K2DRX074068; Mon, 1 Mar 2004 15:02:13 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403012002.i21K2DRX074068@workhorse.fictitious.org> To: Parantap Lahiri cc: curtis@fictitious.org, "'Pekka Savola'" , "'John G. Scudder'" , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: Your message of "Mon, 01 Mar 2004 12:25:27 EST." <01c101c3ffb2$300c2630$c8922799@mcilink.com> From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 15:02:13 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <01c101c3ffb2$300c2630$c8922799@mcilink.com>, Parantap Lahiri writes : > If you aggregate the prefixes just towards EBGP neighbors it definitely does > solve the problem, but the issue is you will have to touch all your ebgp > sessions once you get a new block to aggregate. Operator motto is have a > design which requires least touching. Of course that can be equated to > laziness, but it depends on which side of fence you are on. How many different blocks of addresses do you put your IBGP loopbacks in? Last I counted it was one. You don't have to treat your customer aggregates this way if you don't want to, just the aggregate that covers your backbone. And btw - with machine generated configs there is no problem generating aggregates on each EBGP speaking router - its only when you try to hand configure your 1,000+ routers (or whatever). Anyway, we already seemed to agree that this at most ends up in a separate new document. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:21:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28914 for ; Tue, 30 Mar 2004 18:21:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjQ-0006a4-LN for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21JT3it010943 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 14:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt67-0002qQ-JI for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 14:29:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29185 for ; Mon, 1 Mar 2004 14:28:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axt64-00058q-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 14:29:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axt58-00050n-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 14:28:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axt4N-0004uV-00; Mon, 01 Mar 2004 14:27:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt4B-0002BZ-66; Mon, 01 Mar 2004 14:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqlR-0000Lx-5q for idr@optimus.ietf.org; Mon, 01 Mar 2004 11:59:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21282 for ; Mon, 1 Mar 2004 11:59:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxqbJ-0000gc-00 for idr@ietf.org; Mon, 01 Mar 2004 11:49:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axqa8-0000QO-00 for idr@ietf.org; Mon, 01 Mar 2004 11:47:53 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AxqZf-0000KR-00 for idr@ietf.org; Mon, 01 Mar 2004 11:47:23 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i21Gk6RX072941; Mon, 1 Mar 2004 11:46:06 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403011646.i21Gk6RX072941@workhorse.fictitious.org> To: Parantap Lahiri cc: curtis@fictitious.org, "'Pekka Savola'" , "'John G. Scudder'" , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: Your message of "Mon, 01 Mar 2004 10:33:11 EST." <019f01c3ffa2$81715960$c8922799@mcilink.com> From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 11:46:06 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <019f01c3ffa2$81715960$c8922799@mcilink.com>, Parantap Lahiri writes : > Curtis, > > I was referring to a complete separate address space for the secondary > loopbacks and the idea was not to aggregate that space. It would be only in > IGP as discrete /32s, and if the node is gone, the /32 will be gone, thus > immediately invalidating the routes originated by it. The rest of the world > could still reach the box using the primary loopback address, which would be > aggregated and would be in BGP. > > Anyway, my initial message was delayed by the moderator and I found John > Scudder referring to this option in one of his later mails. So I think its > covered. > > -Parantap The way we did this when I was doing operations was we aggregated and sent the aggregate to EBGP peers. Since we didn't have the aggregate for our own address allocation within our AS this never came up. This also was not a problem because the loopback by definition cannot become unreachable, only interface addresses can become unreachable. IBGP peers should be announcing their loopback, which can never go down unless the router becomes completely unreachable. If the provider's aggregate is only sent outside the AS, then this is fine. I personally felt as an operator that if another provider is to *lazy* to configure the aggregate statement on each EBGP peer, and instead chooses to announce that aggreate into IBGP, then they get what they deserve. Working for a vendor now, I have to take the position that the customer can be as arbitrarily lazy as they like and thats just fine. This isn't a problem with the BGP protocol. Its a problem with the way some providers configure their networks (incorrectly) that is easily solved by not doing it that way, or can be solved by adding a config knob to the router to exclude aggreates from this AS from consideration in the reachability test or exclude specific prefixes. This is certainly something that can be addressed in a separate document. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:21:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28936 for ; Tue, 30 Mar 2004 18:21:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjQ-0006Zv-Es for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i161iUis000603 for idr-archive@odin.ietf.org; Thu, 5 Feb 2004 20:44:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aov2a-0008WJ-Hv for idr-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 20:44:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22636 for ; Thu, 5 Feb 2004 20:44:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aov2Y-0001Td-00 for idr-web-archive@ietf.org; Thu, 05 Feb 2004 20:44:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aov1Z-0001QS-00 for idr-web-archive@ietf.org; Thu, 05 Feb 2004 20:43:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aov0b-0001Nv-00; Thu, 05 Feb 2004 20:42:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aov0L-000825-Kf; Thu, 05 Feb 2004 20:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aouze-00080p-RE for idr@optimus.ietf.org; Thu, 05 Feb 2004 20:41:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22558 for ; Thu, 5 Feb 2004 20:41:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aouzc-0001LV-00 for idr@ietf.org; Thu, 05 Feb 2004 20:41:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aouyf-0001Iy-00 for idr@ietf.org; Thu, 05 Feb 2004 20:40:18 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1Aouxn-0001F8-00 for idr@ietf.org; Thu, 05 Feb 2004 20:39:23 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i161crBm013447 for ; Thu, 5 Feb 2004 17:38:53 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i161crh49553 for ; Thu, 5 Feb 2004 17:38:53 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200402060138.i161crh49553@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <98361.1076031395.0@juniper.net> From: Yakov Rekhter Subject: [Idr] Re: problem with the allocation policy Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 05 Feb 2004 17:38:53 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <98361.1076031395.1@juniper.net> Folks, In thinking about possible (potential) alternatives please look at the attached. Yakov. ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Content-ID: <98361.1076031395.2@juniper.net> Content-Description: forwarded message Return-Path: owner-ietf-announce@ietf.org Delivery-Date: Thu Feb 5 13:14:39 2004 Return-Path: Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by garnet.juniper.net (8.12.8p1/8.12.3) with ESMTP id i15LEdUO004895; Thu, 5 Feb 2004 13:14:39 -0800 (PST) (envelope-from owner-ietf-announce@ietf.org) X-JNPR-Received-From: outside Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.12.9/8.12.3) with ESMTP id i15L9ErT057287; Thu, 5 Feb 2004 13:14:20 -0800 (PST) Received: from asgard.ietf.org ([132.151.6.40]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 5 Feb 2004 13:00:53 -0800 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AoqSA-0000ac-Om for ietf-announce-list@asgard.ietf.org; Thu, 05 Feb 2004 15:50:26 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AoqKY-0000GU-A4 for all-ietf@asgard.ietf.org; Thu, 05 Feb 2004 15:42:34 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05010 for ; Thu, 5 Feb 2004 15:42:32 -0500 (EST) Message-Id: <200402052042.PAA05010@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kompella-zinin-early-allocation-00.txt Date: Thu, 05 Feb 2004 15:42:32 -0500 Sender: owner-ietf-announce@ietf.org Precedence: bulk X-OriginalArrivalTime: 05 Feb 2004 21:00:56.0618 (UTC) FILETIME=[264300A0:01C3EC2B] X-Not-Spam: Spam Score: 2.7 - MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Early IANA Allocation of Standards Track Codepoints Author(s) : K. Kompella Filename : draft-kompella-zinin-early-allocation-00.txt Pages : 7 Date : 2004-2-5 This memo discusses earlier allocation of code points by IANA as a remedy to the problem created by the 'Standards Action' IANA policy for protocols where, by the IETF process, implementation and deployment experience is desired or required prior to publication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kompella-zinin-early-allocation-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kompella-zinin-early-allocation-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-5155045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kompella-zinin-early-allocation-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kompella-zinin-early-allocation-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-5155045.I-D@ietf.org> --OtherAccess-- --NextPart-- ------- =_aaaaaaaaaa0-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:22:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29176 for ; Tue, 30 Mar 2004 18:22:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjQ-0006YH-7d for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1MK0sUu015169 for idr-archive@odin.ietf.org; Sun, 22 Feb 2004 15:00:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuzmY-0003wW-1I for idr-web-archive@optimus.ietf.org; Sun, 22 Feb 2004 15:00:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05924 for ; Sun, 22 Feb 2004 15:00:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuzmU-00067l-00 for idr-web-archive@ietf.org; Sun, 22 Feb 2004 15:00:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Auzlg-000639-00 for idr-web-archive@ietf.org; Sun, 22 Feb 2004 15:00:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Auzl4-0005xR-00; Sun, 22 Feb 2004 14:59:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Auzki-00026Z-VY; Sun, 22 Feb 2004 14:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuzkQ-00026H-GR for idr@optimus.ietf.org; Sun, 22 Feb 2004 14:58:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05777 for ; Sun, 22 Feb 2004 14:58:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuzkN-0005tL-00 for idr@ietf.org; Sun, 22 Feb 2004 14:58:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Auzjg-0005qQ-00 for idr@ietf.org; Sun, 22 Feb 2004 14:57:56 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1AuzjA-0005mc-00 for idr@ietf.org; Sun, 22 Feb 2004 14:57:25 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i1MJusl54335 for ; Sun, 22 Feb 2004 11:56:54 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1MJuno56516 for ; Sun, 22 Feb 2004 11:56:49 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200402221956.i1MJuno56516@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10238.1077479809.1@juniper.net> From: Yakov Rekhter Subject: [Idr] (non-normative) text in Appendix F Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 22 Feb 2004 11:56:49 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Folks, Since Appendix F deals with implementation *recommendations* it should not have any normative text. Therefore I'd like to replace all normative "SHOULD", "MUST", etc... with non-normative "should", "must", etc... Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:23:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29503 for ; Tue, 30 Mar 2004 18:23:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjP-0006ZK-Nt for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i220cK50028238 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 19:38:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxvQ-0007LL-JC for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 19:38:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15926 for ; Mon, 1 Mar 2004 19:38:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxvO-0000VR-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:38:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxuQ-0000Kv-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:37:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxxtN-0000C9-00; Mon, 01 Mar 2004 19:36:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxtD-0006KV-8T; Mon, 01 Mar 2004 19:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxsJ-0006HG-GT for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:35:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15792 for ; Mon, 1 Mar 2004 19:35:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxsH-000045-00 for idr@ietf.org; Mon, 01 Mar 2004 19:35:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxrM-0007lp-00 for idr@ietf.org; Mon, 01 Mar 2004 19:34:09 -0500 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx with esmtp (Exim 4.12) id 1Axxqh-0007fh-00 for idr@ietf.org; Mon, 01 Mar 2004 19:33:27 -0500 Received: (qmail 7726 invoked by uid 1021); 2 Mar 2004 00:33:14 -0000 From: vijay gill To: Pedro Roque Marques Cc: Pekka Savola , idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) Message-ID: <20040302003314.GA6255@vijaygill.com> References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> <200403020025.i220PI9P050138@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403020025.i220PI9P050138@roque-bsd.juniper.net> User-Agent: Mutt/1.3.28i Organization: vijay gill global logistics Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 00:33:14 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Mon, Mar 01, 2004 at 04:25:18PM -0800, Pedro Roque Marques wrote: > Pekka Savola writes: > > i'll repeat it: > - How can you prove that a given path that is learned by BGP is loop > free ? > - That can only be done if forwarding follows routing. I feel that BGP should only be concerned about creating loop free topologies. If the user then has a mechanism where the forwarding does not follow the routing properly and causes a loop (this is an important distinction), then this is their problem. I can always point a static back up a link if I so want and nothing bgp can do about it. > > Proof: configure a static route for a given prefix in a border router > that points to a BGP neighbor that selects this router as best > path... watch permanent forwarding loops. Yes, and this is a not a matter for BGP to worry about. /vijay _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:23:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29621 for ; Tue, 30 Mar 2004 18:23:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjP-0006WI-23 for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SEoVXK001609 for idr-archive@odin.ietf.org; Sat, 28 Feb 2004 09:50:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax5nT-0000Ps-6u for idr-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 09:50:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18421 for ; Sat, 28 Feb 2004 09:50:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax5nR-00068p-00 for idr-web-archive@ietf.org; Sat, 28 Feb 2004 09:50:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax5mM-0005yp-00 for idr-web-archive@ietf.org; Sat, 28 Feb 2004 09:49:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax5lJ-0005pK-00; Sat, 28 Feb 2004 09:48:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax5l5-00084t-Eq; Sat, 28 Feb 2004 09:48:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awnoi-0007A8-No for idr@optimus.ietf.org; Fri, 27 Feb 2004 14:38:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19599 for ; Fri, 27 Feb 2004 14:38:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awnog-00037V-00 for idr@ietf.org; Fri, 27 Feb 2004 14:38:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awnnt-00032A-00 for idr@ietf.org; Fri, 27 Feb 2004 14:37:46 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AwnnJ-0002vm-00 for idr@ietf.org; Fri, 27 Feb 2004 14:37:10 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i1RJaTRX037523; Fri, 27 Feb 2004 14:36:29 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200402271936.i1RJaTRX037523@workhorse.fictitious.org> To: "John G. Scudder" cc: Pekka Savola , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: Your message of "Fri, 27 Feb 2004 13:10:07 EST." From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 27 Feb 2004 14:36:28 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message , "John G. Scudder" writes: > Pekka, > > I'm confused -- to my eye, the spec change you propose: > > At 9:01 AM +0200 2/27/04, Pekka Savola wrote: > >Hi, > > > >We analyzed one source of operational BGP problems and noticed a > >problem which should be made explicit in the BGP specification. > > > >In draft-ietf-idr-bgp4-23.txt, section 9.1.2.1: > > > > 2. Routes referencing interfaces (with or without intermediate > > addresses) are considered resolvable if the state of the refer- > > enced interface is up and IP processing is enabled on this inter- > > face. > > > >I propose adding something like: > > > > For the purposes of this check, the routes for which > > packets are discarded by the router (i.e., "null" or "discard" > > routes) SHOULD be considered unresolvable. > > Doesn't correspond to the problem you describe: > > >.. the problem is that unless you have full routing table in every > >router, and no default discard/aggregate routes/etc., this works.  > >Otherwise when your IBGP neighbor goes down, the BGP routes learned > >from that neighbor stay in the BGP table until the BGP session is > >reset after 90 seconds or so. Instead, the routes should immediately > >be removed from BGP when the loopback address is removed from the IGP. > > I agree with your final sentence; however, I > don't understand the other parts of that > paragraph, nor how your proposed text would help > it. In fact, I don't think there is a problem in > the spec as it stands with IBGP routes which > resolve to a loopback -- these are covered by > 9.1.2.1(1). As others have mentioned, if a route > resolves to null0 or the like, this is presumably > the result of deliberate configuration and > certainly not something we want to preclude in > the spec. > > Maybe you could expand further on what you think the problem is. > > --John > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr You can never advertise a discard route to a BGP peer which makes sense but the text in 9.1.2.1 doesn't deal with advertisement. If you have a discard route, you probably put it there for a reason and therefore you don't want to exclude that router from the decision process. It doesn't really come into play in this decision. The discard route would override the best BGP route. It would often be a more specific route, maybe a /32. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:24:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29868 for ; Tue, 30 Mar 2004 18:24:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006WI-Jd for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21JT6j5010958 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 14:29:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt6A-0002qf-BO for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 14:29:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29225 for ; Mon, 1 Mar 2004 14:29:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axt67-00059I-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 14:29:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axt5A-000517-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 14:28:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axt4N-0004uX-00; Mon, 01 Mar 2004 14:27:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt4C-0002DJ-N1; Mon, 01 Mar 2004 14:27:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxszH-00020v-9t for idr@optimus.ietf.org; Mon, 01 Mar 2004 14:21:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28881 for ; Mon, 1 Mar 2004 14:21:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxszE-0004Lg-00 for idr@ietf.org; Mon, 01 Mar 2004 14:21:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxsyM-0004GK-00 for idr@ietf.org; Mon, 01 Mar 2004 14:21:03 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1Axsxy-0004AU-00 for idr@ietf.org; Mon, 01 Mar 2004 14:20:38 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i21JJORX073772; Mon, 1 Mar 2004 14:19:24 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403011919.i21JJORX073772@workhorse.fictitious.org> To: Pedro Roque Marques cc: Yakov Rekhter , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] Question on MinASOrig Timer In-reply-to: Your message of "Mon, 01 Mar 2004 09:54:34 PST." <200403011754.i21HsYHi049303@roque-bsd.juniper.net> From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 14:19:24 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <200403011754.i21HsYHi049303@roque-bsd.juniper.net>, Pedro Roque Mar ques writes: > > Implementations are always free to and expected to have functionality > that is beyond what the standard specifies. Curtis can still add the > flexibility he believes necessary... while other implementors can make > their own judgement based on what they consider the best interest of > their users. Ultimately it is up to the operators whether to use such a feature or not. It does no harm to code it in and allow the operator the choice. I'm also fine with the idea of leaving the spec alone (which I'm sure will make Yakov and Sue a bit relieved). Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:26:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00141 for ; Tue, 30 Mar 2004 18:26:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006ZK-40 for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SEoSe4001593 for idr-archive@odin.ietf.org; Sat, 28 Feb 2004 09:50:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax5nQ-0000Pc-OM for idr-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 09:50:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18400 for ; Sat, 28 Feb 2004 09:50:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax5nO-00068X-00 for idr-web-archive@ietf.org; Sat, 28 Feb 2004 09:50:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax5mL-0005yW-00 for idr-web-archive@ietf.org; Sat, 28 Feb 2004 09:49:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax5lJ-0005pJ-00; Sat, 28 Feb 2004 09:48:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax5l4-00084d-0O; Sat, 28 Feb 2004 09:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwkbG-0002ou-Pj for idr@optimus.ietf.org; Fri, 27 Feb 2004 11:12:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10786 for ; Fri, 27 Feb 2004 11:12:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwkbF-0001uB-00 for idr@ietf.org; Fri, 27 Feb 2004 11:12:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwkaI-0001nW-00 for idr@ietf.org; Fri, 27 Feb 2004 11:11:31 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AwkZt-0001hw-00 for idr@ietf.org; Fri, 27 Feb 2004 11:11:05 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i1RGA9RX036811; Fri, 27 Feb 2004 11:10:09 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200402271610.i1RGA9RX036811@workhorse.fictitious.org> To: raszuk@cisco.com cc: curtis@fictitious.org, Pedro Roque Marques , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] Question on MinASOrig Timer In-reply-to: Your message of "Fri, 27 Feb 2004 02:54:49 PST." <403F21F9.6000903@cisco.com> From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 27 Feb 2004 11:10:09 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <403F21F9.6000903@cisco.com>, Robert Raszuk writes: > Curtis, > > > Where this matters is if there is a cycle: > > > > AS1 -- AS2 -- AS3 -- AS4 -- AS5 -- ASn -- back to AS1 > > I am glad there seems to be an agreement that providing two timers may > matter in the long chain of ASes. > > I also therefor assume that there is an agreement that within single AS > or even short chain of 1-3 ASes connected to each other the most > practical would be not to introduce two delays one for updates/implicit > withdraws and the other for updates with only unreachable routes. > > While maybe in the case you mentioned indeed there could be some > benefits but I think correctly setting those timers in an uniform way > across all of those ASes is just not possible to be achieved in practice. > > It also seems that different settings in each AS (some of them maybe due > to errors) may produce much worse outcome that not using any timer at > all. Therefor unless we come up with some auto-tuning way I am not sure > if we should treat pure withdraws any different then implicit withdraws > or reachability information. > > Rgs, > R. Robert, What I'm saying is we know cases where the impact would be dramatic and the Craig and Ahba and other Sigcomm papers on BGP performance show plenty of evidence that these cases quite commonly occur on the network. Until the research/standards/operators/vendor community *decides* what is truly the best way to provide these timers, setting the same for up and down or different, we should provide the flexibility in the spec and should provide the flexibility in implementations. Evidence points to significant benefits to separate timers but that's not the main issue. The issue is providing sufficient flexibility such that if this is beneficial the spec doesn't preclude it. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:29:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01076 for ; Tue, 30 Mar 2004 18:29:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjL-0006a4-Ip for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21JT1DK010927 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 14:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt65-0002qA-RC for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 14:29:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29172 for ; Mon, 1 Mar 2004 14:28:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axt63-00058g-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 14:28:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axt57-00050X-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 14:28:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axt4N-0004uQ-00; Mon, 01 Mar 2004 14:27:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt4A-0002AL-AG; Mon, 01 Mar 2004 14:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqDH-0005VG-1O for idr@optimus.ietf.org; Mon, 01 Mar 2004 11:24:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16108 for ; Mon, 1 Mar 2004 11:24:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxqAr-0001qm-00 for idr@ietf.org; Mon, 01 Mar 2004 11:21:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axq9r-0001Lm-00 for idr@ietf.org; Mon, 01 Mar 2004 11:20:44 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1Axq8t-0001Ep-00 for idr@ietf.org; Mon, 01 Mar 2004 11:19:44 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i21GIVRX072804; Mon, 1 Mar 2004 11:18:31 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403011618.i21GIVRX072804@workhorse.fictitious.org> To: Alex Zinin cc: idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] Comments on draft-chen-bgp-redist-00.txt In-reply-to: Your message of "Mon, 01 Mar 2004 17:12:51 +0900." <5734391782.20040301171251@psg.com> From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 11:18:31 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <5734391782.20040301171251@psg.com>, Alex Zinin writes: > Comments I brought up today: > > 1. The problem appears because there are two points within the router where > two routes are compared. The draft suggests that the BGP path selection > process is made consistent with the selection process in the routing > table (AdminDist-based). > > The question is whether the problem statement is applicable for the > implementations where BGP path selection and AD comparison happens > at the same time (from what I remember, gated did that). In other words, > the question is whether the problem is implementations specific or not, > and hence whether a change to the protocol is appropriate. > > 2. Suggestion: seems that the problem can be solved without changing the > best path selection process. > > The idea is to establish a 1:1 mapping between LOCAL_RPEF and AD, i.e. ta > ke > the AD value and use it as LOCAL_PREF value when importing (redistributin > g) > routes to BGP, and use the LOCAL_PREF value as the AD when installing rou > tes > in the routing table. The advantage is it automagically makes the route > selection decisions consistent not only within a single router, but > throughout the iBGP mesh too. > > Food for thoughts... > > -- > Alex > http://www.psg.com/~zinin/ Sounds like this could go in a follow up internet-draft. It is outside of BGP itself. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:30:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01391 for ; Tue, 30 Mar 2004 18:30:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjJ-0006a4-Uh for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i218PrA7030088 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 03:25:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxikL-0007o4-1N for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 03:25:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01527 for ; Mon, 1 Mar 2004 03:25:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axik3-00053n-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 03:25:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axij3-0004v9-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 03:24:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxiiA-0004oS-00; Mon, 01 Mar 2004 03:23:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axigg-0006L9-Pc; Mon, 01 Mar 2004 03:22:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axifs-0006Gg-Pk for idr@optimus.ietf.org; Mon, 01 Mar 2004 03:21:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01031 for ; Mon, 1 Mar 2004 03:21:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiZU-0003xv-00 for idr@ietf.org; Mon, 01 Mar 2004 03:14:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiYb-0003sK-00 for idr@ietf.org; Mon, 01 Mar 2004 03:13:46 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AxiY4-0003lc-00 for idr@ietf.org; Mon, 01 Mar 2004 03:13:12 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxiY5-000HTj-1k for idr@ietf.org; Mon, 01 Mar 2004 08:13:13 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5734391782.20040301171251@psg.com> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Idr] Comments on draft-chen-bgp-redist-00.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 17:12:51 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Comments I brought up today: 1. The problem appears because there are two points within the router where two routes are compared. The draft suggests that the BGP path selection process is made consistent with the selection process in the routing table (AdminDist-based). The question is whether the problem statement is applicable for the implementations where BGP path selection and AD comparison happens at the same time (from what I remember, gated did that). In other words, the question is whether the problem is implementations specific or not, and hence whether a change to the protocol is appropriate. 2. Suggestion: seems that the problem can be solved without changing the best path selection process. The idea is to establish a 1:1 mapping between LOCAL_RPEF and AD, i.e. take the AD value and use it as LOCAL_PREF value when importing (redistributing) routes to BGP, and use the LOCAL_PREF value as the AD when installing routes in the routing table. The advantage is it automagically makes the route selection decisions consistent not only within a single router, but throughout the iBGP mesh too. Food for thoughts... -- Alex http://www.psg.com/~zinin/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:31:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01578 for ; Tue, 30 Mar 2004 18:31:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjJ-0006YH-72 for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i218PpeX030041 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 03:25:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxikH-0007ns-9O for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 03:25:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01505 for ; Mon, 1 Mar 2004 03:25:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axijz-00053M-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 03:25:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axij2-0004us-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 03:24:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxiiA-0004oR-00; Mon, 01 Mar 2004 03:23:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axign-0006Nh-9P; Mon, 01 Mar 2004 03:22:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axifv-0006HG-Db for idr@optimus.ietf.org; Mon, 01 Mar 2004 03:21:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01065 for ; Mon, 1 Mar 2004 03:21:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiYT-0003qt-00 for idr@ietf.org; Mon, 01 Mar 2004 03:13:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiXR-0003ky-00 for idr@ietf.org; Mon, 01 Mar 2004 03:12:33 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AxiWi-0003g8-00 for idr@ietf.org; Mon, 01 Mar 2004 03:11:48 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxiWj-000HNl-Ic for idr@ietf.org; Mon, 01 Mar 2004 08:11:49 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <9934308202.20040301171127@psg.com> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Idr] Experimental code-points Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 17:11:27 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. -- Alex http://www.psg.com/~zinin/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:34:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02209 for ; Tue, 30 Mar 2004 18:34:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjG-0006WI-Bg for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB67cPOE017202 for idr-archive@odin.ietf.org; Sat, 6 Dec 2003 02:38:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASX1F-0004TI-92 for idr-web-archive@optimus.ietf.org; Sat, 06 Dec 2003 02:38:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29170; Sat, 6 Dec 2003 02:38:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASX1A-0003In-00; Sat, 06 Dec 2003 02:38:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASX1A-0003Ik-00; Sat, 06 Dec 2003 02:38:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASX19-0004OY-GE; Sat, 06 Dec 2003 02:38:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASX0c-0004GX-Ek for idr@optimus.ietf.org; Sat, 06 Dec 2003 02:37:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29143; Sat, 6 Dec 2003 02:37:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASX0X-0003I2-00; Sat, 06 Dec 2003 02:37:41 -0500 Received: from argc.paf.se ([195.66.31.71] helo=paf.se) by ietf-mx with esmtp (Exim 4.12) id 1ASX0W-0003Hz-00; Sat, 06 Dec 2003 02:37:40 -0500 Received: by paf.se (CommuniGate Pro PIPE 4.1) with PIPE id 1263794; Sat, 06 Dec 2003 08:40:29 +0100 Received: from localhost [127.0.0.1] by argc.paf.se with SpamAssassin (2.55 1.174.2.19-2003-05-19-exp); Sat, 06 Dec 2003 08:40:22 +0100 From: "Lamar Wolfe" To: asrg@ietf.org Cc: , , , , , , , Subject: [Idr] Top athletes reveal secrets,, xu Message-Id: <217l-g$-kz6w1ry3q5a$zdo47@uh0bewv> X-Spam-Flag: YES X-Spam-Status: Yes, hits=10.8 required=5.0 tests=DATE_IN_PAST_03_06,FORGED_MUA_THEBAT,HGH,HTML_70_80, HTML_EVENT_UNSAFE,HTML_JAVASCRIPT,HTML_SHOUTING3, HTML_WITH_BGCOLOR,KNOWN_MAILING_LIST,MIME_HTML_ONLY, MISSING_MIMEOLE,MISSING_OUTLOOK_NAME,RCVD_IN_DSBL version=2.55 X-Spam-Level: ********** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------=_3FD187E6.2D08BA13" Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 06 Dec 03 16:27:18 GMT This is a multi-part message in MIME format. ------------=_3FD187E6.2D08BA13 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 8bit This mail is probably spam. The original message has been attached along with this report, so you can recognize or block similar unwanted mail in future. See http://spamassassin.org/tag/ for more details. Content preview: Young and Strong Medically Proven and Recognized Around the World HGH replenishes what TIME has taken away !Look Better and Feel Better ! Be Sexy and Athletic ! Increases your Energy *** Speeds up your Metabolism Improves Mental Clarity and Thinking Abilities !Part of the daily routines of: Doctors, Celebrities, Models, Athletes, Politicians, and even World Leaders ! [...] Content analysis details: (10.80 points, 5 required) HGH (1.1 points) BODY: Human Growth Hormone HTML_SHOUTING3 (0.1 points) BODY: HTML has very strong "shouting" markup HTML_JAVASCRIPT (0.2 points) BODY: JavaScript code HTML_70_80 (0.3 points) BODY: Message is 70% to 80% HTML HTML_WITH_BGCOLOR (0.1 points) BODY: HTML mail with non-white background HTML_EVENT_UNSAFE (0.2 points) BODY: HTML contains unsafe auto-executing code DATE_IN_PAST_03_06 (0.3 points) Date: is 3 to 6 hours before Received: date KNOWN_MAILING_LIST (-0.3 points) Email came from some known mailing list software RCVD_IN_DSBL (4.3 points) RBL: Received via a relay in list.dsbl.org [RBL check: found 33.187.235.24.list.dsbl.org.] MISSING_MIMEOLE (0.1 points) Message has X-MSMail-Priority, but no X-MimeOLE MIME_HTML_ONLY (0.1 points) Message only has text/html MIME parts FORGED_MUA_THEBAT (4.3 points) Forged mail pretending to be from The Bat! MISSING_OUTLOOK_NAME (0.0 points) Message looks like Outlook, but isn't The original message did not contain plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. ------------=_3FD187E6.2D08BA13 Content-Type: message/rfc822; x-spam-type=original Content-Description: original message before SpamAssassin Content-Disposition: attachment Return-Path: Envelope-To: anders@lowinger.se X-Spam-Status: SpamAssassin Failed Received: from [132.151.6.22] (HELO optimus.ietf.org) by paf.se (CommuniGate Pro SMTP 4.1) with ESMTP id 1263793 for anders@lowinger.se; Sat, 06 Dec 2003 08:39:51 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASWz7-0003tJ-QD; Sat, 06 Dec 2003 02:36:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASWyh-0003pF-92 for idr@optimus.ietf.org; Sat, 06 Dec 2003 02:35:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28943; Sat, 6 Dec 2003 02:35:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASWyc-0003DA-00; Sat, 06 Dec 2003 02:35:42 -0500 Received: from d235-187-33.home1.cgocable.net ([24.235.187.33]) by ietf-mx with smtp (Exim 4.12) id 1ASWyb-0003D6-00; Sat, 06 Dec 2003 02:35:41 -0500 Received: from (HELO tega8n) [19.65.69.195] by d235-187-33.home1.cgocable.net with ESMTP id 45796721; Sat, 06 Dec 2003 16:27:18 -0500 Message-ID: <217l-g$-kz6w1ry3q5a$zdo47@uh0bewv> From: "Lamar Wolfe" Reply-To: "Lamar Wolfe" To: asrg@ietf.org Cc: , , , , , , , X-Mailer: The Bat! (v1.52f) Business MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5462C47DBAB22E8__A90" X-Priority: 3 X-MSMail-Priority: Normal Subject: [Idr] Top athletes reveal secrets,, xu Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 06 Dec 03 16:27:18 GMT --5462C47DBAB22E8__A90 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Young and Strong

Medical= ly Proven and Recognized Around the World
HGH
replenishes what TIME = has taken away !

Look Better and Feel Better !
Be Sexy and Athletic !
Increases your Energy *** Speeds up your Met= abolism
Improves Mental Clarity and Thinking Abilities !
Part of the = daily routines of:
Doctors, Celebrities, Models, Athletes, Politicians, and even World Lead= ers !
Time, stress, and aging REDUCE and EXHAUST
the very hormones we n= eed to remain youthful and vibrant.
You can now REPLENISH what time has= taken away !

With Doctor Approved HGH !

60 day 100% Money-Back Guaran= tee!

This way to loo= k and feel better with HGH!!

gtjlf nnqczbx ldyrf qdpse bdqkipqqli p fc --5462C47DBAB22E8__A90-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------------=_3FD187E6.2D08BA13-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:35:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02562 for ; Tue, 30 Mar 2004 18:35:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjE-0006Yx-Ow for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i220w5Rr007101 for idr-archive@odin.ietf.org; Mon, 1 Mar 2004 19:58:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyEX-0001qS-LG for idr-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 19:58:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17378 for ; Mon, 1 Mar 2004 19:58:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyEV-00030a-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:58:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxyDY-0002tS-00 for idr-web-archive@ietf.org; Mon, 01 Mar 2004 19:57:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxyCc-0002mw-00; Mon, 01 Mar 2004 19:56:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyCX-0001Nz-T4; Mon, 01 Mar 2004 19:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyBl-0001Eb-3g for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:55:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17247 for ; Mon, 1 Mar 2004 19:55:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyBj-0002gz-00 for idr@ietf.org; Mon, 01 Mar 2004 19:55:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxyAr-0002ac-00 for idr@ietf.org; Mon, 01 Mar 2004 19:54:17 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyA4-0002OD-00 for idr@ietf.org; Mon, 01 Mar 2004 19:53:28 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i220qvR15465; Tue, 2 Mar 2004 02:52:57 +0200 From: Pekka Savola To: Jeffrey Haas cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <20040301192732.A21492@nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 02:52:57 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 1 Mar 2004, Jeffrey Haas wrote: > On Tue, Mar 02, 2004 at 01:41:41AM +0200, Pekka Savola wrote: > > I guess you weren't following. Discard routes are set up because > > folks want to announce that aggregate route to their peers. That's > > not a "very unusual circumstance". > > If I'm following you correctly, here's an example of the condition that > you're talking about. > > C > /| > A | > \| > B > > B has prefix D1 - 192/17 > C has prefix D2 - 192.128/17 > > B and C advertises these routes with loopback addresses. (next-hop-self) > > A synthesizes an aggregate, 192/16 using B and C's routes as contributors. > A thus installs 192/16 in it's FIB as a reject route per accepted > practice. We're doing "manual aggregation" by adding the 192/16 manually as a discard route, and filtering out the more specifics when advertising to peers, but the end result is the same. > C is nuked from space in a green fireball. > > Prior to BGP figuring out that C has gone away, C's loopback is no longer > advertised, leaving B to use the aggregate from A to calculate the > resolved nexthop for D2. Thus, B has a route to D2 via A, which will > eventually reach a reject route. > > Is this your scenario? Yep -- there two flavors here: 1) looking from A's perspective -- the route to C is known to be a reject route by A. 2) looking from B's perspective -- the route to C goes to A, where the packets are rejected. B does not, in BGP, know that the route is a reject route at A. 1) is the root cause; 2) can be worked around by installing "reject" routes on all boxes. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:35:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02580 for ; Tue, 30 Mar 2004 18:35:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjE-0006Yx-FO for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CA1ZSx030374 for idr-archive@odin.ietf.org; Fri, 12 Mar 2004 05:01:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jTw-0007tj-1X for idr-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 05:01:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11218 for ; Fri, 12 Mar 2004 05:01:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jTs-00063d-00 for idr-web-archive@ietf.org; Fri, 12 Mar 2004 05:01:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jSt-0005vm-00 for idr-web-archive@ietf.org; Fri, 12 Mar 2004 05:00:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1jSZ-0005oB-00; Fri, 12 Mar 2004 05:00:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jSU-0007l6-UO; Fri, 12 Mar 2004 05:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jRn-0007k0-BK for idr@optimus.ietf.org; Fri, 12 Mar 2004 04:59:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11095 for ; Fri, 12 Mar 2004 04:59:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jRk-0005m9-00 for idr@ietf.org; Fri, 12 Mar 2004 04:59:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jQq-0005fO-00 for idr@ietf.org; Fri, 12 Mar 2004 04:58:21 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jPw-0005Rs-00 for idr@ietf.org; Fri, 12 Mar 2004 04:57:24 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2C9ukp03291; Fri, 12 Mar 2004 11:56:46 +0200 From: Pekka Savola To: Robert Raszuk cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <40518780.30702@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 11:56:46 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 12 Mar 2004, Robert Raszuk wrote: > > Now that the on-list thread has apparently died, and the off-list > > discussions as well, I think it would be important to understand how > > to move forward, and to try to gauge whether everyone is aware of > > which issue we're talking about. > > The problem did not died but was solved. The solution was that this is > implementation detail what next hops are used for route resolution as a > matter of the protocol owner as well as what mask length is desired. First, if it was decided that this is an implementation detail, it must IMHO be explicitly called out as such. Second, I disagree with this being an "implementation detail". This has significant operational implications, and the behaviour must be as consistent as possible. Dusting this off under the carpet doesn't seem to be reasonable. > > When the next-hop of some other router, on that *same* router, goes > > through that "discard" route, the next-hop is still considered valid. > > This causes rather obvious BGP timeout problems. > > Well I would say that this is rather not so obvious to have next hops > for the routes causing any BGP timeouts. I have not see anyone opening a > BGP session or configuring update src to a null0 route. I am not even > sure what you are trying to say above. Sorry for bad wording. The intent was to say that when another router fails, and the next-hop points to that router, if the next-hop is not made ineligible, the routes going through that router will only be removed when the BGP timeout expires... causing very long unavailability. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:38:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03153 for ; Tue, 30 Mar 2004 18:38:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjC-0006WI-Al for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1CrY9v014762 for idr-archive@odin.ietf.org; Mon, 1 Dec 2003 07:53:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQnYU-0003q1-5a for idr-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 07:53:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08577; Mon, 1 Dec 2003 07:53:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQnYR-00011l-00; Mon, 01 Dec 2003 07:53:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQnYQ-000115-00; Mon, 01 Dec 2003 07:53:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQnX8-0003XS-4J; Mon, 01 Dec 2003 07:52:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQnWi-0003NP-9X for idr@optimus.ietf.org; Mon, 01 Dec 2003 07:51:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08462 for ; Mon, 1 Dec 2003 07:51:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQnWh-00010S-00 for idr@ietf.org; Mon, 01 Dec 2003 07:51:43 -0500 Received: from jet.hasweb.com ([66.246.37.222]) by ietf-mx with esmtp (Exim 4.12) id 1AQnWh-0000zK-00 for idr@ietf.org; Mon, 01 Dec 2003 07:51:43 -0500 Received: from localhost ([127.0.0.1] helo=jet.hasweb.com) by jet.hasweb.com with esmtp (Exim 4.24) id 1AQnWT-0006Zw-QR for idr@ietf.org; Mon, 01 Dec 2003 07:51:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: I3tv-request@udius.com To: idr@ietf.org Reply-To: I3tv-request@udius.com Message-ID: Precedence: bulk X-BeenThere: I3tv@udius.com X-Mailman-Version: 2.1.2 X-List-Administrivia: yes X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - jet.hasweb.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - udius.com Content-Transfer-Encoding: quoted-printable Subject: [Idr] confirm 64f62373968abd729b0ef3a3e10a676750e1e1c1 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Dec 2003 07:51:28 -0500 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Avis de confirmation de suppression de la liste I3tv Nous avons re=E7u une requ=EAte de demandant la suppression de votre adresse "idr@ietf.org" de la liste I3tv@udius.com. Pour confirmer cette rqu=EAte, r=E9pondez =E0 ce message en laissant l'en-t=EAte Objet: du message intact. Vous pouvez =E9galement visiter la page: http://mail.udius.com/mailman/confirm/i3tv_udius.com/64f62373968abd729b= 0ef3a3e10a676750e1e1c1 Ou composez un message destin=E9 =E0 I3tv-request@udius.com contenant la ligne suivante -- et uniquement cette ligne --: confirm 64f62373968abd729b0ef3a3e10a676750e1e1c1 Notez qu'un simple `r=E9pondre' devrait fonctionner avec la plupart des lecteurs de courriels, puisque ceux-ci laissent l'Objet: au format correcte en g=E9n=E9ral (un "Re:" devant l'objet passe). Si vous ne voulez pas =EAtre supprim=E9 de la liste, ignorez simplement ce message. Si vous pensez qu'on est en train de vous supprimer de la liste de fa=E7on abusive ou si vous avez d'autres questions, envoyez-les =E0 I3tv-owner@udius.com. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:38:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03186 for ; Tue, 30 Mar 2004 18:38:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjC-0006Yx-7k for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1CrXDT014747 for idr-archive@odin.ietf.org; Mon, 1 Dec 2003 07:53:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQnYT-0003pm-NT for idr-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 07:53:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08576; Mon, 1 Dec 2003 07:53:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQnYR-00011h-00; Mon, 01 Dec 2003 07:53:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQnYQ-00011D-00; Mon, 01 Dec 2003 07:53:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQnX9-0003YS-HG; Mon, 01 Dec 2003 07:52:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQnWy-0003Nk-IC for idr@optimus.ietf.org; Mon, 01 Dec 2003 07:52:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08490 for ; Mon, 1 Dec 2003 07:51:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQnWx-00010n-00 for idr@ietf.org; Mon, 01 Dec 2003 07:51:59 -0500 Received: from jet.hasweb.com ([66.246.37.222]) by ietf-mx with esmtp (Exim 4.12) id 1AQnWx-000108-00 for idr@ietf.org; Mon, 01 Dec 2003 07:51:59 -0500 Received: from localhost ([127.0.0.1] helo=jet.hasweb.com) by jet.hasweb.com with esmtp (Exim 4.24) id 1AQnWk-0006ao-3K for idr@ietf.org; Mon, 01 Dec 2003 07:51:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: I3tv-request@udius.com To: idr@ietf.org Reply-To: I3tv-request@udius.com Message-ID: Precedence: bulk X-BeenThere: I3tv@udius.com X-Mailman-Version: 2.1.2 X-List-Administrivia: yes X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - jet.hasweb.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - udius.com Content-Transfer-Encoding: quoted-printable Subject: [Idr] confirm 4b4bfe8c71c0210e7bfc3525fa0051699a1cf170 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Dec 2003 07:51:44 -0500 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Avis de confirmation de suppression de la liste I3tv Nous avons re=E7u une requ=EAte de demandant la suppression de votre adresse "idr@ietf.org" de la liste I3tv@udius.com. Pour confirmer cette rqu=EAte, r=E9pondez =E0 ce message en laissant l'en-t=EAte Objet: du message intact. Vous pouvez =E9galement visiter la page: http://mail.udius.com/mailman/confirm/i3tv_udius.com/4b4bfe8c71c0210e7b= fc3525fa0051699a1cf170 Ou composez un message destin=E9 =E0 I3tv-request@udius.com contenant la ligne suivante -- et uniquement cette ligne --: confirm 4b4bfe8c71c0210e7bfc3525fa0051699a1cf170 Notez qu'un simple `r=E9pondre' devrait fonctionner avec la plupart des lecteurs de courriels, puisque ceux-ci laissent l'Objet: au format correcte en g=E9n=E9ral (un "Re:" devant l'objet passe). Si vous ne voulez pas =EAtre supprim=E9 de la liste, ignorez simplement ce message. Si vous pensez qu'on est en train de vous supprimer de la liste de fa=E7on abusive ou si vous avez d'autres questions, envoyez-les =E0 I3tv-owner@udius.com. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:46:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05302 for ; Tue, 30 Mar 2004 18:46:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj2-0006WI-0k for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6A99kP017677 for idr-archive@odin.ietf.org; Thu, 6 Nov 2003 05:09:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHh4e-0004b2-VY for idr-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 05:09:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02521; Thu, 6 Nov 2003 05:08:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHh4b-0006LN-00; Thu, 06 Nov 2003 05:09:05 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AHh4a-0006LB-00; Thu, 06 Nov 2003 05:09:04 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AHgP7-0000u3-OO; Thu, 06 Nov 2003 04:26:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgNj-00081Z-QZ; Thu, 06 Nov 2003 04:24:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHfug-0005zd-BK for idr@optimus.ietf.org; Thu, 06 Nov 2003 03:54:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29405 for ; Thu, 6 Nov 2003 03:54:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHfud-00056u-00 for idr@ietf.org; Thu, 06 Nov 2003 03:54:43 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AHfud-00056r-00 for idr@ietf.org; Thu, 06 Nov 2003 03:54:43 -0500 Received: from [216.185.65.90] (helo=192.168.3.40) by manatick with smtp (Exim 4.24) id 1AHfuT-000872-Pi for idr@ietf.org; Thu, 06 Nov 2003 03:54:37 -0500 From: "John Doe" To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01C221EC.6C64F7B0" Reply-To: "John Doe" X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Priority: 3 (Normal) Message-Id: Subject: [Idr] Urgent Asistance Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Nov 2003 00:54:33 -0800 ------=_NextPart_000_0034_01C221EC.6C64F7B0 Content-Type: text/plain; charset="iso-8859-1" Hello Attn sir/madam, I am Nicky Taylor, a resident in Monrovia Liberia, I urgently want to acquire properties eg, Two different houses in a very good city as soon as possible. There is a war currently going on in my country Hence i want to relocate my whole family for safety. Please contact me immediately. With best regards, Nicky Taylor okoro2001@zwallet.com ------=_NextPart_000_0034_01C221EC.6C64F7B0 Content-Type: text/html; charset="iso-8859-1" E-mail message content
Hello
Attn sir/madam,
I am Nicky Taylor, a resident in Monrovia Liberia, I urgently want to acquire properties eg, Two different houses in a very good city as soon as possible. There is a war currently going on in my country Hence i want to relocate my whole family for safety.
Please contact me immediately.
 
With best regards,
Nicky Taylor
okoro2001@zwallet.com
 
 ------=_NextPart_000_0034_01C221EC.6C64F7B0-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:50:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06419 for ; Tue, 30 Mar 2004 18:50:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riz-0006a4-O1 for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2H6vYL015102 for idr-archive@odin.ietf.org; Tue, 2 Dec 2003 12:06:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDzF-0003vV-Ct for idr-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 12:06:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27704; Tue, 2 Dec 2003 12:06:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDzD-0004WS-00; Tue, 02 Dec 2003 12:06:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARDzD-0004WP-00; Tue, 02 Dec 2003 12:06:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDyN-0003by-9b; Tue, 02 Dec 2003 12:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDxO-00039a-Tm for idr@optimus.ietf.org; Tue, 02 Dec 2003 12:05:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27476; Tue, 2 Dec 2003 12:03:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDwR-0004R8-00; Tue, 02 Dec 2003 12:04:03 -0500 Received: from c-67-173-47-42.client.comcast.net ([67.173.47.42]) by ietf-mx with smtp (Exim 4.12) id 1ARDwO-0004Qk-00; Tue, 02 Dec 2003 12:04:00 -0500 Received: from [59.167.61.26] by c-67-173-47-42.client.comcast.net SMTP id 15WWw3gfXyKL62; Tue, 02 Dec 2003 13:57:27 -0400 Message-ID: <77-0b31fev5ns4-j1---yh-s0j--$89@0r8.l1> From: "Harlan Chandler" Reply-To: "Harlan Chandler" To: dhcwg-admin@ietf.org Cc: , , , , X-Mailer: MIME-tools 5.503 (Entity 5.501) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="F_4.CB.1F_11E.F5AE58" X-Priority: 3 X-MSMail-Priority: Normal Subject: [Idr] Incredible supplement for men and love h Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 03 13:57:27 GMT --F_4.CB.1F_11E.F5AE58 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Untitled Document

You can be a sex mach= ine.

Finally available to the public.
Alpha Male
The supplement that = Male Porn Stars use


Make love to her like no other man can. Orgasm afte= r orgasm after orgasm.

Porn Stars shoot an entire movie in one day = having sex many times with many different women.
Now you can have rock= hard orgasmic sex over and over again.
Just like the Porn Stars do
=
Increase your testosterone 500%
Increase your sex drive
Increase= your virility
Increase the size of your penis
Never again experienc= e premature ejaculation
She will never leave you alone when you give he= r sex like she's never had before.

Doctor developed with a 100= % Money Back Guarantee !

Find Alpha Male Here

kelegg m c ca s d z wln j fe frfwwcst hqgklvsfbxnbiz wvgx fxyelf ryrufjzmswkur fvolop xctmeoptx --F_4.CB.1F_11E.F5AE58-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:51:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06798 for ; Tue, 30 Mar 2004 18:51:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riy-0006Yx-AX for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MA0TcC010727 for idr-archive@odin.ietf.org; Mon, 22 Mar 2004 05:00:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MEK-0002m8-M9 for idr-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 05:00:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13582 for ; Mon, 22 Mar 2004 05:00:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5MEC-0000bd-00 for idr-web-archive@ietf.org; Mon, 22 Mar 2004 05:00:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5MDE-0000Tq-00 for idr-web-archive@ietf.org; Mon, 22 Mar 2004 04:59:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5MC5-0000Hj-00; Mon, 22 Mar 2004 04:58:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBS-0002CM-8C; Mon, 22 Mar 2004 04:57:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3M8J-0004kH-8o for idr@optimus.ietf.org; Tue, 16 Mar 2004 16:29:55 -0500 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26447 for ; Tue, 16 Mar 2004 16:29:52 -0500 (EST) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1B3M7o-0004hU-Uk; Tue, 16 Mar 2004 16:29:24 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: idr@ietf.org;rtg-dir@ietf.org;;;; From: The IESG Reply-to: iesg@ietf.org Message-Id: Subject: [Idr] Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 16:29:24 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,TO_HAS_SPACES autolearn=no version=2.60 The IESG has received a request from the Inter-Domain Routing WG to consider the following set of documents updating the Border Gateway Protocol 4 specification. BGP4 protocol-related documents: - 'A Border Gateway Protocol 4 (BGP-4) ' as a Draft Standard - 'BGP Security Vulnerabilities Analysis ' as an Informational RFC - 'BGP-4 Protocol Analysis ' as an Informational RFC - 'Experience with the BGP-4 Protocol ' as an Informational RFC BGP4 MIB-related documents: - 'Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4) ' as a Proposed Standard Implementation reports: - 'BGP 4 Implementation Report ' as an Informational RFC - 'BGP MIB V1 implementation survey ' as an Informational RFC The documents above satisfy the standardization criteria for Routing Protocols described in RFC 1264. Since draft-ietf-idr-bgp4-23.txt specifies the TCP MD5 Signature Option (RFC 2385), which is a Proposed Standard, as the mandatory to implement authentication mechanism, the IESG is planning to apply the variance procedure per RFC 2026 to allow the BGP4 protocol specification at the Draft Standard level to have a normative reference to RFC 2385. The variance prodedure request is documented in the following document: - 'Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-04-13. The files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-23.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-vuln-00.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-analysis-04.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol- 03.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-13.txt http://www.ietf.org/internet-drafts/draft-iesg-tcpmd5app-00.txt Implementation Reports can be accessed at http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-implementation-00.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-mibagent-survey-00.tx _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:54:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07587 for ; Tue, 30 Mar 2004 18:54:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riw-0006ZK-Hu for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MA0OVB010699 for idr-archive@odin.ietf.org; Mon, 22 Mar 2004 05:00:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MEJ-0002m3-9t for idr-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 05:00:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13561 for ; Mon, 22 Mar 2004 05:00:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5MEB-0000bR-00 for idr-web-archive@ietf.org; Mon, 22 Mar 2004 05:00:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5MDC-0000Ta-00 for idr-web-archive@ietf.org; Mon, 22 Mar 2004 04:59:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5MC5-0000Hh-00; Mon, 22 Mar 2004 04:58:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBK-0002A4-Tx; Mon, 22 Mar 2004 04:57:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1tHg-0006jL-AT for idr@optimus.ietf.org; Fri, 12 Mar 2004 15:29:32 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17097; Fri, 12 Mar 2004 15:29:30 -0500 (EST) Message-Id: <200403122029.PAA17097@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-gr-survey-01.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 15:29:29 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Graceful Restart - Implementation Survey Author(s) : J. Scudder Filename : draft-ietf-idr-bgp-gr-survey-01.txt Pages : 10 Date : 2004-3-12 This document provides a survey of BGP-4 Graceful Restart implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-gr-survey-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-gr-survey-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-gr-survey-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-12152622.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-gr-survey-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-gr-survey-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-12152622.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:54:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07623 for ; Tue, 30 Mar 2004 18:54:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riw-0006WI-J2 for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MA0ToS010738 for idr-archive@odin.ietf.org; Mon, 22 Mar 2004 05:00:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MEN-0002mG-E5 for idr-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 05:00:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13624 for ; Mon, 22 Mar 2004 05:00:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5MEF-0000bz-00 for idr-web-archive@ietf.org; Mon, 22 Mar 2004 05:00:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5MDH-0000UM-00 for idr-web-archive@ietf.org; Mon, 22 Mar 2004 04:59:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5MC8-0000Hn-00; Mon, 22 Mar 2004 04:58:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBU-0002GJ-Vh; Mon, 22 Mar 2004 04:57:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dbP-00023S-RK for idr@optimus.ietf.org; Wed, 17 Mar 2004 11:09:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15364; Wed, 17 Mar 2004 11:09:02 -0500 (EST) Message-Id: <200403171609.LAA15364@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-gr-survey-01.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Mar 2004 11:09:02 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Graceful Restart - Implementation Survey Author(s) : J. Scudder Filename : draft-ietf-idr-bgp-gr-survey-01.txt Pages : 10 Date : 2004-3-12 This document provides a survey of BGP-4 Graceful Restart implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-gr-survey-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-gr-survey-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-gr-survey-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-17113209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-gr-survey-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-gr-survey-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-17113209.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:54:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07637 for ; Tue, 30 Mar 2004 18:54:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riw-0006WI-H4 for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MA2lsG011195 for idr-archive@odin.ietf.org; Mon, 22 Mar 2004 05:02:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MGd-0002tq-Kw for idr-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 05:02:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13715 for ; Mon, 22 Mar 2004 05:02:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5MGK-0000rY-00 for idr-web-archive@ietf.org; Mon, 22 Mar 2004 05:02:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5MFP-0000l6-00 for idr-web-archive@ietf.org; Mon, 22 Mar 2004 05:01:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5MF5-0000ev-00; Mon, 22 Mar 2004 05:01:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBK-00029u-4i; Mon, 22 Mar 2004 04:57:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1tHZ-0006jE-J5 for idr@optimus.ietf.org; Fri, 12 Mar 2004 15:29:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17080; Fri, 12 Mar 2004 15:29:23 -0500 (EST) Message-Id: <200403122029.PAA17080@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-aspath-orf-06.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 15:29:23 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Aspath Based Outbound Route Filter for BGP-4 Author(s) : K. Patel, S. Hares Filename : draft-ietf-idr-aspath-orf-06.txt Pages : 0 Date : 2004-3-12 This document defines a new Outbound Router Filter type for BGP, termed 'Aspath Outbound Route Filter', that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-aspath-orf-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-aspath-orf-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-aspath-orf-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-12152611.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-aspath-orf-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-aspath-orf-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-12152611.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:55:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07670 for ; Tue, 30 Mar 2004 18:55:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riw-0006a4-F8 for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2M9xl18010495 for idr-archive@odin.ietf.org; Mon, 22 Mar 2004 04:59:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MDf-0002iv-UD for idr-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 04:59:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13459 for ; Mon, 22 Mar 2004 04:59:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5MDX-0000WM-00 for idr-web-archive@ietf.org; Mon, 22 Mar 2004 04:59:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5MCX-0000OV-00 for idr-web-archive@ietf.org; Mon, 22 Mar 2004 04:58:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5MC5-0000Hg-00; Mon, 22 Mar 2004 04:58:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBP-0002Ai-Jl; Mon, 22 Mar 2004 04:57:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Lfn-0002YY-TJ for idr@optimus.ietf.org; Tue, 16 Mar 2004 16:00:27 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24350; Tue, 16 Mar 2004 16:00:24 -0500 (EST) Message-Id: <200403162100.QAA24350@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-rfc2858bis-04.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 16:00:24 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Multiprotocol Extensions for BGP-4 Author(s) : T. Bates, R. Chandra, D. Katz, Y. Rekhter Filename : draft-ietf-idr-rfc2858bis-04.txt Pages : 11 Date : 2004-3-16 Currently BGP-4 is capable of carrying routing information only for IPv4. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-rfc2858bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-rfc2858bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-16162447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc2858bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc2858bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-16162447.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:55:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07734 for ; Tue, 30 Mar 2004 18:55:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riw-0006ZK-Dz for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MA0T5W010735 for idr-archive@odin.ietf.org; Mon, 22 Mar 2004 05:00:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MEL-0002mC-VB for idr-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 05:00:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13603 for ; Mon, 22 Mar 2004 05:00:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5MED-0000bo-00 for idr-web-archive@ietf.org; Mon, 22 Mar 2004 05:00:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5MDF-0000U7-00 for idr-web-archive@ietf.org; Mon, 22 Mar 2004 04:59:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5MC5-0000Hk-00; Mon, 22 Mar 2004 04:58:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBO-0002AU-Hc; Mon, 22 Mar 2004 04:57:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Lfi-0002YR-NK for idr@optimus.ietf.org; Tue, 16 Mar 2004 16:00:22 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24333; Tue, 16 Mar 2004 16:00:19 -0500 (EST) Message-Id: <200403162100.QAA24333@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-as4bytes-08.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 16:00:19 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP support for four-octet AS number space Author(s) : Q. Vohra, E. Chen Filename : draft-ietf-idr-as4bytes-08.txt Pages : 7 Date : 2004-3-16 Currently the Autonomous System number is encoded in BGP [BGP] as a two-octets field. This document describes extensions to BGP to carry the Autonomous System number as a four-octets field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-as4bytes-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-as4bytes-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-16162437.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-as4bytes-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-as4bytes-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-16162437.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 18:55:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07752 for ; Tue, 30 Mar 2004 18:55:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riw-0006ZK-Fz for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2M9xlF6010500 for idr-archive@odin.ietf.org; Mon, 22 Mar 2004 04:59:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MDi-0002iw-SJ for idr-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 04:59:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13487 for ; Mon, 22 Mar 2004 04:59:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5MDa-0000Wi-00 for idr-web-archive@ietf.org; Mon, 22 Mar 2004 04:59:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5MCa-0000P0-00 for idr-web-archive@ietf.org; Mon, 22 Mar 2004 04:58:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5MC5-0000Hl-00; Mon, 22 Mar 2004 04:58:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBU-0002FN-3M; Mon, 22 Mar 2004 04:57:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3db9-00022t-0V for idr@optimus.ietf.org; Wed, 17 Mar 2004 11:08:51 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15348; Wed, 17 Mar 2004 11:08:46 -0500 (EST) Message-Id: <200403171608.LAA15348@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-aspath-orf-06.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Mar 2004 11:08:46 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Aspath Based Outbound Route Filter for BGP-4 Author(s) : K. Patel, S. Hares Filename : draft-ietf-idr-aspath-orf-06.txt Pages : 0 Date : 2004-3-12 This document defines a new Outbound Router Filter type for BGP, termed 'Aspath Outbound Route Filter', that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-aspath-orf-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-aspath-orf-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-aspath-orf-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-17113158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-aspath-orf-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-aspath-orf-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-17113158.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From exim@www1.ietf.org Tue Mar 30 19:14:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00138 for ; Tue, 30 Mar 2004 18:26:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006a4-1J for idr-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SEoQke001578 for idr-archive@odin.ietf.org; Sat, 28 Feb 2004 09:50:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax5nO-0000PN-L0 for idr-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 09:50:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18376 for ; Sat, 28 Feb 2004 09:50:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax5nM-00068F-00 for idr-web-archive@ietf.org; Sat, 28 Feb 2004 09:50:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax5mJ-0005yH-00 for idr-web-archive@ietf.org; Sat, 28 Feb 2004 09:49:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax5lI-0005pI-00; Sat, 28 Feb 2004 09:48:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax5l3-00084V-Eu; Sat, 28 Feb 2004 09:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwcNA-0000JV-0p for idr@optimus.ietf.org; Fri, 27 Feb 2004 02:25:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17774 for ; Fri, 27 Feb 2004 02:25:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwcN6-0005m2-00 for idr@ietf.org; Fri, 27 Feb 2004 02:25:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwcMA-0005el-00 for idr@ietf.org; Fri, 27 Feb 2004 02:24:22 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AwcLG-0005YW-00 for idr@ietf.org; Fri, 27 Feb 2004 02:23:26 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i1R7MvRX031806; Fri, 27 Feb 2004 02:22:57 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200402270722.i1R7MvRX031806@workhorse.fictitious.org> To: Pedro Roque Marques cc: curtis@fictitious.org, idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] Question on MinASOrig Timer In-reply-to: Your message of "Thu, 26 Feb 2004 22:50:11 PST." <200402270650.i1R6oBuU039747@roque-bsd.juniper.net> From: Curtis Villamizar Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 27 Feb 2004 02:22:57 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <200402270650.i1R6oBuU039747@roque-bsd.juniper.net>, Pedro Roque Mar ques writes: > Curtis Villamizar writes: > > > If withdraws propogate faster first the unfeasible AS paths are > > removed, then the feasible ones start propogating. The result is > > some withdraw followed by add but much less AS path change in the > > presence of cycles. > > The point in which we differ is that you equate withdraws and updates > w/ unfeasible and feasible paths. I don't believe one can make that > assumption. > > For a given AS, if you have as input an withdraw that can result in an > update being generated or vice-versa, depending on the policy. > > You can have a link up event result in withdrawns being generated, and > a link down event result in updates. In other words the addition of > feasible paths, can result via policy, in withdrawls. > > > Providing separate timers allows us to defer the question of which > > is preferable. > > Providing separate timers, imho, will just further confuse the issue > :-). It has already been showen that there is no single choice of MRAI > timer that is appropriate for all situations. Now you propose an > additional one. That is two parameters nobody knows what the optimal > setting should be. > > Furthermore, i believe that, due to the meshed nature of internet > connectivity, using different delays may increase the duration of > transients. > > Lets say that you start w/ a current path through as3 and > you have a link up event (a) that brings up a prefered path. > > as 3 > | > --a-> as 1 --> as 4 > > --a-> as 2 --> as 4 > > If a is a peer route for as 1 but a customer route for as 2, then by > propagating the withdrawl faster you are increasing the transient time > and causing increase connectivity to create a blackhole for as4. > > imho, currently there is only one good known value for MRAI for both > updates and withdrawls, and that is 0. Let BGP speakers propagate > updates as fast as they can, taking into account that BGP itself > already has embedded flow control mechanisms that allow a receiver to > pace a sender appropriatly. > > Unfortunatly, even that setting (0) has its drawbacks. One is that > values should probably be consistent within an as, and there are very > different interpretations of MRAI between different vendors. The > second is that in case of MED oscillations, MRAI helps reduce the > ammount of churn. > > regards, > Pedro. Pedro, If you have separate timers for route origination/advertisement and up/down and the best solution is to set them all the same then it is possible to set them all the same. If you specify that they must be the same and that doesn't turn out to be the best way to do things you are stuck. Its clear that there isn't agreement on the best solution, so for the time being flexibility is needed. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA19320 for ; Mon, 29 Mar 2004 10:31:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7yjA-00082a-V7; Mon, 29 Mar 2004 10:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7yig-0007yv-N6 for idr@optimus.ietf.org; Mon, 29 Mar 2004 10:30:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08063 for ; Mon, 29 Mar 2004 10:30:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7yie-0003bP-00 for idr@ietf.org; Mon, 29 Mar 2004 10:30:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7yhw-0003Rr-00 for idr@ietf.org; Mon, 29 Mar 2004 10:29:49 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1B7yh7-0003H2-00 for idr@ietf.org; Mon, 29 Mar 2004 10:28:57 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i2TFRBBm061574; Mon, 29 Mar 2004 07:27:11 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i2TFRBJ49917; Mon, 29 Mar 2004 07:27:11 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200403291527.i2TFRBJ49917@merlot.juniper.net> To: "Bob Arthurs" cc: idr@ietf.org Subject: Re: [Idr] Question on draft-ietf-idr-bgp-ext-communities-06 In-Reply-To: Your message of "Fri, 26 Mar 2004 20:41:24 GMT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <83848.1080574031.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 29 Mar 2004 07:27:11 -0800 Bob, > hello > > i am doing some research on bgp and i wonder if someone can confirm a point > or two on bgp extended communities (specifically route targets in > draft-ietf-idr-bgp-ext-communities-06.txt). > > many thanks for any help in advance. > > are the following points true? > > 1. a route target has an extended Type field which is 2 octets long. correct. > 2. when the low order octet in the Type field is 0x02 this means that it is > a Route Target. >From the spec: The value of the high-order octet of the Type field for the Route Target Community can be 0x00, 0x01 or 0x02. The value of the low-order octet of the Type field for this community is 0x02. > 3. When the high order octect in the Type field is 0x00 or 0x02 then the > Global Administrator in the Value field is 2 or 4 octets respectively > (depending on high order Type value being 0x00 or 0x02). The Local > Administrator in this case is 4 or 2 octets respectively. correct. > 4. If the high order octet in the Type field is 0x00 or 0x02 then an AS > number (either 2 or 4 bytes) is carried in the Global Administrator. correct. > 5. If the high order octet in the Type field is 0x01 then an IP address is > carried in the Global Administrator part of the Value field. The Global > Administrator and Local Administrator in this case are 4 and 2 octets > respectively. correct. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA01992 for ; Fri, 26 Mar 2004 15:44:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6yBM-0003Up-AF; Fri, 26 Mar 2004 15:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6yB6-0003UR-FS for idr@optimus.ietf.org; Fri, 26 Mar 2004 15:43:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13683 for ; Fri, 26 Mar 2004 15:43:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6yB5-0005Ny-00 for idr@ietf.org; Fri, 26 Mar 2004 15:43:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6yA5-0005H5-00 for idr@ietf.org; Fri, 26 Mar 2004 15:42:41 -0500 Received: from bay8-f6.bay8.hotmail.com ([64.4.27.6] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B6y9L-000584-00 for idr@ietf.org; Fri, 26 Mar 2004 15:41:55 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 26 Mar 2004 12:41:24 -0800 Received: from 81.178.20.174 by by8fd.bay8.hotmail.msn.com with HTTP; Fri, 26 Mar 2004 20:41:24 GMT X-Originating-IP: [81.178.20.174] X-Originating-Email: [bob_arthurs@hotmail.com] X-Sender: bob_arthurs@hotmail.com From: "Bob Arthurs" To: idr@ietf.org Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2004 20:41:24.0911 (UTC) FILETIME=[B48633F0:01C41372] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Idr] Question on draft-ietf-idr-bgp-ext-communities-06 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 26 Mar 2004 20:41:24 +0000 hello i am doing some research on bgp and i wonder if someone can confirm a point or two on bgp extended communities (specifically route targets in draft-ietf-idr-bgp-ext-communities-06.txt). many thanks for any help in advance. are the following points true? 1. a route target has an extended Type field which is 2 octets long. 2. when the low order octet in the Type field is 0x02 this means that it is a Route Target. 3. When the high order octect in the Type field is 0x00 or 0x02 then the Global Administrator in the Value field is 2 or 4 octets respectively (depending on high order Type value being 0x00 or 0x02). The Local Administrator in this case is 4 or 2 octets respectively. 4. If the high order octet in the Type field is 0x00 or 0x02 then an AS number (either 2 or 4 bytes) is carried in the Global Administrator. 5. If the high order octet in the Type field is 0x01 then an IP address is carried in the Global Administrator part of the Value field. The Global Administrator and Local Administrator in this case are 4 and 2 octets respectively. thanks again, bob _________________________________________________________________ Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA16600 for ; Thu, 25 Mar 2004 17:03:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cwH-0006yG-D2; Thu, 25 Mar 2004 17:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cvY-0006sH-LS for idr@optimus.ietf.org; Thu, 25 Mar 2004 17:02:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27185 for ; Thu, 25 Mar 2004 17:02:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6cvW-0006M9-00 for idr@ietf.org; Thu, 25 Mar 2004 17:02:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ctt-0006Cg-00 for idr@ietf.org; Thu, 25 Mar 2004 17:00:34 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1B6ct5-00069R-00 for idr@ietf.org; Thu, 25 Mar 2004 16:59:43 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id B1F2880F683; Thu, 25 Mar 2004 13:59:43 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23881-09; Thu, 25 Mar 2004 13:59:43 -0800 (PST) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id 5C70280F682; Thu, 25 Mar 2004 13:59:43 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv2.redback.com (Postfix) with ESMTP id 1EE54979C1; Thu, 25 Mar 2004 13:59:43 -0800 (PST) To: idr@ietf.org Cc: enke@redback.com From: Enke Chen Message-Id: <20040325215943.1EE54979C1@popserv2.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] Implementation survey for BGP Cease Subcodes Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 25 Mar 2004 13:59:43 -0800 Hi, folks: In order to progress the BGP Cease Subcodes, we need an implementation report. For folks that have implemented the draft, could you please fill out the simple survey (attached), and send to me by April 9, 2004? Thanks. -- Enke --------------------------------------------------------------------- Implementation Report for BGP Cease Subcodes (draft-ietf-idr-cease-subcode-05.txt) Organization: Person filling out this form: Does your implementation recognize all the subcodes defined in the document? (If not, list the subcodes that your implementation recognizes.) List the subcodes that your implementation may send as part of a NOTIFICATION message. Does your implementation include the Address Family information and the upper bound in the "Data" field of a NOTIFICATION message for the subcode "maximum number of prefixes reached"? Does your implementation implement a backoff mechanism in re-trying a BGP connection, as recommended in the document? List other implementations that you have tested for BGP Cease Subcodes interoperability. --------------------------------------------------------------------- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA15700 for ; Tue, 23 Mar 2004 19:11:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vz4-0006Jm-TQ; Tue, 23 Mar 2004 19:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5u9Q-0005Mg-AF for idr@optimus.ietf.org; Tue, 23 Mar 2004 17:13:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06601 for ; Tue, 23 Mar 2004 17:13:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5u9O-00024f-00 for idr@ietf.org; Tue, 23 Mar 2004 17:13:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5u8V-000216-00 for idr@ietf.org; Tue, 23 Mar 2004 17:12:40 -0500 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx with smtp (Exim 4.12) id 1B5u7v-0001vf-00 for idr@ietf.org; Tue, 23 Mar 2004 17:12:03 -0500 Received: (qmail 54988 invoked from network); 23 Mar 2004 22:11:33 -0000 Received: from 207-171-180-101.amazon.com (HELO ?10.21.134.173?) (ben@207.171.180.101) by layer8.net with SMTP; 23 Mar 2004 22:11:33 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0FA21A83-7D17-11D8-98C8-000A95DA7468@layer8.net> Content-Transfer-Encoding: 7bit Cc: idr@ietf.org From: Benjamin Black Subject: Re: [Idr] IBGP to replace IGP To: "john smith" X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 14:11:40 -0800 a) scheduling is a minor concern. b) certainly carrying a default helps reduce the size of the table, but that is orthogonal to the question. it is not common practice to carry much in the igp (meaning bgp is not redistributed into the igp), so carrying a default really is reducing the size of your bgp ribs which is something you can do regardless of whether you have a second protocol for the igp. c) yes, flapping routes are a problem regardless of protocol, so you generally want one that converges very quickly. a good link-state protocol like ospf converges in seconds vs minutes for bgp in a reasonably complex network. again, the igp is only carrying limited information (links and loops being a very common scenario) and has very detailed knowledge of the network (handling per-link metrics in bgp would get very ugly very fast) so it can do things that are inconvenient or impossible with bgp. d) i don't know what benefits you mean. decoupling the churn of the "global view" from the stability of your internal network supports using an independent igp. e) if they can't understand ospf they shouldn't be touching the routers anyway. f) i'm not suggesting the use of a default route. your questions (and name) seem more like someone lost from nanog looking to do some trolling than someone interested in discussing protocols, but i could be wrong. ben On Mar 22, 2004, at 7:22 PM, john smith wrote: > Hi Ben, > > It would be great if you could share some more information on the > "issues" of convergence time, CPU loads, and RP overloads. > > From my understanding > a. it makes more sense to have 1 routing protocol as we dont have > multiple daemons scheduled on the CPU. (which ofcourse is not a > problem but then so is the point you mentioned below) > > b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we > inject 0.0.0.0/0 into IGP to make unknown prefixes go to the nearest > BGP node.So does that help reduce the size of your routing table? > > c. The cases u mention of changes, I presume you mean route-flaps. > Well in that case, we eitherways have issues when IGP flaps, we > eitherways wait for IGP to converge for BGP to converge etc? (I am > sure "real traffic" operators do that) > > d. We have the benefits of not having the "global view" dependent on 1 > protocol while the internal topology dependent on another > > e. all i need to teach the network admins is BGP :) > > f. Based on c, how would you say that it makes things more complicated > to run iBGP only compared to IGP+0.0.0.0/0 (default originate and > originate always) and all those things taken into consideration? > > would be great if you could help clarify this. > > -Smith > > > > > > > You could certainly run BGP and statics without another protocol for > the IGP, but why would you want to? Convergence times, CPU load on > RPs, etc., during changes would be rather unsatisfactory. If you want > to run one dynamic protocol at all costs, then what you describe below > will work, and has worked for some, but people with real traffic don't > waste their time with it. > > > Ben > > On Mar 15, 2004, at 8:24 PM, John Smith wrote: > > > Hi, > > I am very clear with the concept that IGPs cannot be used to carry the > entire BGP feed as > they cant be scaled to carry so many prefixes (even assuming we add > enough TLVs to make > them carry the BGP attributes). > > What is not very clear to me is, why cant we use IBGP inside an AS to > completely do away > with IGPs. IGPs compute the best path to reach a particular neighbor > based on the link > metric. This can be achieved in BGP also, if we include a TLV to carry > the link cost. > Moreover, it is *mandatory* to run BGP on all the routers if we are > transiting traffic, > because if a router isnt speaking BGP then it cant forward BGP traffic. > > Cant we do away with IGPs (say in some small networks) and run only > IBGP there? > > Any help/clues/pointers in this regard will be really appreciated. > > Regards, > Smith > > _________________________________________________________________ > Tired of spam? Get advanced junk mail protection with MSN 8. > http://join.msn.com/?page=features/junkmail > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA15699 for ; Tue, 23 Mar 2004 19:11:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vz5-0006Ka-IQ; Tue, 23 Mar 2004 19:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uvt-0003Z0-79 for idr@optimus.ietf.org; Tue, 23 Mar 2004 18:03:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09151 for ; Tue, 23 Mar 2004 18:03:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uvq-0006fC-00 for idr@ietf.org; Tue, 23 Mar 2004 18:03:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5uus-0006bK-00 for idr@ietf.org; Tue, 23 Mar 2004 18:02:39 -0500 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx with smtp (Exim 4.12) id 1B5uuO-0006XA-00 for idr@ietf.org; Tue, 23 Mar 2004 18:02:08 -0500 Received: (qmail 55861 invoked from network); 23 Mar 2004 23:01:38 -0000 Received: from 207-171-180-101.amazon.com (HELO ?10.21.134.173?) (ben@207.171.180.101) by layer8.net with SMTP; 23 Mar 2004 23:01:38 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0D84F406-7D1E-11D8-9C3C-000A95DA7468@layer8.net> Content-Transfer-Encoding: 7bit Cc: cmartin@gnilink.net, idr@ietf.org From: Benjamin Black Subject: Re: [Idr] IBGP to replace IGP To: "john smith" X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 15:01:43 -0800 from the sound of things you don't need bgp at all, except to announce routes to your upstreams. rejecting all routes from a peer tends to limit the size of adj-rib-in as well as reduce the cpu load of route flaps. handle the rest with an igp and a default and you are done (and your network admins need know almost nothing about bgp). ben On Mar 23, 2004, at 2:43 PM, john smith wrote: > Check my reply to Ben, it covers a lot of commong ground > > I think you missed out the point that I was planning to put 0.0.0.0/0 > in the intermediate nodes to cover the internet. > > It is nothing buy my IGP replaced with BGP. 0.0.0.0/0 and all that > being considered for intermediate nodes. > > Route flaps are a result of "actualy flaps somewhere" and if you were > to follow the 0.0.0.0/0 principal neither would your intermediate > nodes give a problem. > > The loops would abound in case of any IGP too when u inject 0.0.0.0/0 > into the IGP, so maybe I didnt quite get that point > >> From: "Martin, Christian" >> To: 'john smith' , "'idr@ietf.org'" >> >> Subject: RE: [Idr] IBGP to replace IGP >> Date: Tue, 23 Mar 2004 17:35:58 -0500 >> >> Smith, >> >> Comments inline, as I have been following this thread. >> >> >> >It would be great if you could share some more information on >> >the "issues" >> >of convergence time, CPU loads, and RP overloads. >> >> Convergence is typically nonlienearly proportionate to CPU load, and >> vice-versa, and they often feed off each other in a negative way. >> Network >> meltdowns are typically the result of routing loads disrupting >> topology >> maintenance mechanisms, thereby causing adjacency loss, which causes >> more >> routing load, which inhibits adjacency recreation, etc. I've seen >> networks >> stay in persistent "ditches" because the >> convergence-adjacency-divergence-adjaceny-...loop stayed closed due to >> loading. Not fun to have to rebuild all of your routers or reattach >> them to >> the network one by one... >> >> >From my understanding >> >a. it makes more sense to have 1 routing protocol as we dont >> >have multiple >> >daemons scheduled on the CPU. (which ofcourse is not a problem >> >but then so >> >is the point you mentioned below) >> >> In either case, BGP will consume the vast majority of CPU cycles. >> IGPs that >> are properly tuned in stable environments hardly tickle the CPU, let >> alone >> heat it up. Take LSA/P refresh out of the picture, and all the IGP >> does is >> send hellos and occasionally flood an LSA/P and compute an SPT once >> in a >> rare while. In the Internet, BGP is constantly processing updates and >> withdrawals, all day, every day. Sometimes, we see 100s of updates >> per >> minute, sometimes just a few, but they are always there. >> >> >b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like >> we >> >inject 0.0.0.0/0 into IGP to make unknown prefixes go to the >> >nearest BGP >> >node.So does that help reduce the size of your routing table? >> >> Large SPs must run a full BGP load, at a minimum, to give routes to >> their >> customers. Unless you are talking about enterprise routing, we >> should avoid >> discussions of default routes... >> >> >c. The cases u mention of changes, I presume you mean >> >route-flaps. Well in >> >that case, we eitherways have issues when IGP flaps, we >> >eitherways wait for >> >IGP to converge for BGP to converge etc? (I am sure "real >> >traffic" operators >> >do that) >> >> Modern IGPs, properly tuned, converge way faster than BGP. BGP >> convergence >> is designed to be slow, so as not to place too much load on the global >> routing system. Since BGP carries so many routes, and since the >> topological >> density of the Internet Autonomous System graph increases every day, >> BGP can >> often take minutes to converge. IGPs take seconds, partly because >> they are >> usually lightweight. >> >> >d. We have the benefits of not having the "global view" dependent on >> 1 >> >protocol while the internal topology dependent on another >> >> This is actually a sound design. Think of the IGP as a topology >> discovery >> mechanism. All BGP routes have a next-hop. The goal of BGP is to >> take >> traffic to and from the "edges" of the network. Sometimes, the edge >> is >> within your network, like a server farm. IGPs are very good at >> discovering >> a topology and identifying the shortest path to each edge. BGP is not >> designed for this, and to make it do so requires considerable >> planning and >> lots of policy. >> >> >e. all i need to teach the network admins is BGP :) >> >> It is much easier to learn simple IS-IS and OSPF than BGP. Link >> State IGPs, >> when employed for topology discovery, are exceedingly simple >> (particularly >> IS-IS in a single area). BGP, on the otherhand, is a much bigger >> protocol >> that requires a lot of policy engineering in order for it to be >> effective. >> >> >f. Based on c, how would you say that it makes things more >> >complicated to >> >run iBGP only compared to IGP+0.0.0.0/0 (default originate and >> >originate >> >always) and all those things taken into consideration? >> >> Are you talking about running in an enterprise? Default routes will >> not >> work in any large environment for next-hop discovery of your iBGP >> peer IP's. >> Loops would abound... >> >> >> One of the problems with your proposal, and the primary reason this >> is not >> done, is that iBGP does not provide for transitive route >> dissemination in a >> network. All 'other' IGPs do this. This means your network topology >> must >> be highly symmetrical and/or fully meshed at layer 3 (at least in >> subsections) to allow for end-to-end route propagation. Unless you >> can >> employ lots of confeds (ie, each router in a confed subAS), lots of >> route-reflectors, or a full-mesh topology at layer 3 (and layer 2 if >> you >> consider multiaccess networks fully-meshed), then this approach is not >> possible. >> >> BGP also has race-condition mitigation rules that prevent a BGP route >> from >> being learned from a next-hop that is known via BGP, so injecting >> routes >> into BGP and hoping to bootstrap the next-hops would be problematic. >> This >> restriction is subtle and perhaps vendor specific, but usually, the >> next-hop >> is recursed through an IGP or connected interface. If this were >> possible, >> in any event, it would be slow-converging, as iBGP updates are >> typically >> spaced at 5 second intervals (depending on the event type). Also, >> you will >> have to peer with every interface on the device, thus forcing traffic >> to >> take certain paths that may not be the best path available, as most >> BGP >> attributes are non-accumulating (ie, u have to statically increase, >> say, >> local-pref via policy as routes propagate along a set of routers in >> your >> AS). >> >> The reality is that even if such an approach _were_ possible, the >> drawbacks >> are much more severe than simply turning on an IGP and having it >> discover >> your topology. Then, you may do what you with with iBGP. >> >> The best philosophy, IMO, is to place loopbacks and links in your >> IGP, and >> carry externals (either self-originated or from another AS) in your >> iBGP. >> Route-reflectors are useful if regionalized, as they make best path >> decisions before reflecting (so u want to be careful who peers with >> what to >> ensure path selection optimality). Confeds afford more control, TE, >> etc., >> but at what some claim to be a higher admin cost. Use them based on >> what >> you are trying to do. >> >> HTH, >> Chris >> >> >would be great if you could help clarify this. >> > >> >-Smith >> > >> >> >> >> >> >> >> > >> > >> > >> > >> >You could certainly run BGP and statics without another >> >protocol for the >> >IGP, but why would you want to? Convergence times, CPU load on >> >RPs, etc., >> >during changes would be rather unsatisfactory. If you want to run one >> >dynamic protocol at all costs, then what you describe below >> >will work, and >> >has worked for some, but people with real traffic don't waste >> >their time >> >with it. >> > >> > >> >Ben >> > >> >On Mar 15, 2004, at 8:24 PM, John Smith wrote: >> > >> > >> >Hi, >> > >> >I am very clear with the concept that IGPs cannot be used to carry >> the >> >entire BGP feed as >> >they cant be scaled to carry so many prefixes (even assuming >> >we add enough >> >TLVs to make >> >them carry the BGP attributes). >> > >> >What is not very clear to me is, why cant we use IBGP inside an AS to >> >completely do away >> >with IGPs. IGPs compute the best path to reach a particular >> >neighbor based >> >on the link >> >metric. This can be achieved in BGP also, if we include a TLV >> >to carry the >> >link cost. >> >Moreover, it is *mandatory* to run BGP on all the routers if we are >> >transiting traffic, >> >because if a router isnt speaking BGP then it cant forward BGP >> traffic. >> > >> >Cant we do away with IGPs (say in some small networks) and run >> >only IBGP >> >there? >> > >> >Any help/clues/pointers in this regard will be really appreciated. >> > >> >Regards, >> >Smith >> > >> >_________________________________________________________________ >> >Tired of spam? Get advanced junk mail protection with MSN 8. >> >http://join.msn.com/?page=features/junkmail >> > >> > >> >_______________________________________________ >> >Idr mailing list >> >Idr@ietf.org >> >https://www1.ietf.org/mailman/listinfo/idr >> > > > _________________________________________________________________ > MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. > http://join.msn.com/?page=features/virus > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA15077 for ; Tue, 23 Mar 2004 18:14:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5v5t-0007fa-9g; Tue, 23 Mar 2004 18:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5v4u-0007SL-TL for idr@optimus.ietf.org; Tue, 23 Mar 2004 18:13:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10226 for ; Tue, 23 Mar 2004 18:12:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5v4s-0007Mz-00 for idr@ietf.org; Tue, 23 Mar 2004 18:12:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5v3r-0007Gs-00 for idr@ietf.org; Tue, 23 Mar 2004 18:11:56 -0500 Received: from law9-f21.law9.hotmail.com ([64.4.9.21] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B5v3N-000799-00 for idr@ietf.org; Tue, 23 Mar 2004 18:11:26 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 23 Mar 2004 15:10:54 -0800 Received: from 64.38.138.134 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 23 Mar 2004 23:10:54 GMT X-Originating-IP: [64.38.138.134] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: ben@layer8.net Cc: cmartin@gnilink.net, idr@ietf.org Subject: Re: [Idr] IBGP to replace IGP Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Mar 2004 23:10:54.0117 (UTC) FILETIME=[17592D50:01C4112C] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 23:10:54 +0000 I am not saying that you do not need BGP "at all". The default route to a node "with complete information" only covers the case where you have intermediate nodes which cannot handle the complete routing table due to certain limitations highlighted by you. The reason we use BGP today is the very reason we still need to use BGP. Some one"has to be the *upstream*". There has to be a point in the network where you decide if A or B is the best way to send traffic outside your AS. All I am asking is why do we need IGP when the same things that are done by IGP can be done within BGP. If you plan to extend an IGP like OSPF (LinkState) to do the same things that BGP does today (provides a point in the network which has complete and accurate information), and you believe the performance will be better, I would be really curious to see the results and would be thankful if you could share the same. >From: Benjamin Black >To: "john smith" >CC: cmartin@gnilink.net, idr@ietf.org >Subject: Re: [Idr] IBGP to replace IGP >Date: Tue, 23 Mar 2004 15:01:43 -0800 > >from the sound of things you don't need bgp at all, except to announce >routes to your upstreams. rejecting all routes from a peer tends to limit >the size of adj-rib-in as well as reduce the cpu load of route flaps. >handle the rest with an igp and a default and you are done (and your >network admins need know almost nothing about bgp). > > >ben > >On Mar 23, 2004, at 2:43 PM, john smith wrote: > >>Check my reply to Ben, it covers a lot of commong ground >> >>I think you missed out the point that I was planning to put 0.0.0.0/0 in >>the intermediate nodes to cover the internet. >> >>It is nothing buy my IGP replaced with BGP. 0.0.0.0/0 and all that being >>considered for intermediate nodes. >> >>Route flaps are a result of "actualy flaps somewhere" and if you were to >>follow the 0.0.0.0/0 principal neither would your intermediate nodes give >>a problem. >> >>The loops would abound in case of any IGP too when u inject 0.0.0.0/0 into >>the IGP, so maybe I didnt quite get that point >> >>>From: "Martin, Christian" >>>To: 'john smith' , "'idr@ietf.org'" >>> >>>Subject: RE: [Idr] IBGP to replace IGP >>>Date: Tue, 23 Mar 2004 17:35:58 -0500 >>> >>>Smith, >>> >>>Comments inline, as I have been following this thread. >>> >>> >>> >It would be great if you could share some more information on >>> >the "issues" >>> >of convergence time, CPU loads, and RP overloads. >>> >>>Convergence is typically nonlienearly proportionate to CPU load, and >>>vice-versa, and they often feed off each other in a negative way. >>>Network >>>meltdowns are typically the result of routing loads disrupting topology >>>maintenance mechanisms, thereby causing adjacency loss, which causes more >>>routing load, which inhibits adjacency recreation, etc. I've seen >>>networks >>>stay in persistent "ditches" because the >>>convergence-adjacency-divergence-adjaceny-...loop stayed closed due to >>>loading. Not fun to have to rebuild all of your routers or reattach them >>>to >>>the network one by one... >>> >>> >From my understanding >>> >a. it makes more sense to have 1 routing protocol as we dont >>> >have multiple >>> >daemons scheduled on the CPU. (which ofcourse is not a problem >>> >but then so >>> >is the point you mentioned below) >>> >>>In either case, BGP will consume the vast majority of CPU cycles. IGPs >>>that >>>are properly tuned in stable environments hardly tickle the CPU, let >>>alone >>>heat it up. Take LSA/P refresh out of the picture, and all the IGP does >>>is >>>send hellos and occasionally flood an LSA/P and compute an SPT once in a >>>rare while. In the Internet, BGP is constantly processing updates and >>>withdrawals, all day, every day. Sometimes, we see 100s of updates per >>>minute, sometimes just a few, but they are always there. >>> >>> >b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we >>> >inject 0.0.0.0/0 into IGP to make unknown prefixes go to the >>> >nearest BGP >>> >node.So does that help reduce the size of your routing table? >>> >>>Large SPs must run a full BGP load, at a minimum, to give routes to their >>>customers. Unless you are talking about enterprise routing, we should >>>avoid >>>discussions of default routes... >>> >>> >c. The cases u mention of changes, I presume you mean >>> >route-flaps. Well in >>> >that case, we eitherways have issues when IGP flaps, we >>> >eitherways wait for >>> >IGP to converge for BGP to converge etc? (I am sure "real >>> >traffic" operators >>> >do that) >>> >>>Modern IGPs, properly tuned, converge way faster than BGP. BGP >>>convergence >>>is designed to be slow, so as not to place too much load on the global >>>routing system. Since BGP carries so many routes, and since the >>>topological >>>density of the Internet Autonomous System graph increases every day, BGP >>>can >>>often take minutes to converge. IGPs take seconds, partly because they >>>are >>>usually lightweight. >>> >>> >d. We have the benefits of not having the "global view" dependent on 1 >>> >protocol while the internal topology dependent on another >>> >>>This is actually a sound design. Think of the IGP as a topology >>>discovery >>>mechanism. All BGP routes have a next-hop. The goal of BGP is to take >>>traffic to and from the "edges" of the network. Sometimes, the edge is >>>within your network, like a server farm. IGPs are very good at >>>discovering >>>a topology and identifying the shortest path to each edge. BGP is not >>>designed for this, and to make it do so requires considerable planning >>>and >>>lots of policy. >>> >>> >e. all i need to teach the network admins is BGP :) >>> >>>It is much easier to learn simple IS-IS and OSPF than BGP. Link State >>>IGPs, >>>when employed for topology discovery, are exceedingly simple >>>(particularly >>>IS-IS in a single area). BGP, on the otherhand, is a much bigger >>>protocol >>>that requires a lot of policy engineering in order for it to be >>>effective. >>> >>> >f. Based on c, how would you say that it makes things more >>> >complicated to >>> >run iBGP only compared to IGP+0.0.0.0/0 (default originate and >>> >originate >>> >always) and all those things taken into consideration? >>> >>>Are you talking about running in an enterprise? Default routes will not >>>work in any large environment for next-hop discovery of your iBGP peer >>>IP's. >>>Loops would abound... >>> >>> >>>One of the problems with your proposal, and the primary reason this is >>>not >>>done, is that iBGP does not provide for transitive route dissemination in >>>a >>>network. All 'other' IGPs do this. This means your network topology >>>must >>>be highly symmetrical and/or fully meshed at layer 3 (at least in >>>subsections) to allow for end-to-end route propagation. Unless you can >>>employ lots of confeds (ie, each router in a confed subAS), lots of >>>route-reflectors, or a full-mesh topology at layer 3 (and layer 2 if you >>>consider multiaccess networks fully-meshed), then this approach is not >>>possible. >>> >>>BGP also has race-condition mitigation rules that prevent a BGP route >>>from >>>being learned from a next-hop that is known via BGP, so injecting routes >>>into BGP and hoping to bootstrap the next-hops would be problematic. >>>This >>>restriction is subtle and perhaps vendor specific, but usually, the >>>next-hop >>>is recursed through an IGP or connected interface. If this were >>>possible, >>>in any event, it would be slow-converging, as iBGP updates are typically >>>spaced at 5 second intervals (depending on the event type). Also, you >>>will >>>have to peer with every interface on the device, thus forcing traffic to >>>take certain paths that may not be the best path available, as most BGP >>>attributes are non-accumulating (ie, u have to statically increase, say, >>>local-pref via policy as routes propagate along a set of routers in your >>>AS). >>> >>>The reality is that even if such an approach _were_ possible, the >>>drawbacks >>>are much more severe than simply turning on an IGP and having it discover >>>your topology. Then, you may do what you with with iBGP. >>> >>>The best philosophy, IMO, is to place loopbacks and links in your IGP, >>>and >>>carry externals (either self-originated or from another AS) in your iBGP. >>>Route-reflectors are useful if regionalized, as they make best path >>>decisions before reflecting (so u want to be careful who peers with what >>>to >>>ensure path selection optimality). Confeds afford more control, TE, >>>etc., >>>but at what some claim to be a higher admin cost. Use them based on what >>>you are trying to do. >>> >>>HTH, >>>Chris >>> >>> >would be great if you could help clarify this. >>> > >>> >-Smith >>> > >>> >>> >>> >>> >>> >>> >>> > >>> > >>> > >>> > >>> >You could certainly run BGP and statics without another >>> >protocol for the >>> >IGP, but why would you want to? Convergence times, CPU load on >>> >RPs, etc., >>> >during changes would be rather unsatisfactory. If you want to run one >>> >dynamic protocol at all costs, then what you describe below >>> >will work, and >>> >has worked for some, but people with real traffic don't waste >>> >their time >>> >with it. >>> > >>> > >>> >Ben >>> > >>> >On Mar 15, 2004, at 8:24 PM, John Smith wrote: >>> > >>> > >>> >Hi, >>> > >>> >I am very clear with the concept that IGPs cannot be used to carry the >>> >entire BGP feed as >>> >they cant be scaled to carry so many prefixes (even assuming >>> >we add enough >>> >TLVs to make >>> >them carry the BGP attributes). >>> > >>> >What is not very clear to me is, why cant we use IBGP inside an AS to >>> >completely do away >>> >with IGPs. IGPs compute the best path to reach a particular >>> >neighbor based >>> >on the link >>> >metric. This can be achieved in BGP also, if we include a TLV >>> >to carry the >>> >link cost. >>> >Moreover, it is *mandatory* to run BGP on all the routers if we are >>> >transiting traffic, >>> >because if a router isnt speaking BGP then it cant forward BGP traffic. >>> > >>> >Cant we do away with IGPs (say in some small networks) and run >>> >only IBGP >>> >there? >>> > >>> >Any help/clues/pointers in this regard will be really appreciated. >>> > >>> >Regards, >>> >Smith >>> > >>> >_________________________________________________________________ >>> >Tired of spam? Get advanced junk mail protection with MSN 8. >>> >http://join.msn.com/?page=features/junkmail >>> > >>> > >>> >_______________________________________________ >>> >Idr mailing list >>> >Idr@ietf.org >>> >https://www1.ietf.org/mailman/listinfo/idr >>> > >> >>_________________________________________________________________ >>MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. >>http://join.msn.com/?page=features/virus >> >> >>_______________________________________________ >>Idr mailing list >>Idr@ietf.org >>https://www1.ietf.org/mailman/listinfo/idr >> >> > _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA14928 for ; Tue, 23 Mar 2004 18:03:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uvF-0003GQ-Ba; Tue, 23 Mar 2004 18:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uur-0002pY-58 for idr@optimus.ietf.org; Tue, 23 Mar 2004 18:02:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09076 for ; Tue, 23 Mar 2004 18:02:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uuo-0006aT-00 for idr@ietf.org; Tue, 23 Mar 2004 18:02:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5utv-0006XX-00 for idr@ietf.org; Tue, 23 Mar 2004 18:01:40 -0500 Received: from entmail.gnilink.net ([199.45.47.10]) by ietf-mx with esmtp (Exim 4.12) id 1B5utj-0006Tk-00 for idr@ietf.org; Tue, 23 Mar 2004 18:01:27 -0500 Received: by entmail.gnilink.net with Internet Mail Service (5.5.2656.59) id ; Tue, 23 Mar 2004 18:00:58 -0500 Message-ID: <94B9091E1149D411A45C00508BACEB35071A32DE@entmail.gnilink.net> From: "Martin, Christian" To: "'john smith'" Cc: "'idr@ietf.org'" Subject: RE: [Idr] IBGP to replace IGP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 18:00:54 -0500 John, We are drifting off topic for this list here. Perhaps you should take this up on a list that covers fundamental routing concepts. Contact me privately if you wish to engage further. Thanks, chris >Check my reply to Ben, it covers a lot of commong ground > >I think you missed out the point that I was planning to put >0.0.0.0/0 in the >intermediate nodes to cover the internet. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA14771 for ; Tue, 23 Mar 2004 17:46:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uem-0008Ev-PZ; Tue, 23 Mar 2004 17:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ueM-0008D5-PQ for idr@optimus.ietf.org; Tue, 23 Mar 2004 17:45:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07948 for ; Tue, 23 Mar 2004 17:45:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ueK-0004vU-00 for idr@ietf.org; Tue, 23 Mar 2004 17:45:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5udM-0004rI-00 for idr@ietf.org; Tue, 23 Mar 2004 17:44:33 -0500 Received: from law9-f28.law9.hotmail.com ([64.4.9.28] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B5ucW-0004kA-00 for idr@ietf.org; Tue, 23 Mar 2004 17:43:40 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 23 Mar 2004 14:43:10 -0800 Received: from 64.38.138.134 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 23 Mar 2004 22:43:10 GMT X-Originating-IP: [64.38.138.134] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: cmartin@gnilink.net Cc: idr@ietf.org Subject: RE: [Idr] IBGP to replace IGP Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Mar 2004 22:43:10.0650 (UTC) FILETIME=[37D841A0:01C41128] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 22:43:10 +0000 Check my reply to Ben, it covers a lot of commong ground I think you missed out the point that I was planning to put 0.0.0.0/0 in the intermediate nodes to cover the internet. It is nothing buy my IGP replaced with BGP. 0.0.0.0/0 and all that being considered for intermediate nodes. Route flaps are a result of "actualy flaps somewhere" and if you were to follow the 0.0.0.0/0 principal neither would your intermediate nodes give a problem. The loops would abound in case of any IGP too when u inject 0.0.0.0/0 into the IGP, so maybe I didnt quite get that point >From: "Martin, Christian" >To: 'john smith' , "'idr@ietf.org'" > >Subject: RE: [Idr] IBGP to replace IGP >Date: Tue, 23 Mar 2004 17:35:58 -0500 > >Smith, > >Comments inline, as I have been following this thread. > > > >It would be great if you could share some more information on > >the "issues" > >of convergence time, CPU loads, and RP overloads. > >Convergence is typically nonlienearly proportionate to CPU load, and >vice-versa, and they often feed off each other in a negative way. Network >meltdowns are typically the result of routing loads disrupting topology >maintenance mechanisms, thereby causing adjacency loss, which causes more >routing load, which inhibits adjacency recreation, etc. I've seen networks >stay in persistent "ditches" because the >convergence-adjacency-divergence-adjaceny-...loop stayed closed due to >loading. Not fun to have to rebuild all of your routers or reattach them >to >the network one by one... > > >From my understanding > >a. it makes more sense to have 1 routing protocol as we dont > >have multiple > >daemons scheduled on the CPU. (which ofcourse is not a problem > >but then so > >is the point you mentioned below) > >In either case, BGP will consume the vast majority of CPU cycles. IGPs >that >are properly tuned in stable environments hardly tickle the CPU, let alone >heat it up. Take LSA/P refresh out of the picture, and all the IGP does is >send hellos and occasionally flood an LSA/P and compute an SPT once in a >rare while. In the Internet, BGP is constantly processing updates and >withdrawals, all day, every day. Sometimes, we see 100s of updates per >minute, sometimes just a few, but they are always there. > > >b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we > >inject 0.0.0.0/0 into IGP to make unknown prefixes go to the > >nearest BGP > >node.So does that help reduce the size of your routing table? > >Large SPs must run a full BGP load, at a minimum, to give routes to their >customers. Unless you are talking about enterprise routing, we should >avoid >discussions of default routes... > > >c. The cases u mention of changes, I presume you mean > >route-flaps. Well in > >that case, we eitherways have issues when IGP flaps, we > >eitherways wait for > >IGP to converge for BGP to converge etc? (I am sure "real > >traffic" operators > >do that) > >Modern IGPs, properly tuned, converge way faster than BGP. BGP convergence >is designed to be slow, so as not to place too much load on the global >routing system. Since BGP carries so many routes, and since the >topological >density of the Internet Autonomous System graph increases every day, BGP >can >often take minutes to converge. IGPs take seconds, partly because they are >usually lightweight. > > >d. We have the benefits of not having the "global view" dependent on 1 > >protocol while the internal topology dependent on another > >This is actually a sound design. Think of the IGP as a topology discovery >mechanism. All BGP routes have a next-hop. The goal of BGP is to take >traffic to and from the "edges" of the network. Sometimes, the edge is >within your network, like a server farm. IGPs are very good at discovering >a topology and identifying the shortest path to each edge. BGP is not >designed for this, and to make it do so requires considerable planning and >lots of policy. > > >e. all i need to teach the network admins is BGP :) > >It is much easier to learn simple IS-IS and OSPF than BGP. Link State >IGPs, >when employed for topology discovery, are exceedingly simple (particularly >IS-IS in a single area). BGP, on the otherhand, is a much bigger protocol >that requires a lot of policy engineering in order for it to be effective. > > >f. Based on c, how would you say that it makes things more > >complicated to > >run iBGP only compared to IGP+0.0.0.0/0 (default originate and > >originate > >always) and all those things taken into consideration? > >Are you talking about running in an enterprise? Default routes will not >work in any large environment for next-hop discovery of your iBGP peer >IP's. >Loops would abound... > > >One of the problems with your proposal, and the primary reason this is not >done, is that iBGP does not provide for transitive route dissemination in a >network. All 'other' IGPs do this. This means your network topology must >be highly symmetrical and/or fully meshed at layer 3 (at least in >subsections) to allow for end-to-end route propagation. Unless you can >employ lots of confeds (ie, each router in a confed subAS), lots of >route-reflectors, or a full-mesh topology at layer 3 (and layer 2 if you >consider multiaccess networks fully-meshed), then this approach is not >possible. > >BGP also has race-condition mitigation rules that prevent a BGP route from >being learned from a next-hop that is known via BGP, so injecting routes >into BGP and hoping to bootstrap the next-hops would be problematic. This >restriction is subtle and perhaps vendor specific, but usually, the >next-hop >is recursed through an IGP or connected interface. If this were possible, >in any event, it would be slow-converging, as iBGP updates are typically >spaced at 5 second intervals (depending on the event type). Also, you will >have to peer with every interface on the device, thus forcing traffic to >take certain paths that may not be the best path available, as most BGP >attributes are non-accumulating (ie, u have to statically increase, say, >local-pref via policy as routes propagate along a set of routers in your >AS). > >The reality is that even if such an approach _were_ possible, the drawbacks >are much more severe than simply turning on an IGP and having it discover >your topology. Then, you may do what you with with iBGP. > >The best philosophy, IMO, is to place loopbacks and links in your IGP, and >carry externals (either self-originated or from another AS) in your iBGP. >Route-reflectors are useful if regionalized, as they make best path >decisions before reflecting (so u want to be careful who peers with what to >ensure path selection optimality). Confeds afford more control, TE, etc., >but at what some claim to be a higher admin cost. Use them based on what >you are trying to do. > >HTH, >Chris > > >would be great if you could help clarify this. > > > >-Smith > > > > > > > > > > > > > > > > > >You could certainly run BGP and statics without another > >protocol for the > >IGP, but why would you want to? Convergence times, CPU load on > >RPs, etc., > >during changes would be rather unsatisfactory. If you want to run one > >dynamic protocol at all costs, then what you describe below > >will work, and > >has worked for some, but people with real traffic don't waste > >their time > >with it. > > > > > >Ben > > > >On Mar 15, 2004, at 8:24 PM, John Smith wrote: > > > > > >Hi, > > > >I am very clear with the concept that IGPs cannot be used to carry the > >entire BGP feed as > >they cant be scaled to carry so many prefixes (even assuming > >we add enough > >TLVs to make > >them carry the BGP attributes). > > > >What is not very clear to me is, why cant we use IBGP inside an AS to > >completely do away > >with IGPs. IGPs compute the best path to reach a particular > >neighbor based > >on the link > >metric. This can be achieved in BGP also, if we include a TLV > >to carry the > >link cost. > >Moreover, it is *mandatory* to run BGP on all the routers if we are > >transiting traffic, > >because if a router isnt speaking BGP then it cant forward BGP traffic. > > > >Cant we do away with IGPs (say in some small networks) and run > >only IBGP > >there? > > > >Any help/clues/pointers in this regard will be really appreciated. > > > >Regards, > >Smith > > > >_________________________________________________________________ > >Tired of spam? Get advanced junk mail protection with MSN 8. > >http://join.msn.com/?page=features/junkmail > > > > > >_______________________________________________ > >Idr mailing list > >Idr@ietf.org > >https://www1.ietf.org/mailman/listinfo/idr > > _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA14757 for ; Tue, 23 Mar 2004 17:44:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ucr-00081V-IZ; Tue, 23 Mar 2004 17:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ucX-00080K-G9 for idr@optimus.ietf.org; Tue, 23 Mar 2004 17:43:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07912 for ; Tue, 23 Mar 2004 17:43:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ucU-0004nB-00 for idr@ietf.org; Tue, 23 Mar 2004 17:43:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5ubb-0004hU-00 for idr@ietf.org; Tue, 23 Mar 2004 17:42:43 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1B5uak-0004d1-00 for idr@ietf.org; Tue, 23 Mar 2004 17:41:50 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i2NMcLbZ012648; Tue, 23 Mar 2004 17:38:21 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403232238.i2NMcLbZ012648@workhorse.fictitious.org> To: Pekka Savola cc: idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes (fwd) In-reply-to: Your message of "Tue, 23 Mar 2004 16:42:36 +0200." From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 17:38:20 -0500 In message , Pekka Savola w rites: > There were no follow-ups to this and the spec has entered IETF Last > Call. > > So, let me ask again; is there opposition for adding a clarification > like: > > If a route's (Rte1) next-hop (Rte2) or next-hop interface would > lead to packets being discarded by the same router, the route > (Rte1) SHOULD be considered unresolvable. > > or: > > When considering resolvable routes or referenced interfaces, > if packets through the route would be discarded by the router, > the route SHOULD be considered unresolvable. > > in 9.1.2.1, after the two points about the route resolvability > condition (as justified by below) ? There was plenty of response to your repeated messages on this topic. There is no need to change the BGP spec. If you want more details look at the long threads on list and the threads off list. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA14726 for ; Tue, 23 Mar 2004 17:39:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uY1-0007Pf-Vd; Tue, 23 Mar 2004 17:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uXc-0007Ok-GK for idr@optimus.ietf.org; Tue, 23 Mar 2004 17:38:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07656 for ; Tue, 23 Mar 2004 17:38:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uXZ-0004L6-00 for idr@ietf.org; Tue, 23 Mar 2004 17:38:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5uWf-0004Fz-00 for idr@ietf.org; Tue, 23 Mar 2004 17:37:38 -0500 Received: from entmail.gnilink.net ([199.45.47.10]) by ietf-mx with esmtp (Exim 4.12) id 1B5uVg-00048a-00 for idr@ietf.org; Tue, 23 Mar 2004 17:36:36 -0500 Received: by entmail.gnilink.net with Internet Mail Service (5.5.2656.59) id ; Tue, 23 Mar 2004 17:36:04 -0500 Message-ID: <94B9091E1149D411A45C00508BACEB35071A32DC@entmail.gnilink.net> From: "Martin, Christian" To: "'john smith'" , "'idr@ietf.org'" Subject: RE: [Idr] IBGP to replace IGP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 17:35:58 -0500 Smith, Comments inline, as I have been following this thread. >It would be great if you could share some more information on >the "issues" >of convergence time, CPU loads, and RP overloads. Convergence is typically nonlienearly proportionate to CPU load, and vice-versa, and they often feed off each other in a negative way. Network meltdowns are typically the result of routing loads disrupting topology maintenance mechanisms, thereby causing adjacency loss, which causes more routing load, which inhibits adjacency recreation, etc. I've seen networks stay in persistent "ditches" because the convergence-adjacency-divergence-adjaceny-...loop stayed closed due to loading. Not fun to have to rebuild all of your routers or reattach them to the network one by one... >From my understanding >a. it makes more sense to have 1 routing protocol as we dont >have multiple >daemons scheduled on the CPU. (which ofcourse is not a problem >but then so >is the point you mentioned below) In either case, BGP will consume the vast majority of CPU cycles. IGPs that are properly tuned in stable environments hardly tickle the CPU, let alone heat it up. Take LSA/P refresh out of the picture, and all the IGP does is send hellos and occasionally flood an LSA/P and compute an SPT once in a rare while. In the Internet, BGP is constantly processing updates and withdrawals, all day, every day. Sometimes, we see 100s of updates per minute, sometimes just a few, but they are always there. >b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we >inject 0.0.0.0/0 into IGP to make unknown prefixes go to the >nearest BGP >node.So does that help reduce the size of your routing table? Large SPs must run a full BGP load, at a minimum, to give routes to their customers. Unless you are talking about enterprise routing, we should avoid discussions of default routes... >c. The cases u mention of changes, I presume you mean >route-flaps. Well in >that case, we eitherways have issues when IGP flaps, we >eitherways wait for >IGP to converge for BGP to converge etc? (I am sure "real >traffic" operators >do that) Modern IGPs, properly tuned, converge way faster than BGP. BGP convergence is designed to be slow, so as not to place too much load on the global routing system. Since BGP carries so many routes, and since the topological density of the Internet Autonomous System graph increases every day, BGP can often take minutes to converge. IGPs take seconds, partly because they are usually lightweight. >d. We have the benefits of not having the "global view" dependent on 1 >protocol while the internal topology dependent on another This is actually a sound design. Think of the IGP as a topology discovery mechanism. All BGP routes have a next-hop. The goal of BGP is to take traffic to and from the "edges" of the network. Sometimes, the edge is within your network, like a server farm. IGPs are very good at discovering a topology and identifying the shortest path to each edge. BGP is not designed for this, and to make it do so requires considerable planning and lots of policy. >e. all i need to teach the network admins is BGP :) It is much easier to learn simple IS-IS and OSPF than BGP. Link State IGPs, when employed for topology discovery, are exceedingly simple (particularly IS-IS in a single area). BGP, on the otherhand, is a much bigger protocol that requires a lot of policy engineering in order for it to be effective. >f. Based on c, how would you say that it makes things more >complicated to >run iBGP only compared to IGP+0.0.0.0/0 (default originate and >originate >always) and all those things taken into consideration? Are you talking about running in an enterprise? Default routes will not work in any large environment for next-hop discovery of your iBGP peer IP's. Loops would abound... One of the problems with your proposal, and the primary reason this is not done, is that iBGP does not provide for transitive route dissemination in a network. All 'other' IGPs do this. This means your network topology must be highly symmetrical and/or fully meshed at layer 3 (at least in subsections) to allow for end-to-end route propagation. Unless you can employ lots of confeds (ie, each router in a confed subAS), lots of route-reflectors, or a full-mesh topology at layer 3 (and layer 2 if you consider multiaccess networks fully-meshed), then this approach is not possible. BGP also has race-condition mitigation rules that prevent a BGP route from being learned from a next-hop that is known via BGP, so injecting routes into BGP and hoping to bootstrap the next-hops would be problematic. This restriction is subtle and perhaps vendor specific, but usually, the next-hop is recursed through an IGP or connected interface. If this were possible, in any event, it would be slow-converging, as iBGP updates are typically spaced at 5 second intervals (depending on the event type). Also, you will have to peer with every interface on the device, thus forcing traffic to take certain paths that may not be the best path available, as most BGP attributes are non-accumulating (ie, u have to statically increase, say, local-pref via policy as routes propagate along a set of routers in your AS). The reality is that even if such an approach _were_ possible, the drawbacks are much more severe than simply turning on an IGP and having it discover your topology. Then, you may do what you with with iBGP. The best philosophy, IMO, is to place loopbacks and links in your IGP, and carry externals (either self-originated or from another AS) in your iBGP. Route-reflectors are useful if regionalized, as they make best path decisions before reflecting (so u want to be careful who peers with what to ensure path selection optimality). Confeds afford more control, TE, etc., but at what some claim to be a higher admin cost. Use them based on what you are trying to do. HTH, Chris >would be great if you could help clarify this. > >-Smith > > > > > >You could certainly run BGP and statics without another >protocol for the >IGP, but why would you want to? Convergence times, CPU load on >RPs, etc., >during changes would be rather unsatisfactory. If you want to run one >dynamic protocol at all costs, then what you describe below >will work, and >has worked for some, but people with real traffic don't waste >their time >with it. > > >Ben > >On Mar 15, 2004, at 8:24 PM, John Smith wrote: > > >Hi, > >I am very clear with the concept that IGPs cannot be used to carry the >entire BGP feed as >they cant be scaled to carry so many prefixes (even assuming >we add enough >TLVs to make >them carry the BGP attributes). > >What is not very clear to me is, why cant we use IBGP inside an AS to >completely do away >with IGPs. IGPs compute the best path to reach a particular >neighbor based >on the link >metric. This can be achieved in BGP also, if we include a TLV >to carry the >link cost. >Moreover, it is *mandatory* to run BGP on all the routers if we are >transiting traffic, >because if a router isnt speaking BGP then it cant forward BGP traffic. > >Cant we do away with IGPs (say in some small networks) and run >only IBGP >there? > >Any help/clues/pointers in this regard will be really appreciated. > >Regards, >Smith > >_________________________________________________________________ >Tired of spam? Get advanced junk mail protection with MSN 8. >http://join.msn.com/?page=features/junkmail > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA14647 for ; Tue, 23 Mar 2004 17:36:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uV8-0006kA-9E; Tue, 23 Mar 2004 17:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uUi-0006jF-4X for idr@optimus.ietf.org; Tue, 23 Mar 2004 17:35:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07537 for ; Tue, 23 Mar 2004 17:35:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uUf-00047m-00 for idr@ietf.org; Tue, 23 Mar 2004 17:35:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5uTk-000456-00 for idr@ietf.org; Tue, 23 Mar 2004 17:34:37 -0500 Received: from law9-f45.law9.hotmail.com ([64.4.9.45] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B5uTZ-00041y-00 for idr@ietf.org; Tue, 23 Mar 2004 17:34:26 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 23 Mar 2004 14:33:55 -0800 Received: from 64.38.138.134 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 23 Mar 2004 22:33:55 GMT X-Originating-IP: [64.38.138.134] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: ben@layer8.net Cc: idr@ietf.org Subject: Re: [Idr] IBGP to replace IGP Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Mar 2004 22:33:55.0800 (UTC) FILETIME=[ED20DD80:01C41126] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 22:33:55 +0000 Hi Ben, Thank you for your reply, > >a) scheduling is a minor concern. > I thought as much. CPU overload was something you mentioned. If you consider the point that OSPF carries only your IGP routes and BGP carries a lot more than that, the CPU overload problem will definately be there with BGP. But then assume we were to do away with BGP what would be the problem? would an IGP like OSPF be able to do a better job with the whole routing table? >b) certainly carrying a default helps reduce the size of the table, but >that is orthogonal to the question. it is not common practice to carry >much in the igp (meaning bgp is not redistributed into the igp), so >carrying a default really is reducing the size of your bgp ribs which is >something you can do regardless of whether you have a second protocol for >the igp. Exactly, so why add one more "protocol" to the network? What was wrong with just one? As you see, 2 can load the RP and the CPU and lead to convergence issues a lot more :) that one (but that apparently now is hardly a concern?) > >c) yes, flapping routes are a problem regardless of protocol, so you >generally want one that converges very quickly. a good link-state protocol >like ospf converges in seconds vs minutes for bgp in a reasonably complex >network. again, the igp is only carrying limited information (links and >loops being a very common scenario) and has very detailed knowledge of the >network (handling per-link metrics in bgp would get very ugly very fast) so >it can do things that are inconvenient or impossible with bgp. That is beause of the size of the routes handled by the protocol. What else do you think makes BGP slower? On the other hand, link state would have a lot more LSAs to compute the SPF against. So if my "intermediate" nodes did not have the complete table but I was to use 0.0.0.0/0 just like I do for OSPF (seems like thats what was your intended IGP) Would not BGP on the intermediate nodes (the part that was covering my IGP) converge equally fast? Incase you have a difference of opinion, please do tell me the reason. > >d) i don't know what benefits you mean. decoupling the churn of the >"global view" from the stability of your internal network supports using an >independent igp. which *may( work out if one was to use the same principals of IGP when using BGP as the IGP (0.0.0.0/0 to eBGP nodes etc?) > >e) if they can't understand ospf they shouldn't be touching the routers >anyway. > (Fine, I shall tell them that.) >f) i'm not suggesting the use of a default route. > I am considering that as a possibility. -Smith _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA13822 for ; Tue, 23 Mar 2004 16:16:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tFi-0007Oz-9D; Tue, 23 Mar 2004 16:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5cXD-0003qR-Lt for idr@optimus.ietf.org; Mon, 22 Mar 2004 22:24:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15203 for ; Mon, 22 Mar 2004 22:24:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5cXA-0005W9-00 for idr@ietf.org; Mon, 22 Mar 2004 22:24:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5cWC-0005OW-00 for idr@ietf.org; Mon, 22 Mar 2004 22:23:56 -0500 Received: from law9-f111.law9.hotmail.com ([64.4.9.111] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B5cVA-0005C2-00 for idr@ietf.org; Mon, 22 Mar 2004 22:22:52 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 22 Mar 2004 19:22:22 -0800 Received: from 64.38.138.134 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 23 Mar 2004 03:22:22 GMT X-Originating-IP: [64.38.138.134] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: idr@ietf.org Subject: Re: [Idr] IBGP to replace IGP Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Mar 2004 03:22:22.0522 (UTC) FILETIME=[0E5351A0:01C41086] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 03:22:22 +0000 Hi Ben, It would be great if you could share some more information on the "issues" of convergence time, CPU loads, and RP overloads. >From my understanding a. it makes more sense to have 1 routing protocol as we dont have multiple daemons scheduled on the CPU. (which ofcourse is not a problem but then so is the point you mentioned below) b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we inject 0.0.0.0/0 into IGP to make unknown prefixes go to the nearest BGP node.So does that help reduce the size of your routing table? c. The cases u mention of changes, I presume you mean route-flaps. Well in that case, we eitherways have issues when IGP flaps, we eitherways wait for IGP to converge for BGP to converge etc? (I am sure "real traffic" operators do that) d. We have the benefits of not having the "global view" dependent on 1 protocol while the internal topology dependent on another e. all i need to teach the network admins is BGP :) f. Based on c, how would you say that it makes things more complicated to run iBGP only compared to IGP+0.0.0.0/0 (default originate and originate always) and all those things taken into consideration? would be great if you could help clarify this. -Smith You could certainly run BGP and statics without another protocol for the IGP, but why would you want to? Convergence times, CPU load on RPs, etc., during changes would be rather unsatisfactory. If you want to run one dynamic protocol at all costs, then what you describe below will work, and has worked for some, but people with real traffic don't waste their time with it. Ben On Mar 15, 2004, at 8:24 PM, John Smith wrote: Hi, I am very clear with the concept that IGPs cannot be used to carry the entire BGP feed as they cant be scaled to carry so many prefixes (even assuming we add enough TLVs to make them carry the BGP attributes). What is not very clear to me is, why cant we use IBGP inside an AS to completely do away with IGPs. IGPs compute the best path to reach a particular neighbor based on the link metric. This can be achieved in BGP also, if we include a TLV to carry the link cost. Moreover, it is *mandatory* to run BGP on all the routers if we are transiting traffic, because if a router isnt speaking BGP then it cant forward BGP traffic. Cant we do away with IGPs (say in some small networks) and run only IBGP there? Any help/clues/pointers in this regard will be really appreciated. Regards, Smith _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA10651 for ; Tue, 23 Mar 2004 11:37:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oti-0005rJ-71; Tue, 23 Mar 2004 11:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oq9-0005ir-K9 for idr@optimus.ietf.org; Tue, 23 Mar 2004 11:33:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08722 for ; Tue, 23 Mar 2004 11:33:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5oq8-0004W0-00 for idr@ietf.org; Tue, 23 Mar 2004 11:33:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5opO-0004TQ-00 for idr@ietf.org; Tue, 23 Mar 2004 11:32:35 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1B5ooT-0004Rl-00 for idr@ietf.org; Tue, 23 Mar 2004 11:31:38 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id BEDFC2D1B28; Tue, 23 Mar 2004 08:31:34 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27617-02; Tue, 23 Mar 2004 08:31:34 -0800 (PST) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id E3A892D1B26; Tue, 23 Mar 2004 08:31:33 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv1.redback.com (Postfix) with ESMTP id 5E6AB15D3C2; Tue, 23 Mar 2004 08:31:33 -0800 (PST) To: Pekka Savola Cc: idr@ietf.org, enke@redback.com Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes (fwd) In-Reply-To: Message from Pekka Savola of "Tue, 23 Mar 2004 16:42:36 +0200." From: Enke Chen Message-Id: <20040323163133.5E6AB15D3C2@popserv1.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 08:31:32 -0800 Hi, Pekka: Your proposed text does not reflect the deployed code, and prohibits certain practice in use. So I do not seem it is appropriate for the base spec.. -- Enke > From: Pekka Savola > To: idr@ietf.org > Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 > routes (fwd) > Message-ID: > > There were no follow-ups to this and the spec has entered IETF Last > Call. > > So, let me ask again; is there opposition for adding a clarification > like: > > If a route's (Rte1) next-hop (Rte2) or next-hop interface would > lead to packets being discarded by the same router, the route > (Rte1) SHOULD be considered unresolvable. > > or: > > When considering resolvable routes or referenced interfaces, > if packets through the route would be discarded by the router, > the route SHOULD be considered unresolvable. > > in 9.1.2.1, after the two points about the route resolvability > condition (as justified by below) ? > > ---------- Forwarded message ---------- > Date: Sat, 13 Mar 2004 09:57:15 +0200 (EET) > From: Pekka Savola > To: idr@ietf.org > Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 > routes > > On Fri, 12 Mar 2004, Jeffrey Haas wrote: > > On Fri, Mar 12, 2004 at 04:55:04AM -0500, Curtis Villamizar wrote: > > > I think the best way to handle this (from the standards standpoint) is > > > to write a separate draft. The draft would provide a better "BGP next > > > hop resolvable test" but does not match any current implementation so > > > it does not belong in the BGP spec. If changes are made to any > > > implementations they would remain fully interoperable with those that > > > go by the letter of the spec without any "better resolvable test". > > > > I would agree with Curtis. This is an operational/deployment issue > > and a draft covering such issues - and not just this one - may > > be a Good Thing. > > There was already an off-list discussion about this, but I think I > should clarify the issue here: > > The local router knows that route R2 is a discard/null0 route, and > the nexthop of route R1 goes through R2 after the more specific > route has been withdrawn from IGP. Route R1 is considered valid > even though the router knows it goes through a discard route. > > Many consider this an implementation bug; some have already said > they'd fix this, so the argument "there is no implementation" does not > hold. > > What I want is that this gets fixed in the spec, because the spec can > be read both ways. I want to avoid "local optimizations" by > implementations, and fix this in the specification. It would be > irresponsible to have purposely ambiguous specifications. > > One possible way to fix this could be, in 9.1.2.1: > > ---- > The route resolvability condition is defined as follows. > > 1. A route Rte1, referencing only the intermediate network > address, is considered resolvable if the Routing Table contains at > least one resolvable route Rte2 that matches Rte1's intermediate > network address and is not recursively resolved (directly or indi- > rectly) through Rte1. If multiple matching routes are available, > only the longest matching route SHOULD be considered. > > 2. Routes referencing interfaces (with or without intermediate > addresses) are considered resolvable if the state of the refer- > enced interface is up and IP processing is enabled on this inter- > face. > ---- > > Add a clarifying paragraph afterwards: > > If a route's (Rte1) next-hop (Rte2) or next-hop interface would > lead to packets being discarded by the same router, the route > (Rte1) SHOULD be considered unresolvable. > > or: > > When considering resolvable routes or referenced interfaces, > if packets through the route would be discarded by the router, > the route SHOULD be considered unresolvable. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA09368 for ; Tue, 23 Mar 2004 10:11:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5nX3-0000tb-7O; Tue, 23 Mar 2004 10:09:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5nRx-0007eS-41 for idr@optimus.ietf.org; Tue, 23 Mar 2004 10:04:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00771 for ; Tue, 23 Mar 2004 10:04:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5nRv-0006Ur-00 for idr@ietf.org; Tue, 23 Mar 2004 10:04:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5nR9-0006N8-00 for idr@ietf.org; Tue, 23 Mar 2004 10:03:28 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B5nQF-0006A1-00 for idr@ietf.org; Tue, 23 Mar 2004 10:02:31 -0500 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2NF1vaD007033 for ; Tue, 23 Mar 2004 07:01:58 -0800 (PST) Received: from [64.101.214.212] (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA15172 for ; Tue, 23 Mar 2004 10:01:56 -0500 (EST) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: To: idr@ietf.org From: "John G. Scudder" Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes (fwd) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 10:01:57 -0500 I'd object to either of those since they would have the effect of forbidding certain DoS mitigation techniques, as we've already discussed. Either option is not a clarification, but a spec change. --John At 4:42 PM +0200 3/23/04, Pekka Savola wrote: >There were no follow-ups to this and the spec has entered IETF Last >Call. > >So, let me ask again; is there opposition for adding a clarification >like: > > If a route's (Rte1) next-hop (Rte2) or next-hop interface would > lead to packets being discarded by the same router, the route > (Rte1) SHOULD be considered unresolvable. > >or: > > When considering resolvable routes or referenced interfaces, > if packets through the route would be discarded by the router, > the route SHOULD be considered unresolvable. > >in 9.1.2.1, after the two points about the route resolvability >condition (as justified by below) ? ... _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA08996 for ; Tue, 23 Mar 2004 09:47:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5nBG-0003td-6f; Tue, 23 Mar 2004 09:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5n8w-0003iZ-PD for idr@optimus.ietf.org; Tue, 23 Mar 2004 09:44:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29833 for ; Tue, 23 Mar 2004 09:44:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5n8u-0003qd-00 for idr@ietf.org; Tue, 23 Mar 2004 09:44:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5n8M-0003ik-00 for idr@ietf.org; Tue, 23 Mar 2004 09:44:03 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5n7V-0003SU-00 for idr@ietf.org; Tue, 23 Mar 2004 09:43:09 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2NEgaw06545 for ; Tue, 23 Mar 2004 16:42:36 +0200 From: Pekka Savola To: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 16:42:36 +0200 (EET) There were no follow-ups to this and the spec has entered IETF Last Call. So, let me ask again; is there opposition for adding a clarification like: If a route's (Rte1) next-hop (Rte2) or next-hop interface would lead to packets being discarded by the same router, the route (Rte1) SHOULD be considered unresolvable. or: When considering resolvable routes or referenced interfaces, if packets through the route would be discarded by the router, the route SHOULD be considered unresolvable. in 9.1.2.1, after the two points about the route resolvability condition (as justified by below) ? ---------- Forwarded message ---------- Date: Sat, 13 Mar 2004 09:57:15 +0200 (EET) From: Pekka Savola To: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes On Fri, 12 Mar 2004, Jeffrey Haas wrote: > On Fri, Mar 12, 2004 at 04:55:04AM -0500, Curtis Villamizar wrote: > > I think the best way to handle this (from the standards standpoint) is > > to write a separate draft. The draft would provide a better "BGP next > > hop resolvable test" but does not match any current implementation so > > it does not belong in the BGP spec. If changes are made to any > > implementations they would remain fully interoperable with those that > > go by the letter of the spec without any "better resolvable test". > > I would agree with Curtis. This is an operational/deployment issue > and a draft covering such issues - and not just this one - may > be a Good Thing. There was already an off-list discussion about this, but I think I should clarify the issue here: The local router knows that route R2 is a discard/null0 route, and the nexthop of route R1 goes through R2 after the more specific route has been withdrawn from IGP. Route R1 is considered valid even though the router knows it goes through a discard route. Many consider this an implementation bug; some have already said they'd fix this, so the argument "there is no implementation" does not hold. What I want is that this gets fixed in the spec, because the spec can be read both ways. I want to avoid "local optimizations" by implementations, and fix this in the specification. It would be irresponsible to have purposely ambiguous specifications. One possible way to fix this could be, in 9.1.2.1: ---- The route resolvability condition is defined as follows. 1. A route Rte1, referencing only the intermediate network address, is considered resolvable if the Routing Table contains at least one resolvable route Rte2 that matches Rte1's intermediate network address and is not recursively resolved (directly or indi- rectly) through Rte1. If multiple matching routes are available, only the longest matching route SHOULD be considered. 2. Routes referencing interfaces (with or without intermediate addresses) are considered resolvable if the state of the refer- enced interface is up and IP processing is enabled on this inter- face. ---- Add a clarifying paragraph afterwards: If a route's (Rte1) next-hop (Rte2) or next-hop interface would lead to packets being discarded by the same router, the route (Rte1) SHOULD be considered unresolvable. or: When considering resolvable routes or referenced interfaces, if packets through the route would be discarded by the router, the route SHOULD be considered unresolvable. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA19842 for ; Mon, 22 Mar 2004 04:57:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBV-0002GL-3I; Mon, 22 Mar 2004 04:57:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dbP-00023S-RK for idr@optimus.ietf.org; Wed, 17 Mar 2004 11:09:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15364; Wed, 17 Mar 2004 11:09:02 -0500 (EST) Message-Id: <200403171609.LAA15364@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-gr-survey-01.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Mar 2004 11:09:02 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Graceful Restart - Implementation Survey Author(s) : J. Scudder Filename : draft-ietf-idr-bgp-gr-survey-01.txt Pages : 10 Date : 2004-3-12 This document provides a survey of BGP-4 Graceful Restart implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-gr-survey-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-gr-survey-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-gr-survey-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-17113209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-gr-survey-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-gr-survey-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-17113209.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA19856 for ; Mon, 22 Mar 2004 04:57:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBK-00029x-79; Mon, 22 Mar 2004 04:57:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1tHZ-0006jE-J5 for idr@optimus.ietf.org; Fri, 12 Mar 2004 15:29:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17080; Fri, 12 Mar 2004 15:29:23 -0500 (EST) Message-Id: <200403122029.PAA17080@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-aspath-orf-06.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 15:29:23 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Aspath Based Outbound Route Filter for BGP-4 Author(s) : K. Patel, S. Hares Filename : draft-ietf-idr-aspath-orf-06.txt Pages : 0 Date : 2004-3-12 This document defines a new Outbound Router Filter type for BGP, termed 'Aspath Outbound Route Filter', that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-aspath-orf-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-aspath-orf-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-aspath-orf-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-12152611.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-aspath-orf-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-aspath-orf-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-12152611.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA19826 for ; Mon, 22 Mar 2004 04:57:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBL-0002AJ-Nv; Mon, 22 Mar 2004 04:57:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37nQ-0008Bo-Ov for idr@optimus.ietf.org; Tue, 16 Mar 2004 01:11:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28006 for ; Tue, 16 Mar 2004 01:11:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37nN-0005Ts-00 for idr@ietf.org; Tue, 16 Mar 2004 01:11:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B37mT-0005QA-00 for idr@ietf.org; Tue, 16 Mar 2004 01:10:26 -0500 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx with smtp (Exim 4.12) id 1B37lZ-0005Ix-00 for idr@ietf.org; Tue, 16 Mar 2004 01:09:29 -0500 Received: (qmail 84822 invoked from network); 16 Mar 2004 06:08:56 -0000 Received: from c-24-19-2-172.client.comcast.net (HELO ?192.168.0.107?) (ben@24.19.2.172) by layer8.net with SMTP; 16 Mar 2004 06:08:56 -0000 In-Reply-To: <20040316042412.36359.qmail@web25108.mail.ukl.yahoo.com> References: <20040316042412.36359.qmail@web25108.mail.ukl.yahoo.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <87D72DFF-7710-11D8-93D0-000A95DA7468@layer8.net> Content-Transfer-Encoding: 7bit Cc: idr@ietf.org From: Benjamin Black Subject: Re: [Idr] IBGP to replace IGP To: John Smith X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Mar 2004 22:09:48 -0800 You could certainly run BGP and statics without another protocol for the IGP, but why would you want to? Convergence times, CPU load on RPs, etc., during changes would be rather unsatisfactory. If you want to run one dynamic protocol at all costs, then what you describe below will work, and has worked for some, but people with real traffic don't waste their time with it. Ben On Mar 15, 2004, at 8:24 PM, John Smith wrote: > Hi, > > I am very clear with the concept that IGPs cannot be used to carry the > entire BGP feed as > they cant be scaled to carry so many prefixes (even assuming we add > enough TLVs to make > them carry the BGP attributes). > > What is not very clear to me is, why cant we use IBGP inside an AS to > completely do away > with IGPs. IGPs compute the best path to reach a particular neighbor > based on the link > metric. This can be achieved in BGP also, if we include a TLV to carry > the link cost. > Moreover, it is *mandatory* to run BGP on all the routers if we are > transiting traffic, > because if a router isnt speaking BGP then it cant forward BGP traffic. > > Cant we do away with IGPs (say in some small networks) and run only > IBGP there? > > Any help/clues/pointers in this regard will be really appreciated. > > Regards, > Smith > > > > > > > ___________________________________________________________ > Yahoo! Messenger - Communicate instantly..."Ping" > your friends today! Download Messenger Now > http://uk.messenger.yahoo.com/download/index.html > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA19843 for ; Mon, 22 Mar 2004 04:57:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBT-0002En-Ec; Mon, 22 Mar 2004 04:57:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3M8J-0004kH-8o for idr@optimus.ietf.org; Tue, 16 Mar 2004 16:29:55 -0500 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26447 for ; Tue, 16 Mar 2004 16:29:52 -0500 (EST) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1B3M7o-0004hU-Uk; Tue, 16 Mar 2004 16:29:24 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: idr@ietf.org;rtg-dir@ietf.org;; From: The IESG Reply-to: iesg@ietf.org Message-Id: Subject: [Idr] Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 16:29:24 -0500 The IESG has received a request from the Inter-Domain Routing WG to consider the following set of documents updating the Border Gateway Protocol 4 specification. BGP4 protocol-related documents: - 'A Border Gateway Protocol 4 (BGP-4) ' as a Draft Standard - 'BGP Security Vulnerabilities Analysis ' as an Informational RFC - 'BGP-4 Protocol Analysis ' as an Informational RFC - 'Experience with the BGP-4 Protocol ' as an Informational RFC BGP4 MIB-related documents: - 'Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4) ' as a Proposed Standard Implementation reports: - 'BGP 4 Implementation Report ' as an Informational RFC - 'BGP MIB V1 implementation survey ' as an Informational RFC The documents above satisfy the standardization criteria for Routing Protocols described in RFC 1264. Since draft-ietf-idr-bgp4-23.txt specifies the TCP MD5 Signature Option (RFC 2385), which is a Proposed Standard, as the mandatory to implement authentication mechanism, the IESG is planning to apply the variance procedure per RFC 2026 to allow the BGP4 protocol specification at the Draft Standard level to have a normative reference to RFC 2385. The variance prodedure request is documented in the following document: - 'Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-04-13. The files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-23.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-vuln-00.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-analysis-04.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol- 03.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-13.txt http://www.ietf.org/internet-drafts/draft-iesg-tcpmd5app-00.txt Implementation Reports can be accessed at http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-implementation-00.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-mibagent-survey-00.tx _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA19809 for ; Mon, 22 Mar 2004 04:57:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBL-0002A6-0n; Mon, 22 Mar 2004 04:57:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1tHg-0006jL-AT for idr@optimus.ietf.org; Fri, 12 Mar 2004 15:29:32 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17097; Fri, 12 Mar 2004 15:29:30 -0500 (EST) Message-Id: <200403122029.PAA17097@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-gr-survey-01.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 15:29:29 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Graceful Restart - Implementation Survey Author(s) : J. Scudder Filename : draft-ietf-idr-bgp-gr-survey-01.txt Pages : 10 Date : 2004-3-12 This document provides a survey of BGP-4 Graceful Restart implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-gr-survey-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-gr-survey-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-gr-survey-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-12152622.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-gr-survey-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-gr-survey-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-12152622.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA19827 for ; Mon, 22 Mar 2004 04:57:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBP-0002Ak-OU; Mon, 22 Mar 2004 04:57:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Lfn-0002YY-TJ for idr@optimus.ietf.org; Tue, 16 Mar 2004 16:00:27 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24350; Tue, 16 Mar 2004 16:00:24 -0500 (EST) Message-Id: <200403162100.QAA24350@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-rfc2858bis-04.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 16:00:24 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Multiprotocol Extensions for BGP-4 Author(s) : T. Bates, R. Chandra, D. Katz, Y. Rekhter Filename : draft-ietf-idr-rfc2858bis-04.txt Pages : 11 Date : 2004-3-16 Currently BGP-4 is capable of carrying routing information only for IPv4. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-rfc2858bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-rfc2858bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-16162447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc2858bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc2858bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-16162447.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA19822 for ; Mon, 22 Mar 2004 04:57:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBU-0002FZ-7g; Mon, 22 Mar 2004 04:57:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3db9-00022t-0V for idr@optimus.ietf.org; Wed, 17 Mar 2004 11:08:51 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15348; Wed, 17 Mar 2004 11:08:46 -0500 (EST) Message-Id: <200403171608.LAA15348@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-aspath-orf-06.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Mar 2004 11:08:46 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Aspath Based Outbound Route Filter for BGP-4 Author(s) : K. Patel, S. Hares Filename : draft-ietf-idr-aspath-orf-06.txt Pages : 0 Date : 2004-3-12 This document defines a new Outbound Router Filter type for BGP, termed 'Aspath Outbound Route Filter', that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-aspath-orf-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-aspath-orf-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-aspath-orf-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-17113158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-aspath-orf-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-aspath-orf-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-17113158.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA19811 for ; Mon, 22 Mar 2004 04:57:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBO-0002Ac-Un; Mon, 22 Mar 2004 04:57:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Lfi-0002YR-NK for idr@optimus.ietf.org; Tue, 16 Mar 2004 16:00:22 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24333; Tue, 16 Mar 2004 16:00:19 -0500 (EST) Message-Id: <200403162100.QAA24333@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-as4bytes-08.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 16:00:19 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP support for four-octet AS number space Author(s) : Q. Vohra, E. Chen Filename : draft-ietf-idr-as4bytes-08.txt Pages : 7 Date : 2004-3-16 Currently the Autonomous System number is encoded in BGP [BGP] as a two-octets field. This document describes extensions to BGP to carry the Autonomous System number as a four-octets field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-as4bytes-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-as4bytes-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-16162437.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-as4bytes-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-as4bytes-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-16162437.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA19804 for ; Mon, 22 Mar 2004 04:57:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MBJ-00029n-Io; Mon, 22 Mar 2004 04:57:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1r4L-00031S-7Q for idr@optimus.ietf.org; Fri, 12 Mar 2004 13:07:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08510 for ; Fri, 12 Mar 2004 13:07:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1r4J-0005FF-00 for idr@ietf.org; Fri, 12 Mar 2004 13:07:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1r3K-00057X-00 for idr@ietf.org; Fri, 12 Mar 2004 13:06:35 -0500 Received: from layer8.net ([147.28.0.15] helo=elf.layer8.net) by ietf-mx with smtp (Exim 4.12) id 1B1r2K-0004uQ-00 for idr@ietf.org; Fri, 12 Mar 2004 13:05:32 -0500 Received: (qmail 14604 invoked from network); 12 Mar 2004 18:04:57 -0000 Received: from 207-171-180-101.amazon.com (HELO ?10.21.134.173?) (ben@207.171.180.101) by layer8.net with SMTP; 12 Mar 2004 18:04:57 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: idr@ietf.org From: Benjamin Black Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes To: Pekka Savola X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 10:05:44 -0800 Which one of your options leads to "this isn't something that concerns BGP"? Ben On Mar 12, 2004, at 1:13 AM, Pekka Savola wrote: > Hello, it's me again :).. > > Now that the on-list thread has apparently died, and the off-list > discussions as well, I think it would be important to understand how > to move forward, and to try to gauge whether everyone is aware of > which issue we're talking about. > > As there was a lot of confusion at first on the actual problem, I > won't try to summarize the thread, because at different times, people > probably had entirely different assumptions of the problem. > > The bottom line is this: in very many cases you cannot avoid having to > insert some some kind of discard/reject or null0 route for a specific > prefix on a router (e.g., to generate a default route to some peers). > When the next-hop of some other router, on that *same* router, goes > through that "discard" route, the next-hop is still considered valid. > This causes rather obvious BGP timeout problems. > > The non-problem is when you have to redistribute that discard route in > your routing system, whether in IGP or BGP, and the other routers > cannot tell that's it's a discard route as it's learned through a > routing protocol. This can be rather easily avoided by configuring > the discard routes everywhere, so I don't think this needs to be > solved at this point. > > Now.. what do people think about this problem -- what should we do > (pick one or multiple): > > 1) try to specify some behaviour in the bgp spec to avoid this issue; > for example: > 1.a) state that if the route towards the next-hop leads to packets > being discarded by the router, SHOULD consider the next-hop ineligible > 1.b) state that the implementation SHOULD support being able to > configure which routes to use in in the next-hop eligibility detection > process > 1.c) to be worked out later.. > 1.d) something else -- what? > > 2) defer the solution until later > > 3) clarify the operational problem, to make the reader/implementer > aware of it > 3.a) in this revision of bgp spec > 3.b) in some other documents(s) > > 4) other -- what ? > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA15761 for ; Fri, 19 Mar 2004 14:34:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Pkn-0000AN-Np; Fri, 19 Mar 2004 14:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Pk7-0008W9-5c for idr@optimus.ietf.org; Fri, 19 Mar 2004 14:33:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17503 for ; Fri, 19 Mar 2004 14:33:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Pk4-0000hK-00 for idr@ietf.org; Fri, 19 Mar 2004 14:33:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Pj5-0000Z8-00 for idr@ietf.org; Fri, 19 Mar 2004 14:32:15 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B4Pi7-0000QS-00; Fri, 19 Mar 2004 14:31:16 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4Phx-000PyS-Ar; Fri, 19 Mar 2004 19:31:05 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <139156231539.20040319113030@psg.com> To: idr@ietf.org, rtg-dir@ietf.org, ops-dir@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Mar 2004 11:30:30 -0800 Folks- Below is the IETF LC announcement that should have made it to several lists and hasn't yet http://www1.ietf.org/mail-archive/ietf-announce/Current/msg29135.html -- Alex http://www.psg.com/~zinin/ > * To: IETF-Announce :; > * Subject: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard > * From: The IESG > * Date: Tue, 16 Mar 2004 16:29:24 -0500 > * Cc: idr at ietf.org;rtg-dir at ietf.org; > * Reply-to: iesg at ietf.org > * Sender: owner-ietf-announce at ietf.org > > The IESG has received a request from the Inter-Domain Routing WG to consider > the following set of documents updating the Border Gateway Protocol 4 > specification. > > BGP4 protocol-related documents: > > - 'A Border Gateway Protocol 4 (BGP-4) ' > as a Draft Standard > - 'BGP Security Vulnerabilities Analysis ' > as an Informational RFC > - 'BGP-4 Protocol Analysis ' > as an Informational RFC > - 'Experience with the BGP-4 Protocol ' > as an Informational RFC > > BGP4 MIB-related documents: > > - 'Definitions of Managed Objects for the Fourth Version of Border Gateway > Protocol (BGP-4) ' > as a Proposed Standard > > Implementation reports: > > - 'BGP 4 Implementation Report ' > as an Informational RFC > - 'BGP MIB V1 implementation survey ' > as an Informational RFC > > The documents above satisfy the standardization criteria for Routing > Protocols described in RFC 1264. > > Since draft-ietf-idr-bgp4-23.txt specifies the TCP MD5 Signature Option (RFC > 2385), which is a Proposed Standard, as the mandatory to implement > authentication mechanism, the IESG is planning to apply the variance > procedure per RFC 2026 to allow the BGP4 protocol specification at the Draft > Standard level to have a normative reference to RFC 2385. The variance > prodedure request is documented in the following document: > > - 'Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC > 2385) and the BGP-4 Specification ' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2004-04-13. > > The files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-23.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-vuln-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-analysis-04.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol- > 03.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-13.txt > http://www.ietf.org/internet-drafts/draft-iesg-tcpmd5app-00.txt > > Implementation Reports can be accessed at > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-implementation-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-mibagent-survey-00.tx _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA28789 for ; Thu, 18 Mar 2004 13:26:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B42D8-0007md-8i; Thu, 18 Mar 2004 13:25:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B42C7-0007kO-MC for idr@optimus.ietf.org; Thu, 18 Mar 2004 13:24:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29021 for ; Thu, 18 Mar 2004 13:24:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B42C4-000174-00 for idr@ietf.org; Thu, 18 Mar 2004 13:24:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B42BE-00014h-00 for idr@ietf.org; Thu, 18 Mar 2004 13:23:44 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1B42AZ-00011C-00 for idr@ietf.org; Thu, 18 Mar 2004 13:23:03 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i2IIKdbZ060237; Thu, 18 Mar 2004 13:20:39 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403181820.i2IIKdbZ060237@workhorse.fictitious.org> To: Hunju Park cc: idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] BGP Marker in the Header In-reply-to: Your message of "Thu, 18 Mar 2004 06:26:33 EST." <20040318112633.15547.qmail@web21005.mail.yahoo.com> From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 13:20:38 -0500 In message <20040318112633.15547.qmail@web21005.mail.yahoo.com>, Hunju Park wri tes: > Hi, > What is the need for the BGP Marker (16 bytes) containing all FFs. It is said > that it was used at > times for security but i dont think its valid anymore. If anybody wants secur > ity then he can use > TCP-MD5. > > Any clues, > Park > > P.S. > I went through the IDR archives before posting this and couldnt find any expl > anation for this! > Infact,this question was raised a long time back, but nobody answered this. It is used to detect a horrible bug in either the sending or receiving implementation in which packet alignment has been lost. Those sort of bugs are much less common that they were a decade or more ago, but it might not hurt to keep the check in place anyway. You can't tell what sort of code you will be BGP peering with, including someone's kludged together test or monitoring code. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA26434 for ; Thu, 18 Mar 2004 10:11:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zAn-0000nd-NJ; Thu, 18 Mar 2004 10:11:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zAF-0000e5-DL for idr@optimus.ietf.org; Thu, 18 Mar 2004 10:10:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16965 for ; Thu, 18 Mar 2004 10:10:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3zAD-00041T-00 for idr@ietf.org; Thu, 18 Mar 2004 10:10:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3z99-0003ki-00 for idr@ietf.org; Thu, 18 Mar 2004 10:09:24 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1B3z7m-0003H6-00 for idr@ietf.org; Thu, 18 Mar 2004 10:07:58 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i2IF7Pl26985 for ; Thu, 18 Mar 2004 10:07:25 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Mar 2004 10:07:26 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A88BA53@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: idr@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] FW: BGP MIB v1 Review Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 10:07:23 -0500 -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, March 17, 2004 3:25 PM To: 'Wijnen, Bert (Bert)' Cc: 'Susan Hares'; 'Jeffrey Haas' Subject: BGP MIB v1 Review hi I focused more of my energy into reviewing the delta from the previous version as appose to the older content. I figured we should focus our efforts on getting version 2 of the MIB correct. Issues ------ 1. Need to update copyright dates to 2004 2. In the description of bgpPeerIdentifier and bgpPeerNegotiatedVersion the "should" should be "MUST". 3. The second occurrences of 'should' in bgpPeerNegotiatedVersion is an interesting case as the value was never restricted in the initial version of the MIB, yet you are trying to define what a legal value is in the text. Clarifying where the 'legal' definition is coming from might be helpful. 4. The description for bgp4PathAttrAtomicAggregate is worrisome, but I suspect we are not actually changing the behaviour as drastically as it sounds. I am assuming that the NLRI stuff does not have anything to do with the MIB and this behaviour is described elsewhere. I would suggest rewording it to say: "This object indicates whether or not a system has selected a less specific route without selecting a more specific route. If the ATOMIC_AGGREGATE attribute is present in the Path Attributes then this object MUST have a value of 'lessSpecificRouteNotSelected'. If the ATOMIC_AGGREGATE attribute is missing in the Path Attributes then this object MUST have a value of 'lessSpecificRouteSelected'. Note that ATOMIC_AGGREGATE has been deprecated in the BGP specification." Note we should also add a REFERENCE clause to the BGP specification. 5. In the definitions of the Notifications, we should replace "This object deprecates " with "This Notification replaces the Notification." On the other end, replace "This object has been deprecated in favor of " with "This Notification has been replaced by the Notification. 6. There is a line "--- XXX TODO ..." within the reference section that looks like it should be removed or replaced with an RFC editor instruction. 7. There are no references in the text to RFC1901, RFC2574, RFC2576, RFC3411, RFC3413, RFC3415, RFC3416 or RFC3417 within the text. These need to be removed. Non-gating Issues ---------- 1. I'm assuming the fact that the behaviour of several counters has changed has been discussed and is considered acceptable. I'm personally not sure it is the right thing to do. 2. The text describing behaviour of bgpPeerHoldTimer and bgpPeerKeepAlive is rather passive. This should definitely changed in version 2 or the MIB, but is probable ok for this version. Example "If the value is zero (0), the Hold Timer has either not been established with the peer, or, the value of bgpPeerHoldTimeConfigured is zero (0)." versus " If the Hold Timer has not been established with the peer this object MUST have a value of (0). If the bgpPeerHoldTimeConfigured has a value of (0), then this object MUST have a value of (0)." Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA23250 for ; Thu, 18 Mar 2004 06:29:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vht-0004GU-UR; Thu, 18 Mar 2004 06:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vhI-0004G5-7r for idr@optimus.ietf.org; Thu, 18 Mar 2004 06:28:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03754 for ; Thu, 18 Mar 2004 06:28:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3vhE-0004LZ-00 for idr@ietf.org; Thu, 18 Mar 2004 06:28:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3vgG-0004Ee-00 for idr@ietf.org; Thu, 18 Mar 2004 06:27:21 -0500 Received: from web21005.mail.yahoo.com ([216.136.227.59]) by ietf-mx with smtp (Exim 4.12) id 1B3vfV-00047s-00 for idr@ietf.org; Thu, 18 Mar 2004 06:26:33 -0500 Message-ID: <20040318112633.15547.qmail@web21005.mail.yahoo.com> Received: from [203.200.20.226] by web21005.mail.yahoo.com via HTTP; Thu, 18 Mar 2004 06:26:33 EST From: Hunju Park To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Idr] BGP Marker in the Header Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 06:26:33 -0500 (EST) Hi, What is the need for the BGP Marker (16 bytes) containing all FFs. It is said that it was used at times for security but i dont think its valid anymore. If anybody wants security then he can use TCP-MD5. Any clues, Park P.S. I went through the IDR archives before posting this and couldnt find any explanation for this! Infact,this question was raised a long time back, but nobody answered this. ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA24478 for ; Tue, 16 Mar 2004 01:02:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37eM-00071T-7d; Tue, 16 Mar 2004 01:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37dy-00070k-LW for idr@optimus.ietf.org; Tue, 16 Mar 2004 01:01:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27592 for ; Tue, 16 Mar 2004 01:01:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37dv-0004mG-00 for idr@ietf.org; Tue, 16 Mar 2004 01:01:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B37cx-0004i6-00 for idr@ietf.org; Tue, 16 Mar 2004 01:00:35 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37cK-0004c5-00 for idr@ietf.org; Tue, 16 Mar 2004 00:59:56 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2G5xOB14039; Tue, 16 Mar 2004 07:59:24 +0200 From: Pekka Savola To: =?iso-8859-1?q?John=20Smith?= cc: idr@ietf.org Subject: Re: [Idr] IBGP to replace IGP In-Reply-To: <20040316042412.36359.qmail@web25108.mail.ukl.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 07:59:24 +0200 (EET) On Tue, 16 Mar 2004, John Smith wrote: > Cant we do away with IGPs (say in some small networks) and run only IBGP there? How do you route point-to-point and loopback addresses if not with IGP? Using static routes? :) Otherwise, yes, IBGP has mostly replaced IGP especially wrt. external prefixes and that's a good thing. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA24462 for ; Tue, 16 Mar 2004 01:01:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37dN-0006u7-Ot; Tue, 16 Mar 2004 01:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37cz-0006tO-1S for idr@optimus.ietf.org; Tue, 16 Mar 2004 01:00:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27563 for ; Tue, 16 Mar 2004 01:00:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37cw-0004hr-00 for idr@ietf.org; Tue, 16 Mar 2004 01:00:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B37c2-0004dm-00 for idr@ietf.org; Tue, 16 Mar 2004 00:59:39 -0500 Received: from web25107.mail.ukl.yahoo.com ([217.12.10.55]) by ietf-mx with smtp (Exim 4.12) id 1B37bY-0004Zg-00 for idr@ietf.org; Tue, 16 Mar 2004 00:59:09 -0500 Message-ID: <20040316055839.18764.qmail@web25107.mail.ukl.yahoo.com> Received: from [203.200.20.226] by web25107.mail.ukl.yahoo.com via HTTP; Tue, 16 Mar 2004 05:58:39 GMT From: =?iso-8859-1?q?John=20Smith?= Subject: RE: [Idr] IBGP to replace IGP To: michel@arneill-py.sacramento.ca.us Cc: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 05:58:39 +0000 (GMT) Michel, > Where does this come from? I have configured transit networks with an > IGP (OSPF in my case, but some will prefer IS-IS) in the core and BGP at > the edge. What about this animal called NLRI? Say your edge BGP speaker (R1) learns 10.0.0.0/8 from some other EBGP router (NH1). It advertises the same to the other edge (R2) BGP router (which resides in the other corner of the same AS) with the NEXT_HOP NH1. Now you have IGPs running in the core so all the routers are aware of how they can reach NH1. When data traffic comes on the BGP router R2, it looks at its FIB and determines that it needs to forward the packet to one of your core routers in between the path to reach NH1. When the packet comes to that core router, there isnt any information about 10.0.0.0/8 on that router. How is then that packet forwarded. One can use default routes on the core IGP speaking routers, but that isnt a good solution and can easily lead to routing loops/black holes. Hope i made my case clear. Regards, Smith ___________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA24250 for ; Tue, 16 Mar 2004 00:47:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37Pp-00069b-3o; Tue, 16 Mar 2004 00:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37PI-000693-KJ for idr@optimus.ietf.org; Tue, 16 Mar 2004 00:46:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27121 for ; Tue, 16 Mar 2004 00:46:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37PF-0003lw-00 for idr@ietf.org; Tue, 16 Mar 2004 00:46:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B37OP-0003j3-00 for idr@ietf.org; Tue, 16 Mar 2004 00:45:34 -0500 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1B37Nu-0003fv-00 for idr@ietf.org; Tue, 16 Mar 2004 00:45:02 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Idr] IBGP to replace IGP X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: Thread-Topic: [Idr] IBGP to replace IGP Thread-Index: AcQLDvACp+BWjy6mS8K5VcYyQ713IwACe0zw From: "Michel Py" To: "John Smith" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Mar 2004 21:44:33 -0800 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id AAA24250 > John Smith wrote: > Moreover, it is *mandatory* to run BGP on all the routers > if we are transiting traffic, because if a router isn't > speaking BGP then it cant forward BGP traffic. Where does this come from? I have configured transit networks with an IGP (OSPF in my case, but some will prefer IS-IS) in the core and BGP at the edge. What about this animal called NLRI? Michel. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA23418 for ; Mon, 15 Mar 2004 23:27:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B36AO-00082t-VP; Mon, 15 Mar 2004 23:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B369u-00082A-3q for idr@optimus.ietf.org; Mon, 15 Mar 2004 23:26:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22234 for ; Mon, 15 Mar 2004 23:26:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B369s-0002wZ-00 for idr@ietf.org; Mon, 15 Mar 2004 23:26:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B368t-0002sz-00 for idr@ietf.org; Mon, 15 Mar 2004 23:25:28 -0500 Received: from web25108.mail.ukl.yahoo.com ([217.12.10.56]) by ietf-mx with smtp (Exim 4.12) id 1B3689-0002lr-00 for idr@ietf.org; Mon, 15 Mar 2004 23:24:41 -0500 Message-ID: <20040316042412.36359.qmail@web25108.mail.ukl.yahoo.com> Received: from [203.200.20.226] by web25108.mail.ukl.yahoo.com via HTTP; Tue, 16 Mar 2004 04:24:12 GMT From: =?iso-8859-1?q?John=20Smith?= To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Subject: [Idr] IBGP to replace IGP Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 04:24:12 +0000 (GMT) Hi, I am very clear with the concept that IGPs cannot be used to carry the entire BGP feed as they cant be scaled to carry so many prefixes (even assuming we add enough TLVs to make them carry the BGP attributes). What is not very clear to me is, why cant we use IBGP inside an AS to completely do away with IGPs. IGPs compute the best path to reach a particular neighbor based on the link metric. This can be achieved in BGP also, if we include a TLV to carry the link cost. Moreover, it is *mandatory* to run BGP on all the routers if we are transiting traffic, because if a router isnt speaking BGP then it cant forward BGP traffic. Cant we do away with IGPs (say in some small networks) and run only IBGP there? Any help/clues/pointers in this regard will be really appreciated. Regards, Smith ___________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA15756 for ; Mon, 15 Mar 2004 11:50:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2vHu-0004dp-Rv; Mon, 15 Mar 2004 11:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2vHo-0004d0-Rz for idr@optimus.ietf.org; Mon, 15 Mar 2004 11:49:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09512 for ; Mon, 15 Mar 2004 11:49:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2vHn-0003tw-00 for idr@ietf.org; Mon, 15 Mar 2004 11:49:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2vGp-0003lQ-00 for idr@ietf.org; Mon, 15 Mar 2004 11:48:56 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1B2vFp-0003YE-00 for idr@ietf.org; Mon, 15 Mar 2004 11:47:53 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i2FGlNl68963 for ; Mon, 15 Mar 2004 08:47:23 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i2FGlIJ54485 for ; Mon, 15 Mar 2004 08:47:18 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200403151647.i2FGlIJ54485@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <86685.1079369238.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] BGP Extended Communities implementation report Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Mar 2004 08:47:18 -0800 Folks, Those who participated in the BGP Extended Communities implementation report please let me know if you'd like me to make any updates. Those who did not participate in the report, but would like to be added to the report, please send me the info in a format similar to the one used in the report. The deadline is March 28, 2004. Yakov. ------- Forwarded Message Date: Thu, 11 Mar 2004 15:18:35 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-rekhter-ext-communities-survey-02.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP Extended Communities Attribute - Implementation S urvey Author(s) : Y. Rekhter Filename : draft-rekhter-ext-communities-survey-02.txt Pages : 13 Date : 2004-3-11 This document provides a survey of BGP-4 Extended Communities implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rekhter-ext-communities-survey-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rekhter-ext-communities-survey-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rekhter-ext-communities-survey-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-11142651.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rekhter-ext-communities-survey-02.txt - --OtherAccess Content-Type: Message/External-body; name="draft-rekhter-ext-communities-survey-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-11142651.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA10006 for ; Sat, 13 Mar 2004 03:00:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B243v-0003rg-5g; Sat, 13 Mar 2004 03:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B243C-0003q8-BG for idr@optimus.ietf.org; Sat, 13 Mar 2004 02:59:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03559 for ; Sat, 13 Mar 2004 02:59:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2438-00001Q-00 for idr@ietf.org; Sat, 13 Mar 2004 02:59:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B242H-0007lc-00 for idr@ietf.org; Sat, 13 Mar 2004 02:58:21 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B241m-0007gQ-00 for idr@ietf.org; Sat, 13 Mar 2004 02:57:50 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2D7vFd21750 for ; Sat, 13 Mar 2004 09:57:15 +0200 From: Pekka Savola To: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <20040312141318.C17845@nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 13 Mar 2004 09:57:15 +0200 (EET) On Fri, 12 Mar 2004, Jeffrey Haas wrote: > On Fri, Mar 12, 2004 at 04:55:04AM -0500, Curtis Villamizar wrote: > > I think the best way to handle this (from the standards standpoint) is > > to write a separate draft. The draft would provide a better "BGP next > > hop resolvable test" but does not match any current implementation so > > it does not belong in the BGP spec. If changes are made to any > > implementations they would remain fully interoperable with those that > > go by the letter of the spec without any "better resolvable test". > > I would agree with Curtis. This is an operational/deployment issue > and a draft covering such issues - and not just this one - may > be a Good Thing. There was already an off-list discussion about this, but I think I should clarify the issue here: The local router knows that route R2 is a discard/null0 route, and the nexthop of route R1 goes through R2 after the more specific route has been withdrawn from IGP. Route R1 is considered valid even though the router knows it goes through a discard route. Many consider this an implementation bug; some have already said they'd fix this, so the argument "there is no implementation" does not hold. What I want is that this gets fixed in the spec, because the spec can be read both ways. I want to avoid "local optimizations" by implementations, and fix this in the specification. It would be irresponsible to have purposely ambiguous specifications. One possible way to fix this could be, in 9.1.2.1: ---- The route resolvability condition is defined as follows. 1. A route Rte1, referencing only the intermediate network address, is considered resolvable if the Routing Table contains at least one resolvable route Rte2 that matches Rte1's intermediate network address and is not recursively resolved (directly or indi- rectly) through Rte1. If multiple matching routes are available, only the longest matching route SHOULD be considered. 2. Routes referencing interfaces (with or without intermediate addresses) are considered resolvable if the state of the refer- enced interface is up and IP processing is enabled on this inter- face. ---- Add a clarifying paragraph afterwards: If a route's (Rte1) next-hop (Rte2) or next-hop interface would lead to packets being discarded by the same router, the route (Rte1) SHOULD be considered unresolvable. or: When considering resolvable routes or referenced interfaces, if packets through the route would be discarded by the router, the route SHOULD be considered unresolvable. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA01495 for ; Fri, 12 Mar 2004 14:16:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1s8a-0001Ge-4P; Fri, 12 Mar 2004 14:16:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1s8S-0001F9-C2 for idr@optimus.ietf.org; Fri, 12 Mar 2004 14:15:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11937 for ; Fri, 12 Mar 2004 14:15:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1s8P-0006Jn-00 for idr@ietf.org; Fri, 12 Mar 2004 14:15:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1s7l-0006Ay-00 for idr@ietf.org; Fri, 12 Mar 2004 14:15:14 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1B1s6r-0005xp-00 for idr@ietf.org; Fri, 12 Mar 2004 14:14:17 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 09E2A2D4889; Fri, 12 Mar 2004 14:13:47 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17404-01-36; Fri, 12 Mar 2004 14:13:45 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 4C5B92D4886; Fri, 12 Mar 2004 14:13:19 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i2CJDIl25240; Fri, 12 Mar 2004 14:13:18 -0500 (EST) From: Jeffrey Haas To: Curtis Villamizar Cc: Pekka Savola , idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes Message-ID: <20040312141318.C17845@nexthop.com> References: <200403120955.i2C9t4bZ076794@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200403120955.i2C9t4bZ076794@workhorse.fictitious.org>; from curtis@fictitious.org on Fri, Mar 12, 2004 at 04:55:04AM -0500 X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 14:13:18 -0500 On Fri, Mar 12, 2004 at 04:55:04AM -0500, Curtis Villamizar wrote: > I think the best way to handle this (from the standards standpoint) is > to write a separate draft. The draft would provide a better "BGP next > hop resolvable test" but does not match any current implementation so > it does not belong in the BGP spec. If changes are made to any > implementations they would remain fully interoperable with those that > go by the letter of the spec without any "better resolvable test". I would agree with Curtis. This is an operational/deployment issue and a draft covering such issues - and not just this one - may be a Good Thing. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA25814 for ; Fri, 12 Mar 2004 05:24:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jpi-0000bG-GE; Fri, 12 Mar 2004 05:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jp7-0000ZT-Vq for idr@optimus.ietf.org; Fri, 12 Mar 2004 05:23:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11886 for ; Fri, 12 Mar 2004 05:23:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jp4-0000tF-00 for idr@ietf.org; Fri, 12 Mar 2004 05:23:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1joB-0000mC-00 for idr@ietf.org; Fri, 12 Mar 2004 05:22:28 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jnJ-0000X3-00 for idr@ietf.org; Fri, 12 Mar 2004 05:21:33 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2CAKtH03846; Fri, 12 Mar 2004 12:20:55 +0200 From: Pekka Savola To: Robert Raszuk cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <40518C6B.6060308@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 12:20:55 +0200 (EET) On Fri, 12 Mar 2004, Robert Raszuk wrote: > So all you are asking here is faster next hop state detection and fast > route validatation. Very valid request, but again I fail to see why BGP > spec should mandate how fast one wishes to validate his next hops. All > major implementations I am aware about do it fast enough or allow one to > configure how fast you want to validate the next hops. No, the validation time (i.e., how often you check whether a nexthop has become ineligible) is not the point. The point is that the validation process, no matter how often or seldom is run, reports "valid!" for these routes which go through a discard next-hop. Rigging the timers changes nothing. > Btw .. bgp session timeout does not have to be only triggered by BGP > keepalives :) If you monitor some other work in the IETF BFD could be > one trigger, IGP another etc ... so it could be very fast indeed ;) FWIW, Multi-hop case is currently basically out of scope for BFD. But that's a separate topic. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA25744 for ; Fri, 12 Mar 2004 05:13:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jf4-0008R6-DQ; Fri, 12 Mar 2004 05:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jeO-0008QE-8z for idr@optimus.ietf.org; Fri, 12 Mar 2004 05:12:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11513 for ; Fri, 12 Mar 2004 05:12:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jeL-0007Ir-00 for idr@ietf.org; Fri, 12 Mar 2004 05:12:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jdP-0007CC-00 for idr@ietf.org; Fri, 12 Mar 2004 05:11:20 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B1jcT-0006yP-00 for idr@ietf.org; Fri, 12 Mar 2004 05:10:21 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Mar 2004 02:13:42 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2CA9nK2021790; Fri, 12 Mar 2004 02:09:50 -0800 (PST) Received: from cisco.com (sjc-vpn4-372.cisco.com [10.21.81.116]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARC74416; Fri, 12 Mar 2004 02:09:47 -0800 (PST) Message-ID: <40518C6B.6060308@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 02:09:47 -0800 Pekka, >> > When the next-hop of some other router, on that *same* router, goes >> > through that "discard" route, the next-hop is still considered valid. >> > This causes rather obvious BGP timeout problems. >> >>Well I would say that this is rather not so obvious to have next hops >>for the routes causing any BGP timeouts. I have not see anyone opening a >>BGP session or configuring update src to a null0 route. I am not even >>sure what you are trying to say above. > > > Sorry for bad wording. The intent was to say that when another router > fails, and the next-hop points to that router, if the next-hop is not > made ineligible, the routes going through that router will only be > removed when the BGP timeout expires... causing very long > unavailability. So all you are asking here is faster next hop state detection and fast route validatation. Very valid request, but again I fail to see why BGP spec should mandate how fast one wishes to validate his next hops. All major implementations I am aware about do it fast enough or allow one to configure how fast you want to validate the next hops. Anyhow you can for sure propose the text and min timers this should happen and send to the list for review. Btw .. bgp session timeout does not have to be only triggered by BGP keepalives :) If you monitor some other work in the IETF BFD could be one trigger, IGP another etc ... so it could be very fast indeed ;) Cheers, R. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA25606 for ; Fri, 12 Mar 2004 05:00:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jSV-0007l9-Ve; Fri, 12 Mar 2004 05:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jRn-0007k0-BK for idr@optimus.ietf.org; Fri, 12 Mar 2004 04:59:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11095 for ; Fri, 12 Mar 2004 04:59:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jRk-0005m9-00 for idr@ietf.org; Fri, 12 Mar 2004 04:59:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jQq-0005fO-00 for idr@ietf.org; Fri, 12 Mar 2004 04:58:21 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jPw-0005Rs-00 for idr@ietf.org; Fri, 12 Mar 2004 04:57:24 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2C9ukp03291; Fri, 12 Mar 2004 11:56:46 +0200 From: Pekka Savola To: Robert Raszuk cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <40518780.30702@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 11:56:46 +0200 (EET) On Fri, 12 Mar 2004, Robert Raszuk wrote: > > Now that the on-list thread has apparently died, and the off-list > > discussions as well, I think it would be important to understand how > > to move forward, and to try to gauge whether everyone is aware of > > which issue we're talking about. > > The problem did not died but was solved. The solution was that this is > implementation detail what next hops are used for route resolution as a > matter of the protocol owner as well as what mask length is desired. First, if it was decided that this is an implementation detail, it must IMHO be explicitly called out as such. Second, I disagree with this being an "implementation detail". This has significant operational implications, and the behaviour must be as consistent as possible. Dusting this off under the carpet doesn't seem to be reasonable. > > When the next-hop of some other router, on that *same* router, goes > > through that "discard" route, the next-hop is still considered valid. > > This causes rather obvious BGP timeout problems. > > Well I would say that this is rather not so obvious to have next hops > for the routes causing any BGP timeouts. I have not see anyone opening a > BGP session or configuring update src to a null0 route. I am not even > sure what you are trying to say above. Sorry for bad wording. The intent was to say that when another router fails, and the next-hop points to that router, if the next-hop is not made ineligible, the routes going through that router will only be removed when the BGP timeout expires... causing very long unavailability. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA25578 for ; Fri, 12 Mar 2004 04:58:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jQX-0007bw-Db; Fri, 12 Mar 2004 04:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jPw-0007bd-VB for idr@optimus.ietf.org; Fri, 12 Mar 2004 04:57:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11051 for ; Fri, 12 Mar 2004 04:57:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jPt-0005YF-00 for idr@ietf.org; Fri, 12 Mar 2004 04:57:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jOv-0005Rc-00 for idr@ietf.org; Fri, 12 Mar 2004 04:56:21 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1B1jOg-0005LB-00 for idr@ietf.org; Fri, 12 Mar 2004 04:56:07 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i2C9t4bZ076794; Fri, 12 Mar 2004 04:55:04 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403120955.i2C9t4bZ076794@workhorse.fictitious.org> To: Pekka Savola cc: idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: Your message of "Fri, 12 Mar 2004 11:13:31 +0200." From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 04:55:04 -0500 In message , Pekka Savola w rites: > Hello, it's me again :).. > > Now that the on-list thread has apparently died, and the off-list > discussions as well, I think it would be important to understand how > to move forward, and to try to gauge whether everyone is aware of > which issue we're talking about. > > As there was a lot of confusion at first on the actual problem, I > won't try to summarize the thread, because at different times, people > probably had entirely different assumptions of the problem. > > The bottom line is this: in very many cases you cannot avoid having to > insert some some kind of discard/reject or null0 route for a specific > prefix on a router (e.g., to generate a default route to some peers). > When the next-hop of some other router, on that *same* router, goes > through that "discard" route, the next-hop is still considered valid. > This causes rather obvious BGP timeout problems. > > The non-problem is when you have to redistribute that discard route in > your routing system, whether in IGP or BGP, and the other routers > cannot tell that's it's a discard route as it's learned through a > routing protocol. This can be rather easily avoided by configuring > the discard routes everywhere, so I don't think this needs to be > solved at this point. > > Now.. what do people think about this problem -- what should we do > (pick one or multiple): > > 1) try to specify some behaviour in the bgp spec to avoid this issue; > for example: > 1.a) state that if the route towards the next-hop leads to packets > being discarded by the router, SHOULD consider the next-hop ineligible > 1.b) state that the implementation SHOULD support being able to > configure which routes to use in in the next-hop eligibility detection > process > 1.c) to be worked out later.. > 1.d) something else -- what? > > 2) defer the solution until later > > 3) clarify the operational problem, to make the reader/implementer > aware of it > 3.a) in this revision of bgp spec > 3.b) in some other documents(s) > > 4) other -- what ? > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings In this ongoing discussion, we should be clear about what the consequence is. IBGP learned routes from a peer that has gone down do not get withdrawn on the IGP route withdraw due to the coverage of the next hop by an aggregate. Those IBGP learned routes are withdrawn after the BGP session times out which is rather a long time by today's standards. This is mostly a usage issue which arises when a provider's infrastructure is covered by an aggregate that is advertised within that provider's infrastructure. This problem is easily avoided, except in providers (or other BGP usage) where a default route is made available or where address space of the provider is taken from a larger aggregate of another provider. With some optional configuration a router can exclude routes from consideration in matching the BGP next-hop resolvable test. If the router does so, the provider doesn't need to work around the problem. I think the best way to handle this (from the standards standpoint) is to write a separate draft. The draft would provide a better "BGP next hop resolvable test" but does not match any current implementation so it does not belong in the BGP spec. If changes are made to any implementations they would remain fully interoperable with those that go by the letter of the spec without any "better resolvable test". Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA25487 for ; Fri, 12 Mar 2004 04:52:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jKm-0007Nk-4v; Fri, 12 Mar 2004 04:52:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jK5-0007NA-AM for idr@optimus.ietf.org; Fri, 12 Mar 2004 04:51:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10768 for ; Fri, 12 Mar 2004 04:51:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jK2-0004o4-00 for idr@ietf.org; Fri, 12 Mar 2004 04:51:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jJ4-0004g5-00 for idr@ietf.org; Fri, 12 Mar 2004 04:50:18 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B1jI9-0004RZ-00 for idr@ietf.org; Fri, 12 Mar 2004 04:49:22 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i2C9moWK004427; Fri, 12 Mar 2004 01:48:50 -0800 (PST) Received: from cisco.com (sjc-vpn4-372.cisco.com [10.21.81.116]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARC73878; Fri, 12 Mar 2004 01:48:48 -0800 (PST) Message-ID: <40518780.30702@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 01:48:48 -0800 Pekka, > Now that the on-list thread has apparently died, and the off-list > discussions as well, I think it would be important to understand how > to move forward, and to try to gauge whether everyone is aware of > which issue we're talking about. The problem did not died but was solved. The solution was that this is implementation detail what next hops are used for route resolution as a matter of the protocol owner as well as what mask length is desired. It was also clearly concluded by a few that BGP spec is not the place to add this and that you may rather issue a standalone draft describing operational implications on discard next hops and possibly recommend to implementations some new functionality. > When the next-hop of some other router, on that *same* router, goes > through that "discard" route, the next-hop is still considered valid. > This causes rather obvious BGP timeout problems. Well I would say that this is rather not so obvious to have next hops for the routes causing any BGP timeouts. I have not see anyone opening a BGP session or configuring update src to a null0 route. I am not even sure what you are trying to say above. Cheers, R. > Pekka Savola wrote: > > Hello, it's me again :).. > > Now that the on-list thread has apparently died, and the off-list > discussions as well, I think it would be important to understand how > to move forward, and to try to gauge whether everyone is aware of > which issue we're talking about. > > As there was a lot of confusion at first on the actual problem, I > won't try to summarize the thread, because at different times, people > probably had entirely different assumptions of the problem. > > The bottom line is this: in very many cases you cannot avoid having to > insert some some kind of discard/reject or null0 route for a specific > prefix on a router (e.g., to generate a default route to some peers). > When the next-hop of some other router, on that *same* router, goes > through that "discard" route, the next-hop is still considered valid. > This causes rather obvious BGP timeout problems. > > The non-problem is when you have to redistribute that discard route in > your routing system, whether in IGP or BGP, and the other routers > cannot tell that's it's a discard route as it's learned through a > routing protocol. This can be rather easily avoided by configuring > the discard routes everywhere, so I don't think this needs to be > solved at this point. > > Now.. what do people think about this problem -- what should we do > (pick one or multiple): > > 1) try to specify some behaviour in the bgp spec to avoid this issue; > for example: > 1.a) state that if the route towards the next-hop leads to packets > being discarded by the router, SHOULD consider the next-hop ineligible > 1.b) state that the implementation SHOULD support being able to > configure which routes to use in in the next-hop eligibility detection > process > 1.c) to be worked out later.. > 1.d) something else -- what? > > 2) defer the solution until later > > 3) clarify the operational problem, to make the reader/implementer > aware of it > 3.a) in this revision of bgp spec > 3.b) in some other documents(s) > > 4) other -- what ? > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA25093 for ; Fri, 12 Mar 2004 04:16:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ilu-0005gH-Tj; Fri, 12 Mar 2004 04:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ilL-0005ey-C1 for idr@optimus.ietf.org; Fri, 12 Mar 2004 04:15:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09633 for ; Fri, 12 Mar 2004 04:15:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1ilI-0000Sb-00 for idr@ietf.org; Fri, 12 Mar 2004 04:15:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1ikL-0000KJ-00 for idr@ietf.org; Fri, 12 Mar 2004 04:14:26 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1ijw-0000Bk-00 for idr@ietf.org; Fri, 12 Mar 2004 04:14:00 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2C9DVJ02659 for ; Fri, 12 Mar 2004 11:13:31 +0200 From: Pekka Savola To: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <200403021542.i22Fg3kL083856@workhorse.fictitious.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 11:13:31 +0200 (EET) Hello, it's me again :).. Now that the on-list thread has apparently died, and the off-list discussions as well, I think it would be important to understand how to move forward, and to try to gauge whether everyone is aware of which issue we're talking about. As there was a lot of confusion at first on the actual problem, I won't try to summarize the thread, because at different times, people probably had entirely different assumptions of the problem. The bottom line is this: in very many cases you cannot avoid having to insert some some kind of discard/reject or null0 route for a specific prefix on a router (e.g., to generate a default route to some peers). When the next-hop of some other router, on that *same* router, goes through that "discard" route, the next-hop is still considered valid. This causes rather obvious BGP timeout problems. The non-problem is when you have to redistribute that discard route in your routing system, whether in IGP or BGP, and the other routers cannot tell that's it's a discard route as it's learned through a routing protocol. This can be rather easily avoided by configuring the discard routes everywhere, so I don't think this needs to be solved at this point. Now.. what do people think about this problem -- what should we do (pick one or multiple): 1) try to specify some behaviour in the bgp spec to avoid this issue; for example: 1.a) state that if the route towards the next-hop leads to packets being discarded by the router, SHOULD consider the next-hop ineligible 1.b) state that the implementation SHOULD support being able to configure which routes to use in in the next-hop eligibility detection process 1.c) to be worked out later.. 1.d) something else -- what? 2) defer the solution until later 3) clarify the operational problem, to make the reader/implementer aware of it 3.a) in this revision of bgp spec 3.b) in some other documents(s) 4) other -- what ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA24770 for ; Fri, 12 Mar 2004 03:49:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1iLo-0003uY-80; Fri, 12 Mar 2004 03:49:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1WeO-0002Ac-SI for idr@optimus.ietf.org; Thu, 11 Mar 2004 15:19:28 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20077; Thu, 11 Mar 2004 15:19:26 -0500 (EST) Message-Id: <200403112019.PAA20077@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-implementation-00.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Mar 2004 15:19:26 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP 4 Implementation Report Author(s) : S. Hares Filename : draft-ietf-idr-bgp-implementation-00.txt Pages : 81 Date : 2004-3-11 This document provides a survey of the BGP-4 implementation draft- ietf-idr-bgp4-23.txt. After a brief summary, each response is listed. The editor makes no claim as to the accuracy of the information provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-implementation-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-implementation-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-implementation-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-11142831.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-implementation-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-implementation-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-11142831.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA09983 for ; Thu, 11 Mar 2004 05:26:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1NO9-0007gm-Ld; Thu, 11 Mar 2004 05:26:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1AWk-0004l7-53 for idr@optimus.ietf.org; Wed, 10 Mar 2004 15:42:06 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03167; Wed, 10 Mar 2004 15:42:04 -0500 (EST) Message-Id: <200403102042.PAA03167@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-route-filter-10.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 15:42:03 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Cooperative Route Filtering Capability for BGP-4 Author(s) : E. Chen, Y. Rekhter Filename : draft-ietf-idr-route-filter-10.txt Pages : 11 Date : 2004-3-10 This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of route filters that the peer would use to constrain/filter its outbound routing updates to the speaker. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-route-filter-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-route-filter-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-10150457.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-route-filter-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-route-filter-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-10150457.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA00943 for ; Wed, 10 Mar 2004 15:30:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1AL4-0003Kz-Ue; Wed, 10 Mar 2004 15:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1AKA-0003GM-Nt for idr@optimus.ietf.org; Wed, 10 Mar 2004 15:29:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02124 for ; Wed, 10 Mar 2004 15:29:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1AK9-0002g8-00 for idr@ietf.org; Wed, 10 Mar 2004 15:29:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1AJI-0002Vz-00 for idr@ietf.org; Wed, 10 Mar 2004 15:28:13 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1B1AIi-0002JJ-00 for idr@ietf.org; Wed, 10 Mar 2004 15:27:36 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i2AKR4124828 for ; Wed, 10 Mar 2004 15:27:05 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Mar 2004 15:27:05 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A7435E8@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: idr@ietf.org Cc: "Wijnen, Bert (Bert)" Subject: RE: [Idr] Experimental code-points MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 15:27:02 -0500 hi I'd prefer something more explicit, but I guess I can live with the current text. Sharon -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Wednesday, March 10, 2004 2:03 AM To: Wijnen, Bert (Bert) Cc: Chisholm, Sharon [CAR:0S00:EXCH]; idr@ietf.org Subject: Re: [Idr] Experimental code-points OK. Sharon, would this work for you? -- Alex http://www.psg.com/~zinin/ Tuesday, March 9, 2004, 6:54:03 PM, Wijnen, Bert (Bert) wrote: > Yes.... I wonder why I did not see that ?? > Maybve I was too tired at end of IETF week. > Thanks, > Bert >> -----Original Message----- >> From: Alex Zinin [mailto:zinin@psg.com] >> Sent: woensdag 10 maart 2004 7:45 >> To: Wijnen, Bert (Bert) >> Cc: Sharon Chisholm; idr@ietf.org >> Subject: Re: [Idr] Experimental code-points >> >> >> Bert, >> >> Seems that the text already has it: >> >> > a) The code points must be from a space designated as "Standards >> > Action", amended by IESG approval to permit Early Allocation. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> Does it do the job? >> >> -- >> Alex >> http://www.psg.com/~zinin/ >> >> Saturday, March 6, 2004, 5:01:34 AM, Wijnen, Bert (Bert) wrote: >> > Aha ... good. For me that Covers it. >> > But... it might be good to add that "IESG approval" >> > into the list of "conditions" in sect 2 as well. >> > I bet people will often skip the intro and go straight to >> > the "what are the conditions" section to see if they can >> > request an early registration. >> >> > Thanks, >> > Bert >> >> >> -----Original Message----- >> >> From: Alex Zinin [mailto:zinin@psg.com] >> >> Sent: woensdag 3 maart 2004 21:55 >> >> To: Wijnen, Bert (Bert) >> >> Cc: Sharon Chisholm; idr@ietf.org >> >> Subject: Re: [Idr] Experimental code-points >> >> >> >> >> >> Bert, Sharon- >> >> >> >> The doc says: >> >> >> >> > This memo only addresses the early allocation of code >> points from >> >> > spaces whose allocation policy is "Standards Action" >> >> [2434] AND have >> >> > been amended to permit early allocation. This >> permission must be >> >> > granted by the IESG, and code spaces with permission for early >> >> > allocation must be marked as such in the IANA registry. >> >> >> >> In other words, it doesn't apply to an existing registry >> >> unless IESG approves >> >> that this process is applicable. This leaves existing >> >> registries, OID included, >> >> intact unless someone takes an action. >> >> >> >> Is this good enough? >> >> >> >> -- >> >> Alex >> >> http://www.psg.com/~zinin/ >> >> >> >> Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote: >> >> > Good point. They can get an OID assigned in the >> >> experimental branch though. >> >> >> >> >> >> > Thanks, >> >> > Bert >> >> >> >> > -----Original Message----- >> >> > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] >> >> > Sent: dinsdag 2 maart 2004 9:30 >> >> > To: idr@ietf.org >> >> > Cc: Wijnen, Bert (Bert) >> >> > Subject: RE: [Idr] Experimental code-points >> >> >> >> >> >> >> >> > hi >> >> >> >> > In looking through >> >> > >> > > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocat > ion-00.txt > tion-00.txt> >>> I would suggest the following change to address my concern that it >>> inappropriately sets the expectation that MIB OIDs will be >>> pre-allocated. >>> In either the 'Introduction' or in the section 'Conditions for Early >>> Allocation' the following text needs to be added. >>> 'Note that under no condition will MIB Object Identifiers (OIDs) be >>> allocated before the RFC is published.' >>> Sharon >>> -----Original Message----- >>> From: Alex Zinin [ mailto:zinin@psg.com ] >>> Sent: Monday, March 01, 2004 3:11 AM >>> To: idr@ietf.org >>> Subject: [Idr] Experimental code-points >>> As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA21427 for ; Wed, 10 Mar 2004 02:06:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0xn1-0005l7-79; Wed, 10 Mar 2004 02:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0xmO-0005RU-Nv for idr@optimus.ietf.org; Wed, 10 Mar 2004 02:05:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29771 for ; Wed, 10 Mar 2004 02:05:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0xmL-0007TK-00 for idr@ietf.org; Wed, 10 Mar 2004 02:05:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0xlb-0007II-00 for idr@ietf.org; Wed, 10 Mar 2004 02:04:36 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B0xkZ-00073y-00 for idr@ietf.org; Wed, 10 Mar 2004 02:03:32 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0xkW-000GP3-4c; Wed, 10 Mar 2004 07:03:28 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <127268419917.20040309230252@psg.com> To: "Wijnen, Bert (Bert)" CC: Sharon Chisholm , idr@ietf.org Subject: Re: [Idr] Experimental code-points In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15503C9CF57@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15503C9CF57@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Mar 2004 23:02:52 -0800 OK. Sharon, would this work for you? -- Alex http://www.psg.com/~zinin/ Tuesday, March 9, 2004, 6:54:03 PM, Wijnen, Bert (Bert) wrote: > Yes.... I wonder why I did not see that ?? > Maybve I was too tired at end of IETF week. > Thanks, > Bert >> -----Original Message----- >> From: Alex Zinin [mailto:zinin@psg.com] >> Sent: woensdag 10 maart 2004 7:45 >> To: Wijnen, Bert (Bert) >> Cc: Sharon Chisholm; idr@ietf.org >> Subject: Re: [Idr] Experimental code-points >> >> >> Bert, >> >> Seems that the text already has it: >> >> > a) The code points must be from a space designated as "Standards >> > Action", amended by IESG approval to permit Early Allocation. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> Does it do the job? >> >> -- >> Alex >> http://www.psg.com/~zinin/ >> >> Saturday, March 6, 2004, 5:01:34 AM, Wijnen, Bert (Bert) wrote: >> > Aha ... good. For me that Covers it. >> > But... it might be good to add that "IESG approval" >> > into the list of "conditions" in sect 2 as well. >> > I bet people will often skip the intro and go straight to >> > the "what are the conditions" section to see if they can >> > request an early registration. >> >> > Thanks, >> > Bert >> >> >> -----Original Message----- >> >> From: Alex Zinin [mailto:zinin@psg.com] >> >> Sent: woensdag 3 maart 2004 21:55 >> >> To: Wijnen, Bert (Bert) >> >> Cc: Sharon Chisholm; idr@ietf.org >> >> Subject: Re: [Idr] Experimental code-points >> >> >> >> >> >> Bert, Sharon- >> >> >> >> The doc says: >> >> >> >> > This memo only addresses the early allocation of code >> points from >> >> > spaces whose allocation policy is "Standards Action" >> >> [2434] AND have >> >> > been amended to permit early allocation. This >> permission must be >> >> > granted by the IESG, and code spaces with permission for early >> >> > allocation must be marked as such in the IANA registry. >> >> >> >> In other words, it doesn't apply to an existing registry >> >> unless IESG approves >> >> that this process is applicable. This leaves existing >> >> registries, OID included, >> >> intact unless someone takes an action. >> >> >> >> Is this good enough? >> >> >> >> -- >> >> Alex >> >> http://www.psg.com/~zinin/ >> >> >> >> Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote: >> >> > Good point. They can get an OID assigned in the >> >> experimental branch though. >> >> >> >> >> >> > Thanks, >> >> > Bert >> >> >> >> > -----Original Message----- >> >> > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] >> >> > Sent: dinsdag 2 maart 2004 9:30 >> >> > To: idr@ietf.org >> >> > Cc: Wijnen, Bert (Bert) >> >> > Subject: RE: [Idr] Experimental code-points >> >> >> >> >> >> >> >> > hi >> >> >> >> > In looking through >> >> > >> > > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt >>> I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated. >>> In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. >>> 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' >>> Sharon >>> -----Original Message----- >>> From: Alex Zinin [ mailto:zinin@psg.com ] >>> Sent: Monday, March 01, 2004 3:11 AM >>> To: idr@ietf.org >>> Subject: [Idr] Experimental code-points >>> As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA15766 for ; Tue, 9 Mar 2004 18:48:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0qx7-0003Ml-PR; Tue, 09 Mar 2004 18:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0qwQ-0003Ku-VZ for idr@optimus.ietf.org; Tue, 09 Mar 2004 18:47:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07593 for ; Tue, 9 Mar 2004 18:47:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0qwN-0005Ph-00 for idr@ietf.org; Tue, 09 Mar 2004 18:47:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0qvf-0005Ee-00 for idr@ietf.org; Tue, 09 Mar 2004 18:46:32 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B0quf-00052g-00 for idr@ietf.org; Tue, 09 Mar 2004 18:45:29 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0qua-000Glc-Dc; Tue, 09 Mar 2004 23:45:24 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <124242121131.20040309154433@psg.com> To: "Wijnen, Bert (Bert)" CC: Sharon Chisholm , idr@ietf.org Subject: Re: [Idr] Experimental code-points In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15503B64AB9@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15503B64AB9@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Mar 2004 15:44:33 -0800 Bert, Seems that the text already has it: > a) The code points must be from a space designated as "Standards > Action", amended by IESG approval to permit Early Allocation. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Does it do the job? -- Alex http://www.psg.com/~zinin/ Saturday, March 6, 2004, 5:01:34 AM, Wijnen, Bert (Bert) wrote: > Aha ... good. For me that Covers it. > But... it might be good to add that "IESG approval" > into the list of "conditions" in sect 2 as well. > I bet people will often skip the intro and go straight to > the "what are the conditions" section to see if they can > request an early registration. > Thanks, > Bert >> -----Original Message----- >> From: Alex Zinin [mailto:zinin@psg.com] >> Sent: woensdag 3 maart 2004 21:55 >> To: Wijnen, Bert (Bert) >> Cc: Sharon Chisholm; idr@ietf.org >> Subject: Re: [Idr] Experimental code-points >> >> >> Bert, Sharon- >> >> The doc says: >> >> > This memo only addresses the early allocation of code points from >> > spaces whose allocation policy is "Standards Action" >> [2434] AND have >> > been amended to permit early allocation. This permission must be >> > granted by the IESG, and code spaces with permission for early >> > allocation must be marked as such in the IANA registry. >> >> In other words, it doesn't apply to an existing registry >> unless IESG approves >> that this process is applicable. This leaves existing >> registries, OID included, >> intact unless someone takes an action. >> >> Is this good enough? >> >> -- >> Alex >> http://www.psg.com/~zinin/ >> >> Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote: >> > Good point. They can get an OID assigned in the >> experimental branch though. >> >> >> > Thanks, >> > Bert >> >> > -----Original Message----- >> > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] >> > Sent: dinsdag 2 maart 2004 9:30 >> > To: idr@ietf.org >> > Cc: Wijnen, Bert (Bert) >> > Subject: RE: [Idr] Experimental code-points >> >> >> >> > hi >> >> > In looking through >> > > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt >> I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated. >> In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. >> 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' >> Sharon >> -----Original Message----- >> From: Alex Zinin [ mailto:zinin@psg.com ] >> Sent: Monday, March 01, 2004 3:11 AM >> To: idr@ietf.org >> Subject: [Idr] Experimental code-points >> As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA15385 for ; Tue, 9 Mar 2004 18:17:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0qT7-0000y3-NJ; Tue, 09 Mar 2004 18:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0qSN-0000nK-1i for idr@optimus.ietf.org; Tue, 09 Mar 2004 18:16:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06217 for ; Tue, 9 Mar 2004 18:16:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0qSK-0000At-00 for idr@ietf.org; Tue, 09 Mar 2004 18:16:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0qRK-00000m-00 for idr@ietf.org; Tue, 09 Mar 2004 18:15:11 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B0qQR-0007ex-00 for idr@ietf.org; Tue, 09 Mar 2004 18:14:15 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0qQR-0008Wb-RW; Tue, 09 Mar 2004 23:14:15 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <22240253766.20040309151326@psg.com> To: "Susan Hares" CC: idr@ietf.org Subject: Re: [Idr] FW: IDR minutes In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Mar 2004 15:13:26 -0800 Sue- Some corrections below, please. Monday, March 1, 2004, 7:40:23 PM, Susan Hares wrote: [...] > 4) BGP Peer Restart Backoff Mechanisms [10 minutes] > document: draft-hares-bgp-backoff-01.txt (ietf) (-02 Update) > Author: Susan Hares > Presentation Sue Hares > - Alex: draft should say informational Change to "the draft says it's an RFC, shouldn't do that" > achieve functionality using existing states? > - Sue: no... can't use existing states; already > investigated that option > 5) Deterministic Route Redistribution into BGP [10 minutes] > document: draft-chen-bgp-redist-00.txt > Authors: Jenny Yuan, Enke Chen > Enke Chen > - Andrew Lang: used to use configured localpref tweaking; not > management intensive... unsure if this is needed > - Enke: timing dependent non-deterministic problem so > current knobs cannot be used reliably; does not > break anything... backwards compatible > - Andrew Lang: better to educate people about localpref > - Barry Friedman: lacks generality too narrow a problem > space... only addresses RIP/iBGP interaction > - Enke: tweaking of admin distance defines a baseline > - need per route granularity to solve for all cases? > Possibility of adding more configuration conflicts. > - Alex: this problem only occurs if there's a consistancy > issue between two places... May not be an issue for > a single selection point. Change to: the problem occurs if a router has to select best routes in two places: as in the draft--once in BGP and once in the routing table, and the decisions are not consistent. wonder if the problem still exists if an implementation selects best paths in one place only, e.g. gated?. if so, is the problem implementation-specific, not to mean it shouldn't resolved. Alex sent an e-mail to the list with more details. > 8) BGP Attribute Codes and Suggested Procedures > Document: draft-kompella-zinin-early-allocation-00.txt > Author: Alex Zinin, Kireeti Kompella > Presentation Alex Zinin > - Sharon: talking about protocols and not OIDs preallocation? > bad to preallocate in the MIB... different from what > other WGs; exclude MIB OIDs > - Kireeti: not suggesting that everyone use this > - It would have been nicer to have had OIDs > preallocated so as not to reimpliment the MIB > - Sharon: OIDs not allocated to drafts because if the drafts > goes away then you've wasted numbers > - Lou Berger: allocation with 1 year with 1 renewal is too short; > alterntate policy: as long as draft or version is > alive, expire in 3 to 6 months > - Alex: that suggestion ties validity with ability of author > to submit the draft; suggestion: once document is > submitted to IESG then we freeze. Don't want to > allocate codepoints too early. > - Dave Meyer: Are you sure that IANA can time anything out > - Alex: No Change to: No, that's why the drafts asks the WG chairs to keep track of the timers. > - Dave Meyer: WG chair needs to manage this? I think Dave asked if the WG chairs will need to maintain their own, parallel registry to maintain this. Alex: if IANA registry includes all info necessary, such as time of allocation, responsible WG, etc., then it should be a matter of periodically looking through the IANA registries. > - What happens if the allocation is not renewed and > code is using it still? > - Alex: Add provision to document to deprecate but not return Change to: the document allows to deprecate, but not return > - Kireeti: Deprecate for a period of time to give people time > to remove. Formal process to do early allocations > and if it goes through then stick with it but if it > doesn't go through then people must take this out. > - Dino: Allocate experimental codepoints and once > standardised, then adopt standard codepoint for > sending but accept both. > - Sue: Good for SAFIs as well as AFIs? > - Dino: All well known IANA values > - Fenner: RFC already documents a process for transitioning > codepoints Thanks. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA27509 for ; Mon, 8 Mar 2004 15:40:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RXg-0001je-K2; Mon, 08 Mar 2004 15:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzbSu-0001uy-To for idr@optimus.ietf.org; Sat, 06 Mar 2004 08:03:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16033 for ; Sat, 6 Mar 2004 08:03:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzbSt-0000ef-00 for idr@ietf.org; Sat, 06 Mar 2004 08:03:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzbS1-0000VC-00 for idr@ietf.org; Sat, 06 Mar 2004 08:02:46 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AzbRU-0000LD-00 for idr@ietf.org; Sat, 06 Mar 2004 08:02:12 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i26D1c020197 for ; Sat, 6 Mar 2004 07:01:39 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1699NT0S>; Sat, 6 Mar 2004 14:01:37 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503B64AB9@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Alex Zinin , "Wijnen, Bert (Bert)" Cc: Sharon Chisholm , idr@ietf.org Subject: RE: [Idr] Experimental code-points MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 6 Mar 2004 14:01:34 +0100 Aha ... good. For me that Covers it. But... it might be good to add that "IESG approval" into the list of "conditions" in sect 2 as well. I bet people will often skip the intro and go straight to the "what are the conditions" section to see if they can request an early registration. Thanks, Bert > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: woensdag 3 maart 2004 21:55 > To: Wijnen, Bert (Bert) > Cc: Sharon Chisholm; idr@ietf.org > Subject: Re: [Idr] Experimental code-points > > > Bert, Sharon- > > The doc says: > > > This memo only addresses the early allocation of code points from > > spaces whose allocation policy is "Standards Action" > [2434] AND have > > been amended to permit early allocation. This permission must be > > granted by the IESG, and code spaces with permission for early > > allocation must be marked as such in the IANA registry. > > In other words, it doesn't apply to an existing registry > unless IESG approves > that this process is applicable. This leaves existing > registries, OID included, > intact unless someone takes an action. > > Is this good enough? > > -- > Alex > http://www.psg.com/~zinin/ > > Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote: > > Good point. They can get an OID assigned in the > experimental branch though. > > > > Thanks, > > Bert > > > -----Original Message----- > > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] > > Sent: dinsdag 2 maart 2004 9:30 > > To: idr@ietf.org > > Cc: Wijnen, Bert (Bert) > > Subject: RE: [Idr] Experimental code-points > > > > > hi > > > In looking through > > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt > I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated. > In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. > 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' > Sharon > -----Original Message----- > From: Alex Zinin [ mailto:zinin@psg.com ] > Sent: Monday, March 01, 2004 3:11 AM > To: idr@ietf.org > Subject: [Idr] Experimental code-points > As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA15722 for ; Wed, 3 Mar 2004 19:20:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aygaq-0000Tf-Gm; Wed, 03 Mar 2004 19:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aygag-0000Sc-84 for idr@optimus.ietf.org; Wed, 03 Mar 2004 19:19:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09441 for ; Wed, 3 Mar 2004 19:19:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aygae-0002Fw-00 for idr@ietf.org; Wed, 03 Mar 2004 19:19:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AygZh-00027d-00 for idr@ietf.org; Wed, 03 Mar 2004 19:18:54 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AygZ0-0001q8-00 for idr@ietf.org; Wed, 03 Mar 2004 19:18:10 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i240HdQ01415 for ; Wed, 3 Mar 2004 19:17:39 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 19:17:39 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A60B0F0@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: idr@ietf.org Cc: "Wijnen, Bert (Bert)" Subject: RE: [Idr] Experimental code-points MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Mar 2004 19:17:39 -0500 hi My concern is that this is opening us up to even more queries for premature OID assignment, for which we are most likely going to say they need to wait for the RFC. It's a matter of cutting off a frequently asked question by having clear text in the draft that properly sets expectations. People may reason that if Foo qualifies then the Foo MIB does, so I'd like to see some text in the document that will make it more clear that this isn't the case. Perhaps a middle ground would be to add text indicating that early allocation of code points for the protocol is independent of the MIB OID allocation, or something along those lines. Sharon -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Wednesday, March 03, 2004 7:55 AM To: Wijnen, Bert (Bert) Cc: Chisholm, Sharon [CAR:0S00:EXCH]; idr@ietf.org Subject: Re: [Idr] Experimental code-points Bert, Sharon- The doc says: > This memo only addresses the early allocation of code points from > spaces whose allocation policy is "Standards Action" [2434] AND have > been amended to permit early allocation. This permission must be > granted by the IESG, and code spaces with permission for early > allocation must be marked as such in the IANA registry. In other words, it doesn't apply to an existing registry unless IESG approves that this process is applicable. This leaves existing registries, OID included, intact unless someone takes an action. Is this good enough? -- Alex http://www.psg.com/~zinin/ Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote: > Good point. They can get an OID assigned in the experimental branch > though. > Thanks, > Bert > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] > Sent: dinsdag 2 maart 2004 9:30 > To: idr@ietf.org > Cc: Wijnen, Bert (Bert) > Subject: RE: [Idr] Experimental code-points > hi > In looking through > > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocat > ion-00.txt > tion-00.txt> > I would suggest the following change to address my concern that it > inappropriately sets the expectation that MIB OIDs will be > pre-allocated. > In either the 'Introduction' or in the section 'Conditions for Early > Allocation' the following text needs to be added. > 'Note that under no condition will MIB Object Identifiers (OIDs) be > allocated before the RFC is published.' > Sharon > -----Original Message----- > From: Alex Zinin [ mailto:zinin@psg.com ] > Sent: Monday, March 01, 2004 3:11 AM > To: idr@ietf.org > Subject: [Idr] Experimental code-points > As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA14057 for ; Wed, 3 Mar 2004 17:12:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayeav-0007hI-JN; Wed, 03 Mar 2004 17:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyeZy-0007gg-M0 for idr@optimus.ietf.org; Wed, 03 Mar 2004 17:11:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29749 for ; Wed, 3 Mar 2004 17:10:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyeZw-00019t-00 for idr@ietf.org; Wed, 03 Mar 2004 17:11:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyeZ1-0000y2-00 for idr@ietf.org; Wed, 03 Mar 2004 17:10:04 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1AyeY5-0000bf-00 for idr@ietf.org; Wed, 03 Mar 2004 17:09:05 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i23M8ZBm026489 for ; Wed, 3 Mar 2004 14:08:35 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i23M8Zo00577 for ; Wed, 3 Mar 2004 14:08:35 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200403032208.i23M8Zo00577@merlot.juniper.net> To: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <35832.1078351715.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 03 Mar 2004 14:08:35 -0800 Folks, Let me propose that those who think that the base spec should be changed please get together and propose a *specific* replacement text, *taking into account* all the comments on this topic that have been posted to the list over the last few days (as well as the past discussion on this topic). Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA06732 for ; Wed, 3 Mar 2004 07:58:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVwn-0001Ey-7C; Wed, 03 Mar 2004 07:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVve-0001Ck-MW for idr@optimus.ietf.org; Wed, 03 Mar 2004 07:57:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23537 for ; Wed, 3 Mar 2004 07:56:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyVvJ-0003TX-00 for idr@ietf.org; Wed, 03 Mar 2004 07:56:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyVuZ-0003LR-00 for idr@ietf.org; Wed, 03 Mar 2004 07:55:44 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AyVtw-0003Bs-00 for idr@ietf.org; Wed, 03 Mar 2004 07:55:04 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyVtq-0007lo-G4; Wed, 03 Mar 2004 12:54:58 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <15122904797.20040303215438@psg.com> To: "Wijnen, Bert (Bert)" CC: Sharon Chisholm , idr@ietf.org Subject: Re: [Idr] Experimental code-points In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15503B64455@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15503B64455@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Mar 2004 21:54:38 +0900 Bert, Sharon- The doc says: > This memo only addresses the early allocation of code points from > spaces whose allocation policy is "Standards Action" [2434] AND have > been amended to permit early allocation. This permission must be > granted by the IESG, and code spaces with permission for early > allocation must be marked as such in the IANA registry. In other words, it doesn't apply to an existing registry unless IESG approves that this process is applicable. This leaves existing registries, OID included, intact unless someone takes an action. Is this good enough? -- Alex http://www.psg.com/~zinin/ Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote: > Good point. They can get an OID assigned in the experimental branch though. > Thanks, > Bert > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] > Sent: dinsdag 2 maart 2004 9:30 > To: idr@ietf.org > Cc: Wijnen, Bert (Bert) > Subject: RE: [Idr] Experimental code-points > hi > In looking through > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt > I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated. > In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. > 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' > Sharon > -----Original Message----- > From: Alex Zinin [ mailto:zinin@psg.com ] > Sent: Monday, March 01, 2004 3:11 AM > To: idr@ietf.org > Subject: [Idr] Experimental code-points > As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA03251 for ; Wed, 3 Mar 2004 03:07:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRON-0001Om-D6; Wed, 03 Mar 2004 03:06:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyP84-0000Lm-V2 for idr@optimus.ietf.org; Wed, 03 Mar 2004 00:41:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03221 for ; Wed, 3 Mar 2004 00:41:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyP82-0007Ws-00 for idr@ietf.org; Wed, 03 Mar 2004 00:41:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyP76-0007JP-00 for idr@ietf.org; Wed, 03 Mar 2004 00:40:13 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AyP60-0006xh-00 for idr@ietf.org; Wed, 03 Mar 2004 00:39:04 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i235cWA00544 for ; Tue, 2 Mar 2004 23:38:33 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1699KRK7>; Wed, 3 Mar 2004 06:38:27 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503B64455@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Sharon Chisholm , idr@ietf.org Cc: "Wijnen, Bert (Bert)" Subject: RE: [Idr] Experimental code-points MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C400E1.BFB30A80" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Mar 2004 06:38:26 +0100 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C400E1.BFB30A80 Content-Type: text/plain Good point. They can get an OID assigned in the experimental branch though. Thanks, Bert -----Original Message----- From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] Sent: dinsdag 2 maart 2004 9:30 To: idr@ietf.org Cc: Wijnen, Bert (Bert) Subject: RE: [Idr] Experimental code-points hi In looking through http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated. In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' Sharon -----Original Message----- From: Alex Zinin [ mailto:zinin@psg.com ] Sent: Monday, March 01, 2004 3:11 AM To: idr@ietf.org Subject: [Idr] Experimental code-points As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. -- Alex http://www.psg.com/~zinin/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------_=_NextPart_001_01C400E1.BFB30A80 Content-Type: text/html RE: [Idr] Experimental code-points
Good point. They can get an OID assigned in the experimental branch though.
 

Thanks,
Bert

-----Original Message-----
From: Sharon Chisholm [mailto:schishol@nortelnetworks.com]
Sent: dinsdag 2 maart 2004 9:30
To: idr@ietf.org
Cc: Wijnen, Bert (Bert)
Subject: RE: [Idr] Experimental code-points

hi

In looking through
        http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt

I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated.

In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added.

'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.'

Sharon

-----Original Message-----
From: Alex Zinin [mailto:zinin@psg.com]
Sent: Monday, March 01, 2004 3:11 AM
To: idr@ietf.org
Subject: [Idr] Experimental code-points



As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable.

--
Alex
http://www.psg.com/~zinin/


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr

------_=_NextPart_001_01C400E1.BFB30A80-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA03145 for ; Wed, 3 Mar 2004 03:02:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRJb-0000Gk-FG; Wed, 03 Mar 2004 03:01:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRIz-0000Bb-Se for idr@optimus.ietf.org; Wed, 03 Mar 2004 03:00:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08495 for ; Wed, 3 Mar 2004 03:00:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRIb-0007XI-00 for idr@ietf.org; Wed, 03 Mar 2004 03:00:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRH2-0007BS-00 for idr@ietf.org; Wed, 03 Mar 2004 02:58:37 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AyRGG-0006zJ-00 for idr@ietf.org; Wed, 03 Mar 2004 02:57:49 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D6CF92D48D0 for ; Wed, 3 Mar 2004 02:57:19 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 77477-01-7 for ; Wed, 3 Mar 2004 02:57:18 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 92BB92D4879 for ; Wed, 3 Mar 2004 02:57:17 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Idr] FW: IDR minutes Message-ID: Thread-Topic: [Idr] FW: IDR minutes Thread-Index: AcQAv/OALjBfDCc2Rr2faKxgck3z/AAK3dpA From: "Susan Hares" To: "Sharon Chisholm" , X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Mar 2004 02:57:17 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id DAA03145 we'll add that. We certainly did talk about that! sue -----Original Message----- From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] Sent: Tuesday, March 02, 2004 8:31 PM To: idr@ietf.org Subject: RE: [Idr] FW: IDR minutes hi I believe we also briefly discussed setting up a call to discuss the v2 MIB and that interested parties should contact either Sue or myself. Sharon -----Original Message----- From: Susan Hares [mailto:shares@nexthop.com] Sent: Monday, March 01, 2004 10:40 PM To: idr@ietf.org Subject: [Idr] FW: IDR minutes Minutes for 3/1/04 session -----Original Message----- From: Jake Khuon Sent: Monday, March 01, 2004 3:18 AM To: Susan Hares; yakov@juniper.net Subject: IDR minutes Inter-Domain Routing WG (idr) Monday, March 1 at 1530-1730 ================================== CHAIRS: Sue Hares (skh@nexthop.com) Yakov Rekhter (yakov@juniper.net) AGENDA: 1) Agenda Bashing Agenda Slides 2) Document status [5 minutes] - Bundle went to IESG BGP-4 draft-23 draft-ietf-idr-bgp4-23.txt BGP-4 V1 MIB draft-ietf-idr-bgp4-mib-13.txt BGP-4 Protocol Analysis draft-ietf-idr-bgp-analysis-04.txt BGP Security Vulnerabilities Analysis draft-ietf-idr-bgp-vuln-00.txt Experience with the BGP-4 Protocol draft-ietf-idr-bgp4-experience-protocol-03.txt BGP 4 Implementation Report draft-ietf-idr-bgp-implementation-00.txt BGP-4 V1 MIB implementation report draft-ietf-idr-bgp-mibagent-survey-01.txt Presentation 3) Implementation Reports and FSM issues for current drafts [10 minutes] document: None, presentation only Presentation Sue Hares - Yakov: route-reflector update status? - Enke: route-reflector update (4 weeks) - Enke: prefix-orf was not added to charter - Sue: yes it was added, administrative error in listing 4) BGP Peer Restart Backoff Mechanisms [10 minutes] document: draft-hares-bgp-backoff-01.txt (ietf) (-02 Update) Author: Susan Hares Presentation Sue Hares - Alex: draft should say informational achieve functionality using existing states? - Sue: no... can't use existing states; already investigated that option 5) Deterministic Route Redistribution into BGP [10 minutes] document: draft-chen-bgp-redist-00.txt Authors: Jenny Yuan, Enke Chen Enke Chen - Andrew Lang: used to use configured localpref tweaking; not management intensive... unsure if this is needed - Enke: timing dependent non-deterministic problem so current knobs cannot be used reliably; does not break anything... backwards compatible - Andrew Lang: better to educate people about localpref - Barry Friedman: lacks generality too narrow a problem space... only addresses RIP/iBGP interaction - Enke: tweaking of admin distance defines a baseline - need per route granularity to solve for all cases? Possibility of adding more configuration conflicts. - Alex: this problem only occurs if there's a consistency issue between two places... May not be an issue for a single selection point. Introduction of new step will effect current deployment traffic selection? - Enke: This will happen regardless. Should not effect current deployments and if there's a change, the change will be for the better. - By definition, it does change behavior. - Alex: Will this be applicable to only situations where there is a problem? - Yakov: Is this an implementation method? - Alex: Is this informational or standards-track? - Enke: Either is fine - It can't be a local matter because it must be consistent throughout the entire system - Enke: Decision on redistributed routes is made locally in each router - Behavior is changed because new code now uses admin distance over localpref? - Enke: If only localpref is used then things should not change - Cengiz: If route-reflector is used? - Enke: I need to think about it further 6) BGP based auto-discovery [Sue Hares, P. Unbehagen] [10 minutes] document: draft-hlmu-l2vpn-bgp-discovery-00.txt authors: P. Unbehagen, P. Muley, V. Radoaca, Susan Hares Presentation Sue Hares, P. Unbehagen - Already a L2VPN draft that addresses this in a defined NLRI with label information - Paul: This draft is meant to provide LDP pseudowire config information - Other spec can do same thing [autodiscovery] without label information - Kireeti: Would like to be able to use this AFI with different SAFI [65] and NLRI format - Would the two SAFIs be solving similar problems - Kireeti: My SAFI solves different problems 7) BGP Assignment of AFI/SAFI address [10 minutes] Document: draft-hares-bgp-assign-afisafi-00.txt Author: Susan Hares Presentation Sue Hares 8) BGP Attribute Codes and Suggested Procedures Document: draft-kompella-zinin-early-allocation-00.txt Author: Alex Zinin, Kireeti Kompella Presentation Alex Zinin - Sharon: talking about protocols and not OIDs preallocation? bad to preallocate in the MIB... different from what other WGs; exclude MIB OIDs - Kireeti: not suggesting that everyone use this - It would have been nicer to have had OIDs preallocated so as not to reimpliment the MIB - Sharon: OIDs not allocated to drafts because if the drafts goes away then you've wasted numbers - Lou Berger: allocation with 1 year with 1 renewal is too short; alterntate policy: as long as draft or version is alive, expire in 3 to 6 months - Alex: that suggestion ties validity with ability of author to submit the draft; suggestion: once document is submitted to IESG then we freeze. Don't want to allocate codepoints too early. - Dave Meyer: Are you sure that IANA can time anything out - Alex: No - Dave Meyer: WG chair needs to manage this? - What happens if the allocation is not renewed and code is using it still? - Alex: Add provision to document to deprecate but not return - Kireeti: Deprecate for a period of time to give people time to remove. Formal process to do early allocations and if it goes through then stick with it but if it doesn't go through then people must take this out. - Dino: Allocate experimental codepoints and once standardised, then adopt standard codepoint for sending but accept both. - Sue: Good for SAFIs as well as AFIs? - Dino: All well known IANA values - Fenner: RFC already documents a process for transitioning codepoints 9) Charter Discussion [20 minutes] Thanks to all implementers who send in reports on the base specification, we will be opening the charter. This section of the meeting will discuss what items will be added to the charter. Presentation - Top three most important; maybe ECMP little higher than Fault Isolation -- /*==================[ Jake Khuon ]=====================+ | Field App. Engineer http://www.nexthop.com/ /\ /~ E X T H O P | | Ofc: +1 (425) 391-2262 Fax: +1 (425) 391-6772 / \/ Technologies, Inc.| +==========[ 1911 Landings Drive, Mountain View, CA 94043 USA ]===========*/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA02557 for ; Wed, 3 Mar 2004 02:22:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQhf-0005rn-Ko; Wed, 03 Mar 2004 02:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQgt-0005iO-TU for idr@optimus.ietf.org; Wed, 03 Mar 2004 02:21:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26251 for ; Wed, 3 Mar 2004 02:21:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQgq-0007jb-00 for idr@ietf.org; Wed, 03 Mar 2004 02:21:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQfu-0007be-00 for idr@ietf.org; Wed, 03 Mar 2004 02:20:17 -0500 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 1AyQfC-0007MP-00 for idr@ietf.org; Wed, 03 Mar 2004 02:19:30 -0500 Received: from A1VVMQ21.wireless.ietf59.or.kr (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i237Is8d001414 for ; Wed, 3 Mar 2004 01:18:55 -0600 (CST) From: Andrew Lange To: idr@ietf.org Message-ID: <11588263.1078269532@A1VVMQ21.wireless.ietf59.or.kr> X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========F9F1C055D554AA970B14==========" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Idr] Charter Add - Flexible BGP Communities Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Mar 2004 23:18:52 -0800 --==========F9F1C055D554AA970B14========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit Hello all, I'd like to add the attached BGP Flexible Communities draft as a wg draft (it should show up in the drafts repository after the meeting). I presented on this at both Yokohama and San Francisco. The feedback was generally that this was an idea that should be adopted by the wg and considered further. Thanks, Andrew --==========F9F1C055D554AA970B14========== Content-Type: text/plain; charset=us-ascii; name="draft-lange-flexible-bgp-communities-02.txt" Content-Disposition: attachment; filename="draft-lange-flexible-bgp-communities-02.txt"; size=36430 Content-Transfer-Encoding: 7bit Internet Engineering Task Force A. Lange INTERNET DRAFT Alcatel March 2004 Expires September 2004 Flexible BGP Communities Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines a new attribute for BGP called the Flexible Community attribute. Flexible Communities build on the experience and utility of the standard BGP community, and the extended BGP community attributes. This attribute allows operators to associate structured information with a route or set of routes. This information can be then be used to execute routing policy. An enhanced version of communities is necessary to accommodate IPv6, 4-byte ASN's, and introduce a more extensible and flexible policy expression. This document also introduces the concept of Neighbor Classes. A Neighbor Class is applied to a group of BGP neighbors who share certain attributes. For example, the PEER Neighbor Class could be applied to BGP sessions between ASN X and other networks with which ASN X has a non-transit peering relationship. Lange [Page 1] INTERNET DRAFT December 2002 Table of Contents Status of this Memo......................................... 1 Abstract.................................................... 1 1. Introduction............................................ 2 2. The BGP Flexible Community Attribute.................... 3 2.1 Transitivity Field..................................... 4 2.2 Structure Field........................................ 4 2.3 Type Field............................................. 5 2.4 Originating ASN Field.................................. 5 2.5 Length Field........................................... 6 3. Locally Defined Structures and Types.................... 6 4. Neighbor Classes........................................ 6 4.1 Locally Defined Neighbor Classes....................... 7 4.2 Defined Neighbor Classes............................... 8 5. Defined Flexible BGP Community Structures............... 9 6. Base BGP Flexible Community Type (Opaque Type).......... 10 7. Defined Flexible BGP Community Types.................... 10 7.1 NO_EXPORT.............................................. 10 7.2 ONLY_EXPORT............................................ 11 7.3 ANNOUNCE_WITH.......................................... 12 7.4 PREPEND................................................ 13 7.5 The BGP VPN Communities................................ 13 8. New Capability Code for Flexible Communities............ 14 9. Aggregation............................................. 14 10. Operations.............................................. 15 11. Security Considerations................................. 15 12. IANA Considerations..................................... 16 13. References.............................................. 16 14. Acknowledgements........................................ 17 15. Author's Address........................................ 17 Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1. Introduction This attribute represents the third generation of the BGP community attribute. The first generation is documented in RFC1997 [RFC1997]. The second generation, the extended community, is documented in EX- COMM [EX-COMM]. The Flexible Community Attribute provides a number of important enhancements over the existing BGP Community Attribute and BGP Extended Community Attribute. These enhancements are: Lange [Page 2] INTERNET DRAFT December 2002 - Support for IPv6. - More efficient encoding of lists of data, for example, a list of ASN's. - Clean support for a broad range of future data field structures and interpretations. - Support for locally defined community structures, and interpretations. - Easy extensibility for a range of future applications. The continuation and expansion of the structure introduced with Extended Communities allows for policy based on the application where the community is being used. The separation of structure and interpretation allows for easier machine and human parsing of community types which do the same thing with slightly different input. This attribute continues the use of the Transitivity community bit, first introduced in the Extended Community Attribute. We also define a set of well-known values for this attribute which can be used to replicate and extend the functionality of the existing well-known community values. The concept of Neighbor Classes is introduced. A Neighbor Class is defined on a BGP peering session. It allows neighbors that share a set of administrative attributes to be easily grouped together. Policy can then be defined through Flexible Communities in reference to these groupings. 2. The BGP Flexible Community Attribute The Flexible Community Attribute is a transitive optional BGP attribute with a Type Code of . The attribute consists of a list of "flexible communities." Each Flexible Community is encoded as a variable length quantity. The encoding scheme is: - Transitivity Field: 1 bit - Structure Field: 7 bits - Type Field: 2 octets - Length Field: 1 octet - Value Field: 0-255 octets 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T| Struct. | Type | Originating | Lange [Page 3] INTERNET DRAFT December 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASN | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value Field (0-255 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.1. Transitivity Field: The Transitivity Field is one bit. It can take the following values: Value 0: The community is transitive across ASes Value 1: The community is non-transitive across ASes It is important to note that the transitivity defined by this field is different from the general transitivity of a BGP attribute. A single Flexible Community Attribute, can contain multiple Flexible Communities, each of which may or may not be transitive. If a route originates in an AS with the transitivity bit set, indicating that the community is non-transitive, then that AS MUST NOT propagate that community to its peers. However, if a community with the transitive bit set is applied on an outbound policy expression (e.g., a route- map), the community will be conveyed to the immediately adjacent peer. That peer, in turn, will NOT propagate the community to its peers. The one exception to this is as-confederations. For the purposes of this attribute, confederation boundaries should be treated the same as IBGP. In other words, non-transitive flexible communities should be propagated to other members of the as- confederation, unless overridden by local policy. If the community is transitive, then the Value Field MUST contain the originating ASN. This ASN is encoded as a 4-octet value, occupying the first 4 octets of the Value Field. Two-octet ASN numbers are padded out to 4 octets. Any additional information in the Value Field comes after this origin ASN data. 2.2. Structure Field: The Structure Field's contents modify the Type Field. For example, a Flexible Community which specifies SPECIFIC_NO_EXPORT in its Type Field, can be modified by the contents of the Structure Field to let the receiver know if the list of data on which it must act is a list of 2 octet or 4 octet ASNs. A set of commonly used Structure values is defined later in this document. The Structure field is the latter 7 bits of the first octet. It is split into two sub-fields. Lange [Page 4] INTERNET DRAFT December 2002 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |T|L| Struct. | +-+-+-+-+-+-+-+-+ L - Local bit The Local bit can take two values: Value 0: The Structure is Locally Defined. Value 1: The Structure is Well Known. 2.3. Type Field: The Type Field is two octets. This contents of this field are used to define an action for the recipient to take on the route, or to define and attribute that is related to that route. An example of the former would be a Type which requests that a route be ONLY_EXPORTed to a specific set of peers. An example of the latter would be a Type that defines the LINK_BANDWIDTH associated with a certain NLRI. Like the Structure Field the Type Field is split into two Sub-Fields: 1 2 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Local bit can take two values: Value 0: The Type is Locally Defined. Value 1: The Type is Well Known. An implementation MUST allow an operator to filter out entire Types of Flexible Communities from their peering sessions if they so choose. 2.4 Originating ASN Field: This field contains the ASN that added the flexible community to the route. It is 4 octets long. In the case of a 2-byte ASN, the first 2 octets are set to zero, as padding. Lange [Page 5] INTERNET DRAFT December 2002 2.5. Length Field: The Length Field specifies the length, in octets, of the Value Field. 3. Locally Defined Structures and Types The Local bit allows the operator of the network to define Structures and Types that are relevant only within that ASN's boundaries. The definition the term "local" used throughout this document is: "A value used by ad hoc agreement or convention outside the scope of standardization, which has meaning only between the parties using the Flexible Community in question." This typically means that the Local value only has meaning within an AS or set of ASes controlled by a single entity. A Locally Defined Structure or Type will have a syntax for interpretation defined on the routers that need to interpret it. If a router receives a community with a Locally Defined Structure or Type that it does not recognize, then it should ignore the contents and process the route based on the information in the route that it does understand. This includes obeying the transitivity bit, in the Flexible Community. If the community is set to non-transitive, even if the router does not understand the rest of the Structure or Type of the community, that community should not be forwarded outside the AS. In order to prevent collisions with other operators' Locally Defined values, Flexible Communities containing Locally Defined Structures or Types MUST be non-transitive (have their Transitivity Field set to 1). 4. Neighbor Classes A Neighbor Class is a value which represents a certain class, or group, of BGP neighbors. Each BGP peering session can be configured with zero or more Neighbor Classes. This value will allow a general classification of what sort of relationship the BGP session represents. With the sort of session defined, it becomes easier to apply policy to only that class of neighbors. Neighbor Classes make the expression of policy through flexible communities much easier. There are a number of examples in the sections on defined values. Neighbor Classes can be used in two main ways. First they can be used in a passive manner, where the configuration acts as a policy expression for communities matching it. An example of this would be configuring a neighbor with the PEER neighbor class, and having a community that, say is set to NO_EXPORT for the NEIGHBOR CLASS PEER. In this configuration, all the neighbors that are configured as PEERs Lange [Page 6] INTERNET DRAFT December 2002 would match and filter out the route carrying the NO_EXPORT, NEIGHBOR CLASS PEER community. This is the standard way of using neighbor classes. A second, optional, way to use Neighbor Classes would be to allow inbound community tagging. In this usage, routes traversing the session would be automatically tagged with a flexible community with the appropriate neighbor class value. This eases configuration. To extend the example above, our neighbor designated PEER would add a community with NEIGHBOR CLASS PEER to routes traversing the BGP session. This community could then be used further down the line to just announce PEER routes to a particular customer. This usage is configurable on a per-neighbor basis. A Neighbor Class is encoded as a 2-octet value with 2 parts: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Neighbor Class | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Local bit can take two values: Value 0: The Neighbor Class is Locally Defined. Value 1: The Neighbor Class is Well Known. 4.1. Locally Defined Neighbor Classes If a router receives a Flexible Community containing a Neighbor Class that it does not recognize, then it should ignore the contents and process the route based on the information in the route that it does understand. If the Transitivity Field of the Flexible Community with the Locally Defined Structure or Type is set to 1 (the community is non-transitive) then the router MUST NOT forward the Flexible Community. Similarly, if the Transitivity Field is set to 0 (the community is transitive) the router MUST forward the community along with the NLRI. Using Locally Defined Neighbor Classes an operator could easily define a set that is locally useful. This set could be used in a flat name space, for example, one could say that "31" would be "Asian Public Peers", and "34" would be European Private Peers. Also, a given BGP Neighbor can be part of multiple Neighbor Classes. This would allow for a hierarchical or additive name space. For example, a neighbor could be part of both "PEER", and locally defined Lange [Page 7] INTERNET DRAFT December 2002 "ASIAN" and "PUBLIC PEER" Classes. The logical matching functionality available is left implementation-dependent. However, the default in such as case is logical OR functionality for matching this neighbor class. In the case where routes are being tagged inbound, then by default a single community with all configured neighbor classes in a list is added. Implementation dependent knobs are suggested to allow more fine grained control. 4.2. Defined Neighbor Classes This document defines Neighbor Class values for common BGP neighbor groupings: ALL NEIGHBORS This class is the default Neighbor Class for all BGP peers. This class is represented by a value of 0 (0x8000). PEER This class is typically applied to sessions where a transit-free relationship exists between the two providers. This class is represented by a value of 1 (0x8001). CUSTOMER This class is typically applied to sessions where the remote end of the session is operated by a customer. This class is represented by a value of 2 (0x8002). UPSTREAM This class is typically applied to sessions where the remote end of the session is operated by a network from which you receive transit routes. This class is represented by a value of 3 (0x8003). CONFEDERATION PEER This class is typically applied to sessions where the remote end of the session is part of a confederation. This class is represented by a value of 4 (0x8004). Lange [Page 8] INTERNET DRAFT December 2002 5. Defined Flexible BGP Community Structures This section defines a number of Structure values which different Type values can inherit. Summary of the Defined Values: - opaque/variable (0x40 or 0xC0) - list of ASN's (0x41 or 0xC1) - list of IPv4 addresses (0x42 or 0xC2) - list of IPv6 addresses (0x43 or OxC3) - list of neighbor_classes (0x44 or 0xC4) Defined Structure can be transitive or non-transitive, they are well known. Opaque/Variable Structure This sort of structure defers interpretation of the community and value field to the Type value. Typically this structure value will be used when the Type value does not have a lot of variations, but rather one structure for the Value Field. This structure is represented by the value 0x00. List of ASN's This structure value means that the Type Field's action is qualified by a list of ASN's, contained in the Value Field. In the case of 2 byte ASN's the value is padded to 4 bytes by inserting 2 octets worth of zeros in the leftmost portion of the value. This structure is represented by the value 0x01. List of IPv4 Addresses This structure value means that the Type Field's action is qualified by a list of IPv4 addresses, contained in the Value Field. This structure is represented by the value 0x02. List of IPv6 Addresses This structure value means that the Type Field's action is qualified by a list of IPv6 addresses, contained in the Value Field. Lange [Page 9] INTERNET DRAFT December 2002 This structure is represented by the value 0x03. List of Neighbor Classes This structure value means that the Type Field's action is qualified by a list of neighbor classes, contained in the Value Field. This structure is represented by the value 0x04. 6. Base BGP Flexible Community Type (Opaque Type) This section defines the base BGP community specification. Since the root value of communities is the ability to tag a route with arbitrary information, and then create a system to give that information meaning, the base flexible community type (type 0), is very simple. This base type could also be described as the "opaque type." All actions can be replicated with a well-thought out, provider dependent, implementation of a scheme using this opaque type. Like all flexible communities, this type can be transitive or non- transitive. This is a well known type. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00,0xC0 | 0x0000 | Originating | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASN | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value Field (0-255 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7. Defined Flexible BGP Community Types The Type Field specifies the subgroup that a set of communities belongs to. Typically this subgroup represents an action to be taken on the data. A variety of well-known Type Values follow. 7.1. NO_EXPORT This grouping of well-known communities specify a list of ASNs, Peer IPs, or Neighbor Classes NOT to announce a route to. Name: NO_EXPORT Type Code: 0x0001 Lange [Page 10] INTERNET DRAFT December 2002 Can Take Structures: Ox01 (ASN), 0x02 (IPv4), 0x03 (IPv6), 0x04 (neighbor-class) Transitive: Non-Transitive Min Length of Value Field: 2 octets Max Length of Value Field: 254 octets Behavior: All routes received with this community MUST NOT be advertised to the list of ASNs, Peer IPs, or Neighbor Classes contained in the Value Field. Notes: GLOBAL_NO_EXPORT is accomplished by sending a NO_EXPORT Flexible Community with the Neighbor Class of 0x00 (ALL NEIGHBORS). GLOBAL_NO_EXPORT's NO_EXPORT behavior is defined as: All routes received with this community 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.) [RFC1997] This is analogous to the NO_EXPORT community defined in [RFC1997]. 7.2. ONLY_EXPORT This grouping of well-known communities specify a list of ASNs, Peer IPs, or Neighbor Classes to announce a route to. Name: ONLY_EXPORT Type Code: 0x0002 Can Take Structures: Ox01 (ASN), 0x02 (IPv4), 0x03 (IPv6), 0x04 (neighbor-class) Transitive: Non-Transitive Min Length of Value Field: 0 octets Max Length of Value Field: 254 octets Behavior: The Value Field contains a list of ASNs, neighbor IP addresses, or Neighbor Classes to which the route should be advertised. The default behavior of a route carrying this community is the same as the GLOBAL_NO_EXPORT behavior, except for the ASNs, IPs, or Neighbor Classes listed in the Value Field. Notes: This community can be used to replicate the NO_ADVERTISE functionality from [RFC1997]. To do so, simply announce ONLY_EXPORT with a Structure of 0x03 or 0x04 (one of the IP address Structures), but with no IP address in the list. This will tell the receiving router that you wish to ONLY_EXPORT this route to NO peer IPs. Lange [Page 11] INTERNET DRAFT December 2002 This community can also be use to replicate the NO_EXPORT_SUBCONFED functionality from [RFC1997]. To do so, simply announce ONLY_EXPORT with a Neighbor Class of CONFEDERATION PEER (4, 0x8004). This will tell the receiving router that you wish to ONLY_EXPORT this route to Confederation Peers. 7.3. ANNOUNCE_WITH This group of well-known communities allows a network to announce a community to an ASN beyond those that it directly peers with, assuming its direct peers allow it to transit the community value. This community group has a lot of flexibility, and could be used to nest another ANNOUNCE_WITH community to gain reach greater than 2 ASN-hops away. If this is a good idea or not is unknown and is left to further study. The only theoretical restriction to the amount of nesting is that the community cannot exceed the maximum size for the Value Field. Since true transitivity can be obtained by simply setting a bit, this community is mainly useful for propagating NO_EXPORT or ONLY_EXPORT (which are non-transitive) to your neighbor's neighbors. In effect, this community, if allowed by the BGP neighbors in the chain, can be used for an originating network to very specifically control the distribution of its routes. This community type does contain a LOT of rope, and should be used with care. In the end, though, a mistake should only effect the person originating the route. Name: ANNOUNCE_WITH Type Code: 0x0003 Can Take Structures: Ox01 (ASN), 0x02 (IPv4), 0x03 (IPv6), 0x04 (neighbor-class) Transitive: Non-Transitive Min Length of Value Field: 8 octets Max Length of Value Field: 254 octets Behavior: This community's Value Field is split into two sections. - The first section is a variable length field that contains the full community value that you wish to announce. - The second section is a variable length field that contains the list of, ASN's, IP addresses, or neighbor_classes you wish to propagate this community to. If you wish to propagate to all peers, use the ALL NEIGHBORS neighbor class. When a router receives this community value, it should strip the ANNOUNCE_WITH community and announce the underlying community value to its neighbor. Lange [Page 12] INTERNET DRAFT December 2002 7.4. PREPEND This community can be used to ask a BGP peer to prepend its own ASN to its peers. Name: PREPEND Type Code: 0x0004 Can Take Structures: Ox01 (ASN), 0x02 (IPv4), 0x03 (IPv6), 0x04 (neighbor-class) Transitive: Non-Transitive Min Length of Value Field: 3 octets Max Length of Value Field: 254 octets Behavior: This community has 2 sections: The first section: Is a one-octet value which specifies the number of times that the ASN should prepend its ASN. It is recommended that operators constrain this value to no more than 3. Implementations MUST offer the ability for an operator to set a maximum bound for this field. The suggested default is also 3. The second section: Contains a list of ASNs, peer IPs, or Neighbor Classes to which the originator of this community wishes its peer to prepend its ASN. 7.5. The BGP VPN Communities These communities are used mostly for BGP MPLS VPN's. Please see RFC2547 [RFC2547] for more detail on how these VPNs are constructed. Name: ROUTE_TARGET Type Code: 0x0005 Can Take Structures: 0x02 (IPv4), 0x03 (IPv6) Transitive: Transitive or Non-Transitive Min Length of Value Field: 4 octets Max Length of Value Field: 254 octets Behavior: The Value Field of this community represents a list of the IP addresses where this route is to be announced. Name: ROUTE_ORIGIN Type Code: 0x0006 Can Take Structures: 0x02 (IPv4), 0x03 (IPv6) Transitive: Transitive or Non-Transitive Min Length of Value Field: 4 octets Max Length of Value Field: 16 octets Lange [Page 13] INTERNET DRAFT December 2002 Behavior: The Value Field of this community represents a list of the IP address where this route is originated. This community can only contain one IP address. Name: LINK_BANDWIDTH Type Code: 0x0007 Can Take Structures: 0x00 (opaque), Ox01 (ASN) Transitive: Transitive or Non-Transitive Min Length of Value Field: 4 octets Max Length of Value Field: 6 octets Behavior: This community consists of two parts: The first part represents the bandwidth of the link in bits-per- second, encoded in IEEE floating point format. This part is 4 octets long. The second part consists of a list of ASNs of the peer whose link bandwidth you wish to propagate. 8. New Capability Code for Flexible Communities To ensure compatibility between implementations that may or may not implement this protocol extension, this document defines a new capability. Capability Code: TBD Capability Length: 1 Capability Value: 0x00 for unsupported 0x01 for supported Capability negotiation is especially important for this attribute because we are creating a transitivity action within an optional, transitive attribute. If an implementation sends a flexible community with the non-transitive bit set within the community to a router that does not support flexible communities, that router will send the community on to its peers when it should not do so. 9. Aggregation Aggregation behaves the same as with other community types. By default if a range of routes is to be aggregated and the resultant aggregates path attributes do not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate should have an Flexible Communities path attribute which contains the set union of all the Flexible Communities from all of the aggregated routes. The default Lange [Page 14] INTERNET DRAFT December 2002 behavior could be overridden via local configuration, in which case handling the Flexible Communities attribute in the presence of route aggregation becomes a matter of the local policy of the BGP speaker that performs the aggregation. 10. Operations Flexible Communities are handled operationally in a manner very similar to other community values. A BGP speaker may use the Flexible Communities attribute to control which routing information it accepts or distributes to its peers. The Flexible Community attribute MUST NOT be used to modify the BGP best path selection algorithm in a way that leads to forwarding loops. A BGP speaker receiving a route that doesn't have the Flexible Commu- nities attribute MAY append this attribute to the route when propagating it to its peers. A BGP speaker receiving a route with the Flexible Communities attribute MAY modify this attribute according to the local policy. If a route has a non-transitivity flexible community, then before advertising the route across the Autonomous system boundary the community SHOULD be removed from the route. However, the community SHOULD NOT be removed when advertising the route across the BGP Confederation boundary. A route may carry the BGP Communities attribute as defined in [RFC1997]), the Extended BGP Communities attribute as defined in [EX- COMM], and the Flexible Communities attribute. In this case the BGP Communities attribute is handled as specified in [RFC1997], the Extended BGP Communities attribute is handled as specified in [EX- COMM], and the Flexible Communities attribute is handled as specified in this document. If older community types are present in addition to the flexible community there is the possibility that the information contained may be redundant. Although effort should be made to avoid this situation, if it does occur the BGP Speaker shall prefer the flexible community first, then the extended community second and then the base community. 11. Security Considerations This extension to BGP does not change the underlying security issues. Lange [Page 15] INTERNET DRAFT December 2002 12. IANA Considerations The values for the Transitivity Field (1 or 0) are completely defined in this document. The assignment policy for the Structure Field is: o The "L" bit's usage is completely defined in this document. o Values of the Structure Field where the "L" bit is "0" are to be assigned in accordance with the Private Use policy outlined in RFC2434 [RFC2434]. o Values of the Structure Field where the "L" bit is "1" defined in this document are: 0-4 (0x40-0x44 and 0xC1-0xC4). Remaining values in this range are to be assigned using the IETF Consensus policy outlined in RFC2434 [RFC2434]. The assignment policy for the Type Field is: o The "L" bit's usage is completely defined in this document. o Values of the Type Field where the "L" bit is "0" are to be assigned in accordance with the Private Use policy outlined in RFC2434 [RFC2434]. o Values of the Type Field where the "L" but is "1" defined in this document are: 0-7 (0x0000-0x0007). Remaining values in this range are to be assigned using the IETF Consensus policy outlined in RFC2434 [RFC2434]. The assignment policy for Neighbor Classes is: o The "L" bit's usage is completely defined in this document. o Values of the Type Field where the "L" bit is "0" are to be assigned in accordance with the Private Use policy outlined in RFC2434 [RFC2434]. o Values of the Type Field where the "L" but is "1" defined in this document are: 0-4 (0x8000-0x8004). Remaining values in this range are to be assigned using the IETF Consensus policy outlined in RFC2434 [RFC2434]. 13. References [RFC1771] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC1997] Chandra, R., Traina, P., Li, T., "BGP Communities Attribute", RFC 1997, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998 Lange [Page 16] INTERNET DRAFT December 2002 [RFC2547] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March 1999. [RFC2842] Chandra, R., Scudder, J., "Capabilities Advertisement with BGP-4", RFC 2842, May 2000. [EX-COMM] Sangli, S., Tappan, D., Rekhter, Y., "BGP Extended Communities Attribute", draft-ietf-idr-bgp-ext-communities-05.txt, work-in-progress, expires November, 2002. [NOPEER] Huston, G., "NOPEER community for BGP route scope control", draft-ietf-ptomaine-nopeer-00.txt, work-in-progress, expires October, 2002. [REDIST] Bonaventure, O., et. al., "Controlling the redistribution of BGP routes", draft-ietf-ptomaine-redistribution-01.txt, work-in- progress, expires February, 2003. 14. Acknowledgements I would like to thank Tom Barron, Dave Ward and especially Hal Peterson for their valuable comments and feedback. 15. Author's Address: Andrew Lange Alcatel 274 Ferguson Drive Mountain View, CA 94043 andrew.lange@alcatel.com Lange [Page 17] --==========F9F1C055D554AA970B14==========-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA00309 for ; Tue, 2 Mar 2004 22:54:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNSL-0001z4-E9; Tue, 02 Mar 2004 22:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNRO-0001xi-11 for idr@optimus.ietf.org; Tue, 02 Mar 2004 22:53:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27038 for ; Tue, 2 Mar 2004 22:52:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyNRK-0006Cd-00 for idr@ietf.org; Tue, 02 Mar 2004 22:52:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyNQL-00063d-00 for idr@ietf.org; Tue, 02 Mar 2004 22:51:58 -0500 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx with esmtp (Exim 4.12) id 1AyNPQ-0005nH-00 for idr@ietf.org; Tue, 02 Mar 2004 22:51:00 -0500 Received: (qmail 6411 invoked by uid 211); 3 Mar 2004 03:50:44 -0000 Received: from 166-205-011-063.mobile.attwireless.net (HELO ?10.120.130.82?) (vgill@166.205.11.63) by challah.msrl.com with DES-CBC3-SHA encrypted SMTP; 3 Mar 2004 03:50:44 -0000 From: vijay gill To: Pedro Roque Marques cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) Message-ID: <2147483647.1078182303@[10.88.104.252]> In-Reply-To: <200403020041.i220fwFm050173@roque-bsd.juniper.net> References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> <200403020025.i220PI9P050138@roque-bsd.juniper.net> <20040302003314.GA6255@vijaygill.com> <200403020041.i220fwFm050173@roque-bsd.juniper.net> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 23:05:03 -0500 --On Monday, March 1, 2004 16:41 -0800 Pedro Roque Marques wrote: > vijay gill writes: > >> On Mon, Mar 01, 2004 at 04:25:18PM -0800, Pedro Roque Marques wrote: >>> Pekka Savola writes: >>> >>> i'll repeat it: - How can you prove that a given path that is >>> learned by BGP is loop free ? - That can only be done if >>> forwarding follows routing. > >> I feel that BGP should only be concerned about creating loop free >> topologies. If the user then has a mechanism where the forwarding >> does not follow the routing properly and causes a loop (this is an >> important distinction), then this is their problem. I can always >> point a static back up a link if I so want and nothing bgp can do >> about it. > > Your argument assumes that the user always knows that is configuring a > situation that may create forwarding loops... > > That may not be the case. It may come from a configuration > mistake... > > imho, the default approach for the protocol spec is to choose the most > graceful failure model possible torwards loop-free forwarding... Pedro, I still don't understand why BGP must care about statics or other protocols that may or may not be misconfigured. For some reason I may want to create a forwarding loop (for example, in my lab) to see what the router does. Actually, to be more specific, there are valid operational reasons for sometimes routing information away from where BGP points you, load balancing on congested peerings for example. Not very elegant, but these cases do exist. If a vendors BGP implementation does not allow me to have the final say as to where I want to place traffic, I _will_ be extremely irate. > >>> Proof: configure a static route for a given prefix in a border >>> router that points to a BGP neighbor that selects this router as >>> best path... watch permanent forwarding loops. > >> Yes, and this is a not a matter for BGP to worry about. > > I respectfully disagree. that is fine. but as we all know, the final arbiter of features is the account team, back up by P.O.s /vijay > > Pedro. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA00307 for ; Tue, 2 Mar 2004 22:54:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNSM-0001zD-1v; Tue, 02 Mar 2004 22:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNRO-0001xp-KY for idr@optimus.ietf.org; Tue, 02 Mar 2004 22:53:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27041 for ; Tue, 2 Mar 2004 22:52:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyNRL-0006Ci-00 for idr@ietf.org; Tue, 02 Mar 2004 22:52:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyNQM-00063l-00 for idr@ietf.org; Tue, 02 Mar 2004 22:51:59 -0500 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx with esmtp (Exim 4.12) id 1AyNPQ-0005tB-00 for idr@ietf.org; Tue, 02 Mar 2004 22:51:00 -0500 Received: (qmail 6414 invoked by uid 211); 3 Mar 2004 03:50:54 -0000 Received: from 166-205-011-063.mobile.attwireless.net (HELO ?10.120.130.82?) (vgill@166.205.11.63) by challah.msrl.com with DES-CBC3-SHA encrypted SMTP; 3 Mar 2004 03:50:54 -0000 From: vijay gill To: Pedro Roque Marques cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) Message-ID: <2147483647.1078183926@[10.88.104.252]> In-Reply-To: <200403020041.i220fwFm050173@roque-bsd.juniper.net> References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> <200403020025.i220PI9P050138@roque-bsd.juniper.net> <20040302003314.GA6255@vijaygill.com> <200403020041.i220fwFm050173@roque-bsd.juniper.net> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 23:32:08 -0500 --On Monday, March 1, 2004 16:41 -0800 Pedro Roque Marques wrote: > vijay gill writes: > >> On Mon, Mar 01, 2004 at 04:25:18PM -0800, Pedro Roque Marques wrote: >>> Pekka Savola writes: >>> >>> i'll repeat it: - How can you prove that a given path that is >>> learned by BGP is loop free ? - That can only be done if >>> forwarding follows routing. > >> I feel that BGP should only be concerned about creating loop free >> topologies. If the user then has a mechanism where the forwarding >> does not follow the routing properly and causes a loop (this is an >> important distinction), then this is their problem. I can always >> point a static back up a link if I so want and nothing bgp can do >> about it. > > Your argument assumes that the user always knows that is configuring a > situation that may create forwarding loops... > > That may not be the case. It may come from a configuration > mistake... > > imho, the default approach for the protocol spec is to choose the most > graceful failure model possible torwards loop-free forwarding... >imho, the default approach for the protocol spec is to choose the most >graceful failure model possible torwards loop-free forwarding... Pedro, I still don't understand why BGP must care about statics or other protocols that may or may not be misconfigured. For some reason I may want to create a forwarding loop (for example, in my lab) to see what the router does. Actually, to be more specific, there are valid operational reasons for sometimes routing information away from where BGP points you, load balancing on congested peerings for example. Not very elegant, but these cases do exist. If a vendors BGP implementation does not allow me to have the final say as to where I want to place traffic, I _will_ be extremely irate. If you only consider BGP, then it should do loop-free routing, absolutely. I just do not want BGP to be looking into static configurations and trying to do my thinking for me. This leads to anger and anger leads to the dark side. etc etc. > >>> Proof: configure a static route for a given prefix in a border >>>router that points to a BGP neighbor that selects this router as >>>best path... watch permanent forwarding loops. > >>Yes, and this is a not a matter for BGP to worry about. > >I respectfully disagree. that is fine. but as we all know, the final arbiter of features is the account team, backed up by P.O.s no matter what the IETF would like to believe. /vijay > > Pedro. > >_______________________________________________ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA28855 for ; Tue, 2 Mar 2004 20:35:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLHs-0001YU-GS; Tue, 02 Mar 2004 20:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLGz-0001SD-SL for idr@optimus.ietf.org; Tue, 02 Mar 2004 20:34:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18462 for ; Tue, 2 Mar 2004 20:34:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLGx-0007lq-00 for idr@ietf.org; Tue, 02 Mar 2004 20:34:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLGD-0007Zf-00 for idr@ietf.org; Tue, 02 Mar 2004 20:33:22 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AyLEl-00074K-00 for idr@ietf.org; Tue, 02 Mar 2004 20:31:51 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i231VFi13770 for ; Tue, 2 Mar 2004 20:31:15 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Mar 2004 20:31:15 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A5AECCB@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: idr@ietf.org Subject: RE: [Idr] FW: IDR minutes MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 20:31:14 -0500 hi I believe we also briefly discussed setting up a call to discuss the v2 MIB and that interested parties should contact either Sue or myself. Sharon -----Original Message----- From: Susan Hares [mailto:shares@nexthop.com] Sent: Monday, March 01, 2004 10:40 PM To: idr@ietf.org Subject: [Idr] FW: IDR minutes Minutes for 3/1/04 session -----Original Message----- From: Jake Khuon Sent: Monday, March 01, 2004 3:18 AM To: Susan Hares; yakov@juniper.net Subject: IDR minutes Inter-Domain Routing WG (idr) Monday, March 1 at 1530-1730 ================================== CHAIRS: Sue Hares (skh@nexthop.com) Yakov Rekhter (yakov@juniper.net) AGENDA: 1) Agenda Bashing Agenda Slides 2) Document status [5 minutes] - Bundle went to IESG BGP-4 draft-23 draft-ietf-idr-bgp4-23.txt BGP-4 V1 MIB draft-ietf-idr-bgp4-mib-13.txt BGP-4 Protocol Analysis draft-ietf-idr-bgp-analysis-04.txt BGP Security Vulnerabilities Analysis draft-ietf-idr-bgp-vuln-00.txt Experience with the BGP-4 Protocol draft-ietf-idr-bgp4-experience-protocol-03.txt BGP 4 Implementation Report draft-ietf-idr-bgp-implementation-00.txt BGP-4 V1 MIB implementation report draft-ietf-idr-bgp-mibagent-survey-01.txt Presentation 3) Implementation Reports and FSM issues for current drafts [10 minutes] document: None, presentation only Presentation Sue Hares - Yakov: route-reflector update status? - Enke: route-reflector update (4 weeks) - Enke: prefix-orf was not added to charter - Sue: yes it was added, administrative error in listing 4) BGP Peer Restart Backoff Mechanisms [10 minutes] document: draft-hares-bgp-backoff-01.txt (ietf) (-02 Update) Author: Susan Hares Presentation Sue Hares - Alex: draft should say informational achieve functionality using existing states? - Sue: no... can't use existing states; already investigated that option 5) Deterministic Route Redistribution into BGP [10 minutes] document: draft-chen-bgp-redist-00.txt Authors: Jenny Yuan, Enke Chen Enke Chen - Andrew Lang: used to use configured localpref tweaking; not management intensive... unsure if this is needed - Enke: timing dependent non-deterministic problem so current knobs cannot be used reliably; does not break anything... backwards compatible - Andrew Lang: better to educate people about localpref - Barry Friedman: lacks generality too narrow a problem space... only addresses RIP/iBGP interaction - Enke: tweaking of admin distance defines a baseline - need per route granularity to solve for all cases? Possibility of adding more configuration conflicts. - Alex: this problem only occurs if there's a consistancy issue between two places... May not be an issue for a single selection point. Introduction of new step will effect current edployment traffic selection? - Enke: This will happen regardless. Should not effect current deployments and if there's a change, the change will be for the better. - By definition, it does change behaviour. - Alex: Will this be applicable to only situations where there is a problem? - Yakov: Is this an implimentation method? - Alex: Is this informational or standards-track? - Enke: Either is fine - It can't be a local matter because it must be consistant throughout the entire system - Enke: Decision on redistributed routes is made locally in each router - Behaviour is changed because new code now uses admin distance over localpref? - Enke: If only localpref is used then things should not change - Cengiz: If route-reflector is used? - Enke: I need to think about it further 6) BGP based auto-discovery [Sue Hares, P. Unbehagen] [10 minutes] document: draft-hlmu-l2vpn-bgp-discovery-00.txt authors: P. Unbehagen, P. Muley, V. Radoaca, Susan Hares Presentation Sue Hares, P. Unbehagen - Already a L2VPN draft that addresses this in a defined NLRI with label information - Paul: This draft is meant to provide LDP pseudowire config information - Other spec can do same thing [autodiscovery] without label information - Kireeti: Would like to be able to use this AFI with different SAFI [65] and NLRI format - Would the two SAFIs be solving similar problems - Kireeti: My SAFI solves different problems 7) BGP Assignment of AFI/SAFI address [10 minutes] Document: draft-hares-bgp-assign-afisafi-00.txt Author: Susan Hares Presentation Sue Hares 8) BGP Attribute Codes and Suggested Procedures Document: draft-kompella-zinin-early-allocation-00.txt Author: Alex Zinin, Kireeti Kompella Presentation Alex Zinin - Sharon: talking about protocols and not OIDs preallocation? bad to preallocate in the MIB... different from what other WGs; exclude MIB OIDs - Kireeti: not suggesting that everyone use this - It would have been nicer to have had OIDs preallocated so as not to reimpliment the MIB - Sharon: OIDs not allocated to drafts because if the drafts goes away then you've wasted numbers - Lou Berger: allocation with 1 year with 1 renewal is too short; alterntate policy: as long as draft or version is alive, expire in 3 to 6 months - Alex: that suggestion ties validity with ability of author to submit the draft; suggestion: once document is submitted to IESG then we freeze. Don't want to allocate codepoints too early. - Dave Meyer: Are you sure that IANA can time anything out - Alex: No - Dave Meyer: WG chair needs to manage this? - What happens if the allocation is not renewed and code is using it still? - Alex: Add provision to document to deprecate but not return - Kireeti: Deprecate for a period of time to give people time to remove. Formal process to do early allocations and if it goes through then stick with it but if it doesn't go through then people must take this out. - Dino: Allocate experimental codepoints and once standardised, then adopt standard codepoint for sending but accept both. - Sue: Good for SAFIs as well as AFIs? - Dino: All well known IANA values - Fenner: RFC already documents a process for transitioning codepoints 9) Charter Discussion [20 minutes] Thanks to all implementers who send in reports on the the base specification, we will be opening the charter. This section of the meeting will discuss what items will be added to the charter. Presentation - Top three most important; maybe ECMP little higher than Fault Isolation -- /*==================[ Jake Khuon ]=====================+ | Field App. Engineer http://www.nexthop.com/ /\ /~ E X T H O P | | Ofc: +1 (425) 391-2262 Fax: +1 (425) 391-6772 / \/ Technologies, Inc.| +==========[ 1911 Landings Drive, Mountain View, CA 94043 USA ]===========*/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA27625 for ; Tue, 2 Mar 2004 18:20:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJBE-0005We-Uw; Tue, 02 Mar 2004 18:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJAR-0005HS-6L for idr@optimus.ietf.org; Tue, 02 Mar 2004 18:19:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08114 for ; Tue, 2 Mar 2004 18:19:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyJAN-0001D1-00 for idr@ietf.org; Tue, 02 Mar 2004 18:19:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyJ9L-00011a-00 for idr@ietf.org; Tue, 02 Mar 2004 18:18:08 -0500 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx with esmtp (Exim 4.12) id 1AyJ8a-0000rs-00 for idr@ietf.org; Tue, 02 Mar 2004 18:17:20 -0500 Received: (qmail 27420 invoked by uid 1021); 2 Mar 2004 23:17:11 -0000 From: vijay gill To: Pedro Roque Marques Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) Message-ID: <20040302231711.GC21017@vijaygill.com> References: <40442200.3030904@cisco.com> <200403020645.i226jiF4050962@roque-bsd.juniper.net> <20040302153406.GA5590@vijaygill.com> <200403022247.i22MlJXN052561@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403022247.i22MlJXN052561@roque-bsd.juniper.net> User-Agent: Mutt/1.3.28i Organization: vijay gill global logistics X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 23:17:11 +0000 On Tue, Mar 02, 2004 at 02:47:19PM -0800, Pedro Roque Marques wrote: > When you receive a BGP advertisement from a neighbor, do you expect > traffic sent to that neighbor to follow the ASes that are present in > the corresponding routing advertisement ? Yes, but right now, nothing prevents that person from putting a static up that points any traffic I send to that AS right back out the current pipe. I am saying is that you are trying to solve a problem which a) isn't a huge thing in practice and b) _cannot_ be solved. > Is it a 'feature' or a 'bug' if traffic doesn't follow the path > advertised by routing... it is a bug obviously, but insofar as BGP knows, it is setting up a correct loop-free graph and it really should restrict itself to doing that, as opposed to trying to figure out all the myriad ways traffic can go wrong. > This is an issue that exists today... and not strictly related to the > advertisement of inactive paths. I believe CAIDA has made measurements > of such inconsistencies. I think we need more results from randy's happy packets research. > But while it is easy for all of us to say "i'd like to be able to do > whatever i want" a more interesting question is "what i would like > others to contrain themselfs to"... But I don't worry how say, my bgp peers AS routes traffic internally. It is not within my bailiwick to worry about it, they could be using statics for all I care. my concern is that they send me an accurate prefix set that they are transiting and I give them traffic for that prefix set. I think we are starting to loop here. /vijay _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA27338 for ; Tue, 2 Mar 2004 17:50:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyIiB-00044C-3A; Tue, 02 Mar 2004 17:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyIhw-00043g-D1 for idr@optimus.ietf.org; Tue, 02 Mar 2004 17:49:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05703 for ; Tue, 2 Mar 2004 17:49:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyIht-0004zq-00 for idr@ietf.org; Tue, 02 Mar 2004 17:49:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyIgv-0004tH-00 for idr@ietf.org; Tue, 02 Mar 2004 17:48:46 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AyIg1-0004gy-00 for idr@ietf.org; Tue, 02 Mar 2004 17:47:49 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i22MlJ1K052564; Tue, 2 Mar 2004 14:47:19 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i22MlJXN052561; Tue, 2 Mar 2004 14:47:19 -0800 (PST) Message-Id: <200403022247.i22MlJXN052561@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: vijay gill Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: <20040302153406.GA5590@vijaygill.com> References: <40442200.3030904@cisco.com> <200403020645.i226jiF4050962@roque-bsd.juniper.net> <20040302153406.GA5590@vijaygill.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 14:47:19 -0800 (PST) vijay gill writes: > What BGP does should be separate from anything else. You have the > bgp database, operate on the BGP database. Pick routes, only look to > see if you have a valid next-hop, and then continue on. Vijay, I'm sure that your view as its merits... but we also need to consider the question the other way around. When you receive a BGP advertisement from a neighbor, do you expect traffic sent to that neighbor to follow the ASes that are present in the corresponding routing advertisement ? Do you make any assumptions based on the contents of such as-path attribute ? Is it a 'feature' or a 'bug' if traffic doesn't follow the path advertised by routing... This is an issue that exists today... and not strictly related to the advertisement of inactive paths. I believe CAIDA has made measurements of such inconsistencies. But while it is easy for all of us to say "i'd like to be able to do whatever i want" a more interesting question is "what i would like others to contrain themselfs to"... Disabling the advertisement of inactive routes is not a panacea that will address all inconsistencies, assuming one does care about those... Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA26000 for ; Tue, 2 Mar 2004 15:44:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyGkD-0008FD-0O; Tue, 02 Mar 2004 15:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyC5O-0007z5-Qp for idr@optimus.ietf.org; Tue, 02 Mar 2004 10:45:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16029 for ; Tue, 2 Mar 2004 10:45:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyC5K-0000bc-00 for idr@ietf.org; Tue, 02 Mar 2004 10:45:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyC4M-0000Uk-00 for idr@ietf.org; Tue, 02 Mar 2004 10:44:30 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AyC3M-0000JQ-00 for idr@ietf.org; Tue, 02 Mar 2004 10:43:29 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i22Fg3kL083856; Tue, 2 Mar 2004 10:42:03 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403021542.i22Fg3kL083856@workhorse.fictitious.org> To: Pedro Roque Marques cc: Pekka Savola , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: Your message of "Mon, 01 Mar 2004 17:56:09 PST." <200403020156.i221u9jf050325@roque-bsd.juniper.net> From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Mar 2004 10:42:03 -0500 In message <200403020156.i221u9jf050325@roque-bsd.juniper.net>, Pedro Roque Mar ques writes: > Pekka Savola writes: > > > My interpretation of the spec (and a vendor's, as well) is that this > > is not considered at all in the current spec. And if we disagree, > > it calls for EVEN MORE LOUDLY for a clarification! > > [...] > > > No -- the current spec is just looking up a route -- it takes no > > stance what kind of 'route' that is. > > By your own admission the spec doesn't require clarification. It is > clear that it doesn't understand the next-hop type of a route. > > > This needs to be specified. > > What you mean by this is that you believe that the current behaviour > should be modified... > > Even if we where to agree that the behaviour you and Curtis propose is > more desirable than the current one, it isn't feasible to modify the > behaviour of current systems. > > The modification you propose also isn't suficient to address the > problem that you point out whenever your aggregate route has a > reachable next-hop. > > Examples where this could happen: > > - User wants to forward all traffic that hits the default route to a > remote box that analyzes traffic... i.e. 0/0 to an LSP to a traffic > collector. That's a default route that forwards traffic, not a discard route. > - Network is divided in areas but has global IGP. Each area border > generates a summary of address in the are that is propagated across > the network. i.e. outside the area you see an aggregate via BGP and > more specific /32s. That route also forwards traffic. It is not a discard route. On the aggregator itself, there had better be a more specific route or if not the routes should be considered infeasible. If the aggregator which also happens to be an EIBGP router where confederations are used then the aggregator is also passing the BGP routes from the border router that went down. When the hole in the aggregate occurs if the discard route is allowed to pass the reachability test, then the BGP routes remain in the rest of the AS until the BGP session times out - a very long time. This quite obviously is bad for SLAs and if some of those routes had alternates there might be some unhappy customers (you could also argue that if they didn't have alternates they'd be even more unhappy). If the discard does not cause the reachability test to pass, then the BGP routes advertised by the border router that went down go down in IGP time (seconds and possibly sub-second - YMMV). An occasional fault and recovery in seconds doesn't violate most SLAs and customers also don't see substantial impact. If the IGP aggregates, as it does in OSPF areas, but the aggregators are not either RRs or confed boundaries, then the test for reachability does not occur on the aggregator and that can be a problem. The only current solution is to not aggregate the addresses used for the infrastructure within the AS, but aggregate those prefixes outside the AS. There really is not alternative. Once the aggregate is formed information is lost that is needed to quickly withdraw the routes due to the reachability change. This is certainly a topic for a BCP but we don't need to put anything in the BGP spec. ... that said, I think I'll go back and check our implementation. > Pedro. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA24310 for ; Tue, 2 Mar 2004 12:58:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyE9b-0005mW-7T; Tue, 02 Mar 2004 12:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyE9I-0005hL-KG for idr@optimus.ietf.org; Tue, 02 Mar 2004 12:57:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21205 for ; Tue, 2 Mar 2004 12:57:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyE9G-0002d7-00 for idr@ietf.org; Tue, 02 Mar 2004 12:57:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyE8P-0002WK-00 for idr@ietf.org; Tue, 02 Mar 2004 12:56:49 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AyE87-0002OO-00 for idr@ietf.org; Tue, 02 Mar 2004 12:56:32 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i22Hts1K052101; Tue, 2 Mar 2004 09:55:54 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i22HtsCp052098; Tue, 2 Mar 2004 09:55:54 -0800 (PST) Message-Id: <200403021755.i22HtsCp052098@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: gargi@cisco.com Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: <40443AA7.2010804@cisco.com> References: <40442200.3030904@cisco.com> <200403020645.i226jiF4050962@roque-bsd.juniper.net> <40443AA7.2010804@cisco.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 09:55:54 -0800 (PST) Gargi Nalawade writes: >> >> My time to ask for a clarification... >> >> It seems that you are saying that: >> >> 1) when the nexthop of a BGP route doesn't match the forwarding >> nexthop selected in the routing table that BGP should not advertise >> the route. In your words "it breaks routing", or it has the >> potential to do so. >> >> 2) If the next-hop does match, BGP should advertise its route, even >> if less preferred. > yes & yes. Thanks. You should probably write an Internet-Draft that describes that behaviour then. >> A second question would be how do you define 'next-hop matching' in >> the context of an iBGP route vs an IGP route. > Am I missing what you are trying to say? You have two routes for the same prefix. i.e. 10.0.1/24 OSPF nexthop 1 10.0.1/24 iBGP nexthop 2 What do you consider nexthop to be... i.e. in terms of iBGP is 'next-hop' the NEXT_HOP BGP attribute as advertised by the remote peer ? Or is this a directly connected next-hop obtained via route resolution. It would be nice to have the answer to that question, in case you do decide to write an I-D. regards, Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA23022 for ; Tue, 2 Mar 2004 10:36:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBwB-0006m0-8t; Tue, 02 Mar 2004 10:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBvl-0006kt-8x for idr@optimus.ietf.org; Tue, 02 Mar 2004 10:35:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15409 for ; Tue, 2 Mar 2004 10:35:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBvi-00076a-00 for idr@ietf.org; Tue, 02 Mar 2004 10:35:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBun-00070T-00 for idr@ietf.org; Tue, 02 Mar 2004 10:34:38 -0500 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx with esmtp (Exim 4.12) id 1AyBuR-0006uE-00 for idr@ietf.org; Tue, 02 Mar 2004 10:34:15 -0500 Received: (qmail 6547 invoked by uid 1021); 2 Mar 2004 15:34:06 -0000 From: vijay gill To: Pedro Roque Marques Cc: gargi@cisco.com, idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) Message-ID: <20040302153406.GA5590@vijaygill.com> References: <40442200.3030904@cisco.com> <200403020645.i226jiF4050962@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403020645.i226jiF4050962@roque-bsd.juniper.net> User-Agent: Mutt/1.3.28i Organization: vijay gill global logistics X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 15:34:06 +0000 What BGP does should be separate from anything else. You have the bgp database, operate on the BGP database. Pick routes, only look to see if you have a valid next-hop, and then continue on. If you have an identical route that is more preferred by whatever mechanism that does the 'pick what route to install in the forwarding table' why does this affect bgp. This leads to things like advertise-inactive and each time there is a new install of a juniper box, you have to write a paragraph on advertise-inactive and why it is needed. I've done this for too many jnx qual docs and it is starting to annoy the @#$# out of me. I am fully willing to change my opinion but I've long maintained that each routing protocol should have its own tables and it is up to the user to ensure that they are topologically sane. /vijay _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA22814 for ; Tue, 2 Mar 2004 10:18:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBej-0004q3-8V; Tue, 02 Mar 2004 10:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBeJ-0004jo-R6 for idr@optimus.ietf.org; Tue, 02 Mar 2004 10:17:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14381 for ; Tue, 2 Mar 2004 10:17:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBeH-0004ll-00 for idr@ietf.org; Tue, 02 Mar 2004 10:17:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBdK-0004g4-00 for idr@ietf.org; Tue, 02 Mar 2004 10:16:35 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AyBd2-0004Zi-00 for idr@ietf.org; Tue, 02 Mar 2004 10:16:16 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 88A8C2D4957; Tue, 2 Mar 2004 10:15:45 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 57139-01-96; Tue, 2 Mar 2004 10:15:44 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 8A35F2D4965; Tue, 2 Mar 2004 10:15:44 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i22FFiw03346; Tue, 2 Mar 2004 10:15:44 -0500 (EST) From: Jeffrey Haas To: curtis@fictitious.org Cc: Pekka Savola , idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes Message-ID: <20040302101544.A3266@nexthop.com> References: <20040301192732.A21492@nexthop.com> <200403020140.i221eqRX077993@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200403020140.i221eqRX077993@workhorse.fictitious.org>; from curtis@workhorse.fictitious.org on Mon, Mar 01, 2004 at 08:40:52PM -0500 X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 10:15:44 -0500 On Mon, Mar 01, 2004 at 08:40:52PM -0500, Curtis Villamizar wrote: > If A installs the discard route but not both components, then A's > implementation of aggregation is broken. The installation of the more specifics was presumed. I was talking about BGP aggregation. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA19071 for ; Tue, 2 Mar 2004 02:46:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4bK-00014c-3D; Tue, 02 Mar 2004 02:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4b3-00013J-91 for idr@optimus.ietf.org; Tue, 02 Mar 2004 02:45:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23477 for ; Tue, 2 Mar 2004 02:45:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4az-0000IB-00 for idr@ietf.org; Tue, 02 Mar 2004 02:45:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4Zo-00001I-00 for idr@ietf.org; Tue, 02 Mar 2004 02:44:30 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4Xz-0007BN-00 for idr@ietf.org; Tue, 02 Mar 2004 02:42:35 -0500 Received: from cisco.com (hkidc-vpn-client-234-5.cisco.com [10.75.234.5]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i227fSD1017579; Mon, 1 Mar 2004 23:41:29 -0800 (PST) Message-ID: <40443AA7.2010804@cisco.com> From: Gargi Nalawade Reply-To: gargi@cisco.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pedro Roque Marques CC: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) References: <40442200.3030904@cisco.com> <200403020645.i226jiF4050962@roque-bsd.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 23:41:27 -0800 Pedro Roque Marques wrote: > Gargi Nalawade writes: > > >>Now that I understand your request for modification & clarification >>better, I think it makes sense. It would be good to clarify in the >>spec. > > >>If there is no operator here who can think of a reason why they may >>want to explicitly prohibit BGP from advertising a route it doesnt own, >>even when the nexthop matches that in the forwarding table, we should >>make the other behavior (i.e. advertise even if BGP doesnt own the route >>when the nexthop matches) the recommended one, stating the currently >>stated but least used behavior as an optional alternative. > > > My time to ask for a clarification... > > It seems that you are saying that: > > 1) when the nexthop of a BGP route doesn't match the forwarding > nexthop selected in the routing table that BGP should not advertise > the route. In your words "it breaks routing", or it has the potential > to do so. > > 2) If the next-hop does match, BGP should advertise its route, even if > less preferred. yes & yes. > A second question would be how do you define 'next-hop matching' in > the context of an iBGP route vs an IGP route. Why should iBGP vs IGP come into play? The BGP bestpath calculation would have already given us the best BGP route. If this BGP route (BGP's bestpath) loses to an IGP route with a lower admin-distance then BGP decides whether or not advertise this BGP route. But a BGP bestpath cannot lose to an iBGP route in the routing-table. Because that iBGP route wont be the BGP bestpath. Then why does losing to an iBGP route come into play when it comes to advertising a BGP bestpath? Am I missing what you are trying to say? -Gargi > > regards, > Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA18593 for ; Tue, 2 Mar 2004 01:49:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3iA-0001Tc-DN; Tue, 02 Mar 2004 01:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3hV-0001Jb-Ex for idr@optimus.ietf.org; Tue, 02 Mar 2004 01:48:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06743 for ; Tue, 2 Mar 2004 01:48:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3hS-00006n-00 for idr@ietf.org; Tue, 02 Mar 2004 01:48:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay3gT-0007mp-00 for idr@ietf.org; Tue, 02 Mar 2004 01:47:18 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1Ay3fY-0007aH-00 for idr@ietf.org; Tue, 02 Mar 2004 01:46:20 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i226ji1K050965; Mon, 1 Mar 2004 22:45:44 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i226jiF4050962; Mon, 1 Mar 2004 22:45:44 -0800 (PST) Message-Id: <200403020645.i226jiF4050962@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: gargi@cisco.com Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: <40442200.3030904@cisco.com> References: <40442200.3030904@cisco.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 22:45:44 -0800 (PST) Gargi Nalawade writes: > Now that I understand your request for modification & clarification > better, I think it makes sense. It would be good to clarify in the > spec. > If there is no operator here who can think of a reason why they may > want to explicitly prohibit BGP from advertising a route it doesnt own, > even when the nexthop matches that in the forwarding table, we should > make the other behavior (i.e. advertise even if BGP doesnt own the route > when the nexthop matches) the recommended one, stating the currently > stated but least used behavior as an optional alternative. My time to ask for a clarification... It seems that you are saying that: 1) when the nexthop of a BGP route doesn't match the forwarding nexthop selected in the routing table that BGP should not advertise the route. In your words "it breaks routing", or it has the potential to do so. 2) If the next-hop does match, BGP should advertise its route, even if less preferred. A second question would be how do you define 'next-hop matching' in the context of an iBGP route vs an IGP route. regards, Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA18235 for ; Tue, 2 Mar 2004 00:59:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2vn-0002x8-Ag; Tue, 02 Mar 2004 00:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2vL-0002vq-6Q for idr@optimus.ietf.org; Tue, 02 Mar 2004 00:58:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04447 for ; Tue, 2 Mar 2004 00:58:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2vI-0001oe-00 for idr@ietf.org; Tue, 02 Mar 2004 00:58:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2uO-0001gJ-00 for idr@ietf.org; Tue, 02 Mar 2004 00:57:37 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2tr-0001YT-00 for idr@ietf.org; Tue, 02 Mar 2004 00:57:03 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 01 Mar 2004 21:56:30 -0800 Received: from cisco.com (hkidc-vpn-client-234-19.cisco.com [10.75.234.19]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i225uID1027841; Mon, 1 Mar 2004 21:56:19 -0800 (PST) Message-ID: <40442200.3030904@cisco.com> From: Gargi Nalawade Reply-To: gargi@cisco.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Pedro Roque Marques , idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 21:56:16 -0800 Pekka Savola wrote: > On Mon, 1 Mar 2004, Gargi Nalawade wrote: > >>For this case - there is no problem. Some implementations can already >>do this. But again there are operators who want the opposite behavior >>as well. i.e. BGP should not advertise a route if it is not the owner >>even if the BGP nexthop is the same as that of the route in the >>forwarding table. > > > Really? I'm having problems figuring out where this would be desired > behaviour. Im trying to hunt for the usage if this as well. So if anyone knows of a reason, let us know. I have only heard 3rd & 4th hand requirements so far where the source has either moved on or no longer exists. >>Both behaviors are achieved today by various imple- >>mentations even though the default may vary from vendor to vendor. > > > Yep. > > >>Again - time for a clarification. :) Are you asking for that the >>behavior be present or that the spec be changed to describe both >>behaviors? > > > I think the specification should, very clearly, state just one > recommended behaviour, and possibly describe an optional other > behaviour. I think the recommended behaviour should be what I > proposed, and you also described. Because that's actually what > happens very often. > > But if there is strong objection to this very clear statement of > behaviour (or "modification"), also spelling out the alternative is > important. Now that I understand your request for modification & clarification better, I think it makes sense. It would be good to clarify in the spec. If there is no operator here who can think of a reason why they may want to explicitly prohibit BGP from advertising a route it doesnt own, even when the nexthop matches that in the forwarding table, we should make the other behavior (i.e. advertise even if BGP doesnt own the route when the nexthop matches) the recommended one, stating the currently stated but least used behavior as an optional alternative. -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA18074 for ; Tue, 2 Mar 2004 00:49:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2m6-0001oC-51; Tue, 02 Mar 2004 00:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2lL-0001lc-EF for idr@optimus.ietf.org; Tue, 02 Mar 2004 00:48:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04054 for ; Tue, 2 Mar 2004 00:48:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2lI-0000i4-00 for idr@ietf.org; Tue, 02 Mar 2004 00:48:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2kN-0000cY-00 for idr@ietf.org; Tue, 02 Mar 2004 00:47:15 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2k0-0000Wy-00 for idr@ietf.org; Tue, 02 Mar 2004 00:46:52 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i225kCd19705; Tue, 2 Mar 2004 07:46:12 +0200 From: Pekka Savola To: Gargi Nalawade cc: Pedro Roque Marques , Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: <404417CE.2020901@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 07:46:12 +0200 (EET) On Mon, 1 Mar 2004, Gargi Nalawade wrote: > For this case - there is no problem. Some implementations can already > do this. But again there are operators who want the opposite behavior > as well. i.e. BGP should not advertise a route if it is not the owner > even if the BGP nexthop is the same as that of the route in the > forwarding table. Really? I'm having problems figuring out where this would be desired behaviour. > Both behaviors are achieved today by various imple- > mentations even though the default may vary from vendor to vendor. Yep. > Again - time for a clarification. :) Are you asking for that the > behavior be present or that the spec be changed to describe both > behaviors? I think the specification should, very clearly, state just one recommended behaviour, and possibly describe an optional other behaviour. I think the recommended behaviour should be what I proposed, and you also described. Because that's actually what happens very often. But if there is strong objection to this very clear statement of behaviour (or "modification"), also spelling out the alternative is important. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA17856 for ; Tue, 2 Mar 2004 00:16:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2G9-0005Ef-RX; Tue, 02 Mar 2004 00:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2FU-0005CP-6d for idr@optimus.ietf.org; Tue, 02 Mar 2004 00:15:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02311 for ; Tue, 2 Mar 2004 00:15:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2FR-0004dk-00 for idr@ietf.org; Tue, 02 Mar 2004 00:15:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2EZ-0004XT-00 for idr@ietf.org; Tue, 02 Mar 2004 00:14:23 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2Dx-0004Od-00 for idr@ietf.org; Tue, 02 Mar 2004 00:13:45 -0500 Received: from cisco.com (hkidc-vpn-client-234-19.cisco.com [10.75.234.19]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i225ClLM006725; Mon, 1 Mar 2004 21:12:48 -0800 (PST) Message-ID: <404417CE.2020901@cisco.com> From: Gargi Nalawade Reply-To: gargi@cisco.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Pedro Roque Marques , idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 21:12:46 -0800 Pekka Savola wrote: > On Mon, 1 Mar 2004, Gargi Nalawade wrote: > >>Are you asking that BGP advertise a route even if the nexthop of the >>route in the forwarding table is different? If so, this definitely >>breaks routing. As long as the nexthop of the 2 routes are the same, >>there is no problem. > > > Thanks for asking for clarification; I think this is very useful, and > a point which has not been spelled out clearly enough. > > I'm only interested of the case where the next-hop interface is the > same for both protocols. (Obviously, there is no 1-to-1 mapping, > because IGP gives an interface, but BGP an address.) For this case - there is no problem. Some implementations can already do this. But again there are operators who want the opposite behavior as well. i.e. BGP should not advertise a route if it is not the owner even if the BGP nexthop is the same as that of the route in the forwarding table. Both behaviors are achieved today by various imple- mentations even though the default may vary from vendor to vendor. Again - time for a clarification. :) Are you asking for that the behavior be present or that the spec be changed to describe both behaviors? -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA17495 for ; Mon, 1 Mar 2004 23:39:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1gL-0007xS-3M; Mon, 01 Mar 2004 23:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1fb-0007k5-Lc for idr@optimus.ietf.org; Mon, 01 Mar 2004 23:38:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29984 for ; Mon, 1 Mar 2004 23:38:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1fZ-0000Ah-00 for idr@ietf.org; Mon, 01 Mar 2004 23:38:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay1ed-000031-00 for idr@ietf.org; Mon, 01 Mar 2004 23:37:16 -0500 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1dq-0007jA-00 for idr@ietf.org; Mon, 01 Mar 2004 23:36:26 -0500 Received: (qmail 16232 invoked by uid 1021); 2 Mar 2004 04:36:27 -0000 From: vijay gill To: Pedro Roque Marques Cc: Pekka Savola , idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) Message-ID: <20040302043627.GA16188@vijaygill.com> References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> <200403020025.i220PI9P050138@roque-bsd.juniper.net> <20040302003314.GA6255@vijaygill.com> <200403020041.i220fwFm050173@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403020041.i220fwFm050173@roque-bsd.juniper.net> User-Agent: Mutt/1.3.28i Organization: vijay gill global logistics X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 04:36:27 +0000 --On Monday, March 1, 2004 16:41 -0800 Pedro Roque Marques wrote: > vijay gill writes: > >> On Mon, Mar 01, 2004 at 04:25:18PM -0800, Pedro Roque Marques wrote: >>> Pekka Savola writes: >>> >>> i'll repeat it: - How can you prove that a given path that is >>> learned by BGP is loop free ? - That can only be done if >>> forwarding follows routing. > >> I feel that BGP should only be concerned about creating loop free >> topologies. If the user then has a mechanism where the forwarding >> does not follow the routing properly and causes a loop (this is an >> important distinction), then this is their problem. I can always >> point a static back up a link if I so want and nothing bgp can do >> about it. > > Your argument assumes that the user always knows that is configuring a > situation that may create forwarding loops... > > That may not be the case. It may come from a configuration > mistake... > > imho, the default approach for the protocol spec is to choose the most > graceful failure model possible torwards loop-free forwarding... >imho, the default approach for the protocol spec is to choose the most >graceful failure model possible torwards loop-free forwarding... Pedro, I still don't understand why BGP must care about statics or other protocols that may or may not be misconfigured. For some reason I may want to create a forwarding loop (for example, in my lab) to see what the router does. Actually, to be more specific, there are valid operational reasons for sometimes routing information away from where BGP points you, load balancing on congested peerings for example. Not very elegant, but these cases do exist. If a vendors BGP implementation does not allow me to have the final say as to where I want to place traffic, I _will_ be extremely irate. If you only consider BGP, then it should do loop-free routing, absolutely. I just do not want BGP to be looking into static configurations and trying to do my thinking for me. This leads to anger and anger leads to the dark side. etc etc. > >>> Proof: configure a static route for a given prefix in a border >>>router that points to a BGP neighbor that selects this router as >>>best path... watch permanent forwarding loops. > >>Yes, and this is a not a matter for BGP to worry about. > >I respectfully disagree. that is fine. but as we all know, the final arbiter of features is the account team, backed up by P.O.s no matter what the IETF would like to believe. /vijay > > Pedro. > >_______________________________________________ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA17375 for ; Mon, 1 Mar 2004 23:19:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1Mz-0005hJ-NK; Mon, 01 Mar 2004 23:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1MJ-0005b8-0o for idr@optimus.ietf.org; Mon, 01 Mar 2004 23:18:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28744 for ; Mon, 1 Mar 2004 23:18:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1MH-0005II-00 for idr@ietf.org; Mon, 01 Mar 2004 23:18:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay1LH-0005BZ-00 for idr@ietf.org; Mon, 01 Mar 2004 23:17:15 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1KR-0004z7-00 for idr@ietf.org; Mon, 01 Mar 2004 23:16:23 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i224FpM18674; Tue, 2 Mar 2004 06:15:51 +0200 From: Pekka Savola To: Pedro Roque Marques cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <200403020156.i221u9jf050325@roque-bsd.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 06:15:51 +0200 (EET) On Mon, 1 Mar 2004, Pedro Roque Marques wrote: > > > No -- the current spec is just looking up a route -- it takes no > > stance what kind of 'route' that is. > > By your own admission the spec doesn't require clarification. It is > clear that it doesn't understand the next-hop type of a route. Some people seem to disagree. I personally am of the opinion that the spec can be read both ways, but *seems* to indicate that the intent is to be "route -type agnostic". > What you mean by this is that you believe that the current behaviour > should be modified... Modified (if the WG thinks your interpretation is correct) is preferable. Clarified is required. > The modification you propose also isn't suficient to address the > problem that you point out whenever your aggregate route has a > reachable next-hop. As stated, that can be avoided by operational procedures (by putting the discard routes in every box). This really can't. > Examples where this could happen: > > - User wants to forward all traffic that hits the default route to a > remote box that analyzes traffic... i.e. 0/0 to an LSP to a traffic > collector. Of course, this can happen. Then the BGP nexthops matching the default remain 'resolvable'. But that seems quite obvious: if you have a "working" default route, it will be considered by the resolvability process. Of course, in the long run, there is a need to specify the resolvability in a more fine-grained manner, but the "discard route" scenario seems to be a non-obvious problem which must be fixed quickly. I don't have many preferences on the way it's solved, as long as it gets fixed soon. And if fixing would take time, and it's for any purpose delayed from the bgp4-xx spec for now, we must clearly specify the expected behaviour in the spec. > - Network is divided in areas but has global IGP. Each area border > generates a summary of address in the are that is propagated across > the network. i.e. outside the area you see an aggregate via BGP and > more specific /32s. "Don't do that". :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA17262 for ; Mon, 1 Mar 2004 23:05:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay19X-0004MS-9e; Mon, 01 Mar 2004 23:05:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay19O-0004LG-KB for idr@optimus.ietf.org; Mon, 01 Mar 2004 23:04:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28060 for ; Mon, 1 Mar 2004 23:04:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay19I-0003YX-00 for idr@ietf.org; Mon, 01 Mar 2004 23:04:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay17i-0003P5-00 for idr@ietf.org; Mon, 01 Mar 2004 23:03:14 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay16j-00037L-00 for idr@ietf.org; Mon, 01 Mar 2004 23:02:13 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2241WV18475; Tue, 2 Mar 2004 06:01:32 +0200 From: Pekka Savola To: Gargi Nalawade cc: Pedro Roque Marques , Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: <4043F15B.7000400@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 06:01:32 +0200 (EET) On Mon, 1 Mar 2004, Gargi Nalawade wrote: > Are you asking that BGP advertise a route even if the nexthop of the > route in the forwarding table is different? If so, this definitely > breaks routing. As long as the nexthop of the 2 routes are the same, > there is no problem. Thanks for asking for clarification; I think this is very useful, and a point which has not been spelled out clearly enough. I'm only interested of the case where the next-hop interface is the same for both protocols. (Obviously, there is no 1-to-1 mapping, because IGP gives an interface, but BGP an address.) But this is natural, as the BGP next-hop information is quite often, when it matters, calculated based on IGP :) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA17118 for ; Mon, 1 Mar 2004 22:43:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay0o9-0002qd-Eb; Mon, 01 Mar 2004 22:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay0nL-0002pd-Mz for idr@optimus.ietf.org; Mon, 01 Mar 2004 22:42:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26811 for ; Mon, 1 Mar 2004 22:42:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay0nI-0000RS-00 for idr@ietf.org; Mon, 01 Mar 2004 22:42:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay0mQ-0000M7-00 for idr@ietf.org; Mon, 01 Mar 2004 22:41:15 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay0m6-0000GM-00 for idr@ietf.org; Mon, 01 Mar 2004 22:40:54 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id CF2232D493F for ; Mon, 1 Mar 2004 22:40:24 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 45584-03-17 for ; Mon, 1 Mar 2004 22:40:23 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7D4BE2D4932 for ; Mon, 1 Mar 2004 22:40:23 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: IDR minutes Thread-Index: AcP/ZbUR5OkElLH7TN2Bea6gcoa+eQAjb2yw From: "Susan Hares" To: X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] FW: IDR minutes Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 22:40:23 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id WAA17118 Minutes for 3/1/04 session -----Original Message----- From: Jake Khuon Sent: Monday, March 01, 2004 3:18 AM To: Susan Hares; yakov@juniper.net Subject: IDR minutes Inter-Domain Routing WG (idr) Monday, March 1 at 1530-1730 ================================== CHAIRS: Sue Hares (skh@nexthop.com) Yakov Rekhter (yakov@juniper.net) AGENDA: 1) Agenda Bashing Agenda Slides 2) Document status [5 minutes] - Bundle went to IESG BGP-4 draft-23 draft-ietf-idr-bgp4-23.txt BGP-4 V1 MIB draft-ietf-idr-bgp4-mib-13.txt BGP-4 Protocol Analysis draft-ietf-idr-bgp-analysis-04.txt BGP Security Vulnerabilities Analysis draft-ietf-idr-bgp-vuln-00.txt Experience with the BGP-4 Protocol draft-ietf-idr-bgp4-experience-protocol-03.txt BGP 4 Implementation Report draft-ietf-idr-bgp-implementation-00.txt BGP-4 V1 MIB implementation report draft-ietf-idr-bgp-mibagent-survey-01.txt Presentation 3) Implementation Reports and FSM issues for current drafts [10 minutes] document: None, presentation only Presentation Sue Hares - Yakov: route-reflector update status? - Enke: route-reflector update (4 weeks) - Enke: prefix-orf was not added to charter - Sue: yes it was added, administrative error in listing 4) BGP Peer Restart Backoff Mechanisms [10 minutes] document: draft-hares-bgp-backoff-01.txt (ietf) (-02 Update) Author: Susan Hares Presentation Sue Hares - Alex: draft should say informational achieve functionality using existing states? - Sue: no... can't use existing states; already investigated that option 5) Deterministic Route Redistribution into BGP [10 minutes] document: draft-chen-bgp-redist-00.txt Authors: Jenny Yuan, Enke Chen Enke Chen - Andrew Lang: used to use configured localpref tweaking; not management intensive... unsure if this is needed - Enke: timing dependent non-deterministic problem so current knobs cannot be used reliably; does not break anything... backwards compatible - Andrew Lang: better to educate people about localpref - Barry Friedman: lacks generality too narrow a problem space... only addresses RIP/iBGP interaction - Enke: tweaking of admin distance defines a baseline - need per route granularity to solve for all cases? Possibility of adding more configuration conflicts. - Alex: this problem only occurs if there's a consistancy issue between two places... May not be an issue for a single selection point. Introduction of new step will effect current edployment traffic selection? - Enke: This will happen regardless. Should not effect current deployments and if there's a change, the change will be for the better. - By definition, it does change behaviour. - Alex: Will this be applicable to only situations where there is a problem? - Yakov: Is this an implimentation method? - Alex: Is this informational or standards-track? - Enke: Either is fine - It can't be a local matter because it must be consistant throughout the entire system - Enke: Decision on redistributed routes is made locally in each router - Behaviour is changed because new code now uses admin distance over localpref? - Enke: If only localpref is used then things should not change - Cengiz: If route-reflector is used? - Enke: I need to think about it further 6) BGP based auto-discovery [Sue Hares, P. Unbehagen] [10 minutes] document: draft-hlmu-l2vpn-bgp-discovery-00.txt authors: P. Unbehagen, P. Muley, V. Radoaca, Susan Hares Presentation Sue Hares, P. Unbehagen - Already a L2VPN draft that addresses this in a defined NLRI with label information - Paul: This draft is meant to provide LDP pseudowire config information - Other spec can do same thing [autodiscovery] without label information - Kireeti: Would like to be able to use this AFI with different SAFI [65] and NLRI format - Would the two SAFIs be solving similar problems - Kireeti: My SAFI solves different problems 7) BGP Assignment of AFI/SAFI address [10 minutes] Document: draft-hares-bgp-assign-afisafi-00.txt Author: Susan Hares Presentation Sue Hares 8) BGP Attribute Codes and Suggested Procedures Document: draft-kompella-zinin-early-allocation-00.txt Author: Alex Zinin, Kireeti Kompella Presentation Alex Zinin - Sharon: talking about protocols and not OIDs preallocation? bad to preallocate in the MIB... different from what other WGs; exclude MIB OIDs - Kireeti: not suggesting that everyone use this - It would have been nicer to have had OIDs preallocated so as not to reimpliment the MIB - Sharon: OIDs not allocated to drafts because if the drafts goes away then you've wasted numbers - Lou Berger: allocation with 1 year with 1 renewal is too short; alterntate policy: as long as draft or version is alive, expire in 3 to 6 months - Alex: that suggestion ties validity with ability of author to submit the draft; suggestion: once document is submitted to IESG then we freeze. Don't want to allocate codepoints too early. - Dave Meyer: Are you sure that IANA can time anything out - Alex: No - Dave Meyer: WG chair needs to manage this? - What happens if the allocation is not renewed and code is using it still? - Alex: Add provision to document to deprecate but not return - Kireeti: Deprecate for a period of time to give people time to remove. Formal process to do early allocations and if it goes through then stick with it but if it doesn't go through then people must take this out. - Dino: Allocate experimental codepoints and once standardised, then adopt standard codepoint for sending but accept both. - Sue: Good for SAFIs as well as AFIs? - Dino: All well known IANA values - Fenner: RFC already documents a process for transitioning codepoints 9) Charter Discussion [20 minutes] Thanks to all implementers who send in reports on the the base specification, we will be opening the charter. This section of the meeting will discuss what items will be added to the charter. Presentation - Top three most important; maybe ECMP little higher than Fault Isolation -- /*==================[ Jake Khuon ]=====================+ | Field App. Engineer http://www.nexthop.com/ /\ /~ E X T H O P | | Ofc: +1 (425) 391-2262 Fax: +1 (425) 391-6772 / \/ Technologies, Inc.| +==========[ 1911 Landings Drive, Mountain View, CA 94043 USA ]===========*/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA16483 for ; Mon, 1 Mar 2004 21:32:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzhR-0007I3-Hp; Mon, 01 Mar 2004 21:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axzgj-0007F9-De for idr@optimus.ietf.org; Mon, 01 Mar 2004 21:31:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24322 for ; Mon, 1 Mar 2004 21:31:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axzgg-0000l2-00 for idr@ietf.org; Mon, 01 Mar 2004 21:31:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axzfl-0000bG-00 for idr@ietf.org; Mon, 01 Mar 2004 21:30:18 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Axzeu-0000Jm-00 for idr@ietf.org; Mon, 01 Mar 2004 21:29:24 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 01 Mar 2004 18:28:52 -0800 Received: from cisco.com (hkidc-vpn-client-234-14.cisco.com [10.75.234.14]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i222SjLB011026; Mon, 1 Mar 2004 18:28:46 -0800 (PST) Message-ID: <4043F15B.7000400@cisco.com> From: Gargi Nalawade Reply-To: gargi@cisco.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pedro Roque Marques CC: Pekka Savola , idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> <200403020034.i220Ytrh050157@roque-bsd.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 18:28:43 -0800 Pedro, > The issue is "what are the drawbacks of advertising a route that is > not used for forwarding". I agree that BGP should not advertise a route not used for forwarding, to the extent that the route used for forwarding means same nexthop. If BGP is not the owner of the route, but the BGP nexthop matches the nexthop of the route in the forwarding table, there is no forwarding loop if BGP advertises the route. Things work perfectly fine. Pekka, Are you asking that BGP advertise a route even if the nexthop of the route in the forwarding table is different? If so, this definitely breaks routing. As long as the nexthop of the 2 routes are the same, there is no problem. -Gargi _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA16201 for ; Mon, 1 Mar 2004 20:59:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzBV-0003Rq-7M; Mon, 01 Mar 2004 20:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzAn-0003Qc-T6 for idr@optimus.ietf.org; Mon, 01 Mar 2004 20:58:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22012 for ; Mon, 1 Mar 2004 20:58:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxzAl-0003sB-00 for idr@ietf.org; Mon, 01 Mar 2004 20:58:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axz9v-0003lI-00 for idr@ietf.org; Mon, 01 Mar 2004 20:57:23 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1Axz9D-0003aS-00 for idr@ietf.org; Mon, 01 Mar 2004 20:56:39 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i221uA1K050328; Mon, 1 Mar 2004 17:56:10 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i221u9jf050325; Mon, 1 Mar 2004 17:56:09 -0800 (PST) Message-Id: <200403020156.i221u9jf050325@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pekka Savola Cc: Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: References: <200403020106.i2216XRX077511@workhorse.fictitious.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 17:56:09 -0800 (PST) Pekka Savola writes: > My interpretation of the spec (and a vendor's, as well) is that this > is not considered at all in the current spec. And if we disagree, > it calls for EVEN MORE LOUDLY for a clarification! [...] > No -- the current spec is just looking up a route -- it takes no > stance what kind of 'route' that is. By your own admission the spec doesn't require clarification. It is clear that it doesn't understand the next-hop type of a route. > This needs to be specified. What you mean by this is that you believe that the current behaviour should be modified... Even if we where to agree that the behaviour you and Curtis propose is more desirable than the current one, it isn't feasible to modify the behaviour of current systems. The modification you propose also isn't suficient to address the problem that you point out whenever your aggregate route has a reachable next-hop. Examples where this could happen: - User wants to forward all traffic that hits the default route to a remote box that analyzes traffic... i.e. 0/0 to an LSP to a traffic collector. - Network is divided in areas but has global IGP. Each area border generates a summary of address in the are that is propagated across the network. i.e. outside the area you see an aggregate via BGP and more specific /32s. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA16048 for ; Mon, 1 Mar 2004 20:41:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axyu7-0000nA-7J; Mon, 01 Mar 2004 20:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxytL-0000lG-Ps for idr@optimus.ietf.org; Mon, 01 Mar 2004 20:40:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20538 for ; Mon, 1 Mar 2004 20:40:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxytJ-0001GQ-00 for idr@ietf.org; Mon, 01 Mar 2004 20:40:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxysH-00019a-00 for idr@ietf.org; Mon, 01 Mar 2004 20:39:10 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyrH-0000xh-00 for idr@ietf.org; Mon, 01 Mar 2004 20:38:07 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i221bZp16232; Tue, 2 Mar 2004 03:37:36 +0200 From: Pekka Savola To: Jeffrey Haas cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <20040301200914.C16130@nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 03:37:35 +0200 (EET) On Mon, 1 Mar 2004, Jeffrey Haas wrote: > > Yep -- there two flavors here: > > 1) looking from A's perspective -- the route to C is known to be a > > reject route by A. > > We're fine here. We'll, not sure what you mean. I don't think "we're fine here" is a good choice of words, because that's the actual problem I was reporting -- one which is not covered by the specification! > > 2) looking from B's perspective -- the route to C goes to A, where > > the packets are rejected. B does not, in BGP, know that the route is a > > reject route at A. > > And thus packets that arrive at B will be propagated to A and be > consumed by the reject route. > > And this is not fine how? I can accept this behaviour, but 1), above is unacceptable. > The ideal scenario is that each core router within the AS knows all > of the routes to networks within an AS. Once a packet hits one of > these routers, that router will generate ICMP destination unreachable. Agreed. > In our scenario above, we provide a routing sink that attracts packets > that otherwise would be generating ICMP further into the network, > but the right thing continues to happen. If we're being clever, > we may be doing this intentionally with a default sink as an attempt > to collect statistics about packets being sent to hosts within our > network that appear outside advertised aggregates for purposes of > intrusion detection or something else. But such a packet sink breaks route resolvability -- all the routers which do not have the reject route -- assuming that problem 1) above will be fixed -- will continue to have their iBGP sessions up. This is, AFAICS, in conflict with two of your goals below. > At no time does this break routing. What the above scenario indicates > is that the network isn't being configured well. I think you're assuming that 1) is a non-problem. It is a real problem. But assuming it isn't.. > Ideally (and please feel to shoot this down based on operational > experience): > o Aggregation happens at your AS border routers. Every single one of them. > o You do not inject your aggregates into your iBGP. These are desirable goals, yes. Actually, they are just one goal, worded differently -- if you don't aggregate everywhere, you have to have the aggregates in your iBGP, no question about it. Excluding misconfigurations (such as unintentional aggregate advertisement to iBGP unnecesarily), practically, either you break zero or you break both. Practically, these are not always feasible. E.g., we use private ASns in access networks, so each core router connecting to an access network has EBGP and would have to aggregate (we're just advertising the default). This is "aggregation in all of the borders" is a bit cumbersome, but we could add it if that would make the network "more correct" and make it work better. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA15904 for ; Mon, 1 Mar 2004 20:24:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axydd-00062d-LW; Mon, 01 Mar 2004 20:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axycm-0005xY-N9 for idr@optimus.ietf.org; Mon, 01 Mar 2004 20:23:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19239 for ; Mon, 1 Mar 2004 20:23:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axyck-0006dp-00 for idr@ietf.org; Mon, 01 Mar 2004 20:23:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axyb0-0006Hp-00 for idr@ietf.org; Mon, 01 Mar 2004 20:21:19 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyZB-0005mK-00 for idr@ietf.org; Mon, 01 Mar 2004 20:19:25 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i221IeS15962; Tue, 2 Mar 2004 03:18:40 +0200 From: Pekka Savola To: curtis@fictitious.org cc: Parantap Lahiri , "'John G. Scudder'" , Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <200403020106.i2216XRX077511@workhorse.fictitious.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 03:18:40 +0200 (EET) On Mon, 1 Mar 2004, Curtis Villamizar wrote: > Yes I was following. You just didn't read the paragraph that was > immediately above this one, which you also conveniently chopped off. > The paragraph you omitted said: > > Then the aggregate is locally generated and it is very easy to > exclude the parts of an aggregate that you generated but are not > covered by more specific from the reachability test and it makes > perfectly good sense to do so. If other prefixes in the AS match > that aggregate then the aggregate is generated but locally it is > installed as a discard route. > > I'm agreeing with the original point just mentioning that the original > point wasn't clear. It was (or _is_) not clear whether you consider this to be the status quo or not. My interpretation of the spec (and a vendor's, as well) is that this is not considered at all in the current spec. And if we disagree, it calls for EVEN MORE LOUDLY for a clarification! > > > No need to modify the spec. If you've installed a special type of > > > route in the kernel that is there explicitly to indicate > > > non-reachability, then that route should not be allowed to indicate > > > reachability. I dont' think we really need to say that. > > > > You would think so, but the current spec does not say so. > > The bgp3-23 test just mentions route. If you interpret that to > include discard routes you simply have a bug in your implementation. > It is quite easy to just look for something in the FIB radix trie and > if you find something declare that is satisfied the reachability > criteria without looking at what it was you found (a discard route). No -- the current spec is just looking up a route -- it takes no stance what kind of 'route' that is. This needs to be specified. Of course, it'd be nice to fix the implementation I'm having problems with. But being altruistic, and wanting to fix this problem for others as well, this needs to be specified, somehow, in the spec to avoid this issue being misinterpreted. My assumption is that the implementation must work properly, if implemented to the letter of the spec. That's not the case now. Anything that requires the implementor to "use non-obvious interpretation of the spec" is a potential missing (or badly written) item from the spec. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA15784 for ; Mon, 1 Mar 2004 20:12:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyS2-0004UI-7B; Mon, 01 Mar 2004 20:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyRN-0004RM-6d for idr@optimus.ietf.org; Mon, 01 Mar 2004 20:11:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18277 for ; Mon, 1 Mar 2004 20:11:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyRL-0004dY-00 for idr@ietf.org; Mon, 01 Mar 2004 20:11:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxyQU-0004We-00 for idr@ietf.org; Mon, 01 Mar 2004 20:10:27 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AxyPo-0004NA-00 for idr@ietf.org; Mon, 01 Mar 2004 20:09:44 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A2A332D480C; Mon, 1 Mar 2004 20:09:15 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 43228-01-2; Mon, 1 Mar 2004 20:09:14 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A0BB52D4804; Mon, 1 Mar 2004 20:09:14 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i2219Eg22046; Mon, 1 Mar 2004 20:09:14 -0500 (EST) From: Jeffrey Haas To: Pekka Savola Cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes Message-ID: <20040301200914.C16130@nexthop.com> References: <20040301192732.A21492@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pekkas@netcore.fi on Tue, Mar 02, 2004 at 02:52:57AM +0200 X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 20:09:14 -0500 Please excuse the long citation. On Tue, Mar 02, 2004 at 02:52:57AM +0200, Pekka Savola wrote: > > C > > /| > > A | > > \| > > B > > > > B has prefix D1 - 192/17 > > C has prefix D2 - 192.128/17 > > > > B and C advertises these routes with loopback addresses. (next-hop-self) > > > > A synthesizes an aggregate, 192/16 using B and C's routes as contributors. > > A thus installs 192/16 in it's FIB as a reject route per accepted > > practice. > > We're doing "manual aggregation" by adding the 192/16 manually as a > discard route, and filtering out the more specifics when advertising > to peers, but the end result is the same. A, B and C are all within a given AS. Regardless of whether A propagates B and C's more specifics to peers outside of this AS isn't important to this particular scenario. To be clear, we may consider A, B and C to be egress routers for this AS and B and C will propagate the aggregate synthesized by A and learned via iBGP. Note that as has been mentioned multiple times, this is not common practice - C and B should be configured to synthesize the aggregate as well, but this will work "ok" without it. > > C is nuked from space in a green fireball. > > > > Prior to BGP figuring out that C has gone away, C's loopback is no longer > > advertised, leaving B to use the aggregate from A to calculate the > > resolved nexthop for D2. Thus, B has a route to D2 via A, which will > > eventually reach a reject route. > > > > Is this your scenario? > > Yep -- there two flavors here: > 1) looking from A's perspective -- the route to C is known to be a > reject route by A. We're fine here. > 2) looking from B's perspective -- the route to C goes to A, where > the packets are rejected. B does not, in BGP, know that the route is a > reject route at A. And thus packets that arrive at B will be propagated to A and be consumed by the reject route. And this is not fine how? The ideal scenario is that each core router within the AS knows all of the routes to networks within an AS. Once a packet hits one of these routers, that router will generate ICMP destination unreachable. In our scenario above, we provide a routing sink that attracts packets that otherwise would be generating ICMP further into the network, but the right thing continues to happen. If we're being clever, we may be doing this intentionally with a default sink as an attempt to collect statistics about packets being sent to hosts within our network that appear outside advertised aggregates for purposes of intrusion detection or something else. At no time does this break routing. What the above scenario indicates is that the network isn't being configured well. Ideally (and please feel to shoot this down based on operational experience): o Aggregation happens at your AS border routers. Every single one of them. o You do not inject your aggregates into your iBGP. o You do not advertised more specifics covered by an announced aggregate unless you are doing intentional traffic engineering. If you are, you're preferably working with your upstream ISPs to make sure those routes aren't propagated "too far" in attempt to keep the Internet routing table clean. One example is tagging the routes with the NO_EXPORT community. However, if you fail in one of the above, routing will still work. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA15653 for ; Mon, 1 Mar 2004 19:56:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyCX-0001O3-Vb; Mon, 01 Mar 2004 19:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyBl-0001Eb-3g for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:55:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17247 for ; Mon, 1 Mar 2004 19:55:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyBj-0002gz-00 for idr@ietf.org; Mon, 01 Mar 2004 19:55:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxyAr-0002ac-00 for idr@ietf.org; Mon, 01 Mar 2004 19:54:17 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyA4-0002OD-00 for idr@ietf.org; Mon, 01 Mar 2004 19:53:28 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i220qvR15465; Tue, 2 Mar 2004 02:52:57 +0200 From: Pekka Savola To: Jeffrey Haas cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <20040301192732.A21492@nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 02:52:57 +0200 (EET) On Mon, 1 Mar 2004, Jeffrey Haas wrote: > On Tue, Mar 02, 2004 at 01:41:41AM +0200, Pekka Savola wrote: > > I guess you weren't following. Discard routes are set up because > > folks want to announce that aggregate route to their peers. That's > > not a "very unusual circumstance". > > If I'm following you correctly, here's an example of the condition that > you're talking about. > > C > /| > A | > \| > B > > B has prefix D1 - 192/17 > C has prefix D2 - 192.128/17 > > B and C advertises these routes with loopback addresses. (next-hop-self) > > A synthesizes an aggregate, 192/16 using B and C's routes as contributors. > A thus installs 192/16 in it's FIB as a reject route per accepted > practice. We're doing "manual aggregation" by adding the 192/16 manually as a discard route, and filtering out the more specifics when advertising to peers, but the end result is the same. > C is nuked from space in a green fireball. > > Prior to BGP figuring out that C has gone away, C's loopback is no longer > advertised, leaving B to use the aggregate from A to calculate the > resolved nexthop for D2. Thus, B has a route to D2 via A, which will > eventually reach a reject route. > > Is this your scenario? Yep -- there two flavors here: 1) looking from A's perspective -- the route to C is known to be a reject route by A. 2) looking from B's perspective -- the route to C goes to A, where the packets are rejected. B does not, in BGP, know that the route is a reject route at A. 1) is the root cause; 2) can be worked around by installing "reject" routes on all boxes. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA15570 for ; Mon, 1 Mar 2004 19:48:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axy4n-0000Zw-7t; Mon, 01 Mar 2004 19:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axy3p-000075-Mh for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:47:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16668 for ; Mon, 1 Mar 2004 19:46:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axy3n-0001iC-00 for idr@ietf.org; Mon, 01 Mar 2004 19:46:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axy2p-0001Z6-00 for idr@ietf.org; Mon, 01 Mar 2004 19:45:59 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1Axy1p-0001Mc-00 for idr@ietf.org; Mon, 01 Mar 2004 19:44:57 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 723C22D48B4; Mon, 1 Mar 2004 19:44:28 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 42048-01-55; Mon, 1 Mar 2004 19:44:27 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 720632D4838; Mon, 1 Mar 2004 19:44:27 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i220iR721796; Mon, 1 Mar 2004 19:44:27 -0500 (EST) From: Jeffrey Haas To: curtis@fictitious.org Cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes Message-ID: <20040301194427.B16130@nexthop.com> References: <01da01c3ffcc$03125450$c8922799@mcilink.com> <200403012044.i21KijRX074248@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200403012044.i21KijRX074248@workhorse.fictitious.org>; from curtis@workhorse.fictitious.org on Mon, Mar 01, 2004 at 03:44:45PM -0500 X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 19:44:27 -0500 On Mon, Mar 01, 2004 at 03:44:45PM -0500, Curtis Villamizar wrote: > Then the aggregate is locally generated and it is very easy to exclude > the parts of an aggregate that you generated but are not covered by > more specific from the reachability test and it makes perfectly good > sense to do so. If other prefixes in the AS match that aggregate then > the aggregate is generated but locally it is installed as a discard > route. > > I suppose this is the original reason that the discard route was > mentioned, but with a failure to mention the entire context. It took me a second to remember, but to dredge up the ghost from the last time this thread came around: rfc 1519, section 4.2.2: : 4.2. Rules for route advertisement : [...] : 2. A routing domain which performs summarization of multiple : routes must discard packets which match the summarization but : do not match any of the explicit routes which makes up the : summarization. This is necessary to prevent routing loops in : the presence of less-specific information (such as a default : route). Implementation note - one simple way to implement : this rule would be for the border router to maintain a "sink" : route for each of its aggregations. By the rule of longest : match, this would cause all traffic destined to components of : the aggregation which are not explicitly known to be : discarded. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA15551 for ; Mon, 1 Mar 2004 19:45:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axy1w-0008KW-IJ; Mon, 01 Mar 2004 19:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axy17-0008JE-Qb for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:44:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16568 for ; Mon, 1 Mar 2004 19:44:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axy16-0001Kt-00 for idr@ietf.org; Mon, 01 Mar 2004 19:44:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axy0E-0001EG-00 for idr@ietf.org; Mon, 01 Mar 2004 19:43:18 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AxxzQ-00010k-00 for idr@ietf.org; Mon, 01 Mar 2004 19:42:28 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i220fw1K050176; Mon, 1 Mar 2004 16:41:58 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i220fwFm050173; Mon, 1 Mar 2004 16:41:58 -0800 (PST) Message-Id: <200403020041.i220fwFm050173@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: vijay gill Cc: Pekka Savola , idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: <20040302003314.GA6255@vijaygill.com> References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> <200403020025.i220PI9P050138@roque-bsd.juniper.net> <20040302003314.GA6255@vijaygill.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 16:41:58 -0800 (PST) vijay gill writes: > On Mon, Mar 01, 2004 at 04:25:18PM -0800, Pedro Roque Marques wrote: >> Pekka Savola writes: >> >> i'll repeat it: - How can you prove that a given path that is >> learned by BGP is loop free ? - That can only be done if >> forwarding follows routing. > I feel that BGP should only be concerned about creating loop free > topologies. If the user then has a mechanism where the forwarding > does not follow the routing properly and causes a loop (this is an > important distinction), then this is their problem. I can always > point a static back up a link if I so want and nothing bgp can do > about it. Your argument assumes that the user always knows that is configuring a situation that may create forwarding loops... That may not be the case. It may come from a configuration mistake... imho, the default approach for the protocol spec is to choose the most graceful failure model possible torwards loop-free forwarding... >> Proof: configure a static route for a given prefix in a border >> router that points to a BGP neighbor that selects this router as >> best path... watch permanent forwarding loops. > Yes, and this is a not a matter for BGP to worry about. I respectfully disagree. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA15462 for ; Mon, 1 Mar 2004 19:38:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxvA-00079q-1P; Mon, 01 Mar 2004 19:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxub-00070B-DC for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:37:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15870 for ; Mon, 1 Mar 2004 19:37:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxuZ-0000MQ-00 for idr@ietf.org; Mon, 01 Mar 2004 19:37:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxtQ-0000Cq-00 for idr@ietf.org; Mon, 01 Mar 2004 19:36:16 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1Axxsb-0007mb-00 for idr@ietf.org; Mon, 01 Mar 2004 19:35:25 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i220Yt1K050160; Mon, 1 Mar 2004 16:34:55 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i220Ytrh050157; Mon, 1 Mar 2004 16:34:55 -0800 (PST) Message-Id: <200403020034.i220Ytrh050157@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pekka Savola Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 16:34:55 -0800 (PST) Pekka Savola writes: > [I don't quickly see how this is related to this specific issue, but > I'm still grasping to understand the specific scenario and the > failure model you're describing.] The issue is "what are the drawbacks of advertising a route that is not used for forwarding". > If a link has failed but rerouting is not possible (i.e.: a and b > become isolated from each other, or both a and b become isolated > from the route originator), the internal consistency has failed. > But as they have configured a discard route, this is an intended > consequence -- the routers by its definition are supposed to know > everything in the area. In such scenario, w/ one choice of behaviour a blackhole route is advertised, w/ is not so w/ another choice of behaviour. Which means that your original question as to there being instances where this behaviour is desirable has been answered. It may not be desirable in your network. And i find it perfectly reasonable if you require implementations to support the behaviour that is desirable in your network. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA15454 for ; Mon, 1 Mar 2004 19:37:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxuA-0006q7-B0; Mon, 01 Mar 2004 19:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxtP-0006Xg-6M for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:36:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15814 for ; Mon, 1 Mar 2004 19:36:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxtN-0000C8-00 for idr@ietf.org; Mon, 01 Mar 2004 19:36:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxsO-00005D-00 for idr@ietf.org; Mon, 01 Mar 2004 19:35:12 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Axxrl-0007kv-00 for idr@ietf.org; Mon, 01 Mar 2004 19:34:33 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i220TlS17480 for ; Mon, 1 Mar 2004 19:29:47 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Mar 2004 19:29:47 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A5AE2AB@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: idr@ietf.org Cc: "Wijnen, Bert (Bert)" Subject: RE: [Idr] Experimental code-points MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 19:29:47 -0500 hi In looking through http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00 .txt I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated. In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' Sharon -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Monday, March 01, 2004 3:11 AM To: idr@ietf.org Subject: [Idr] Experimental code-points As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. -- Alex http://www.psg.com/~zinin/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA15446 for ; Mon, 1 Mar 2004 19:36:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxtF-0006Nb-Hy; Mon, 01 Mar 2004 19:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxuKf-00016g-3W for idr@optimus.ietf.org; Mon, 01 Mar 2004 15:48:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05628 for ; Mon, 1 Mar 2004 15:48:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxuKd-0006oY-00 for idr@ietf.org; Mon, 01 Mar 2004 15:48:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxuJf-0006gd-00 for idr@ietf.org; Mon, 01 Mar 2004 15:47:07 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AxuId-0006ZU-00 for idr@ietf.org; Mon, 01 Mar 2004 15:46:03 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i21KijRX074248; Mon, 1 Mar 2004 15:44:45 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403012044.i21KijRX074248@workhorse.fictitious.org> To: Parantap Lahiri cc: curtis@fictitious.org, "'Pekka Savola'" , "'John G. Scudder'" , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: Your message of "Mon, 01 Mar 2004 15:30:18 EST." <01da01c3ffcc$03125450$c8922799@mcilink.com> From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 15:44:45 -0500 In message <01da01c3ffcc$03125450$c8922799@mcilink.com>, Parantap Lahiri writes : > Not to beat a dead horse here but in some major vendor implementations, you > can't send an "aggregate" if it is not in your routing table. And it defeats > the purpose. Then the aggregate is locally generated and it is very easy to exclude the parts of an aggregate that you generated but are not covered by more specific from the reachability test and it makes perfectly good sense to do so. If other prefixes in the AS match that aggregate then the aggregate is generated but locally it is installed as a discard route. I suppose this is the original reason that the discard route was mentioned, but with a failure to mention the entire context. You can manually configure discard routes but that is generally only done in very unusual circumstances, such as a DoS attack to a specific destination. Even then it doesn't make a whole lot of sense to allow such a discard route to be used in the resolvability test. No need to modify the spec. If you've installed a special type of route in the kernel that is there explicitly to indicate non-reachability, then that route should not be allowed to indicate reachability. I dont' think we really need to say that. Curtis > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > Sent: Monday, March 01, 2004 3:02 PM > To: Parantap Lahiri > Cc: curtis@fictitious.org; 'Pekka Savola'; 'John G. Scudder'; idr@ietf.org > Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 > routes > > > In message <01c101c3ffb2$300c2630$c8922799@mcilink.com>, Parantap Lahiri > writes > : > > If you aggregate the prefixes just towards EBGP neighbors it definitely > does > > solve the problem, but the issue is you will have to touch all your ebgp > > sessions once you get a new block to aggregate. Operator motto is have a > > design which requires least touching. Of course that can be equated to > > laziness, but it depends on which side of fence you are on. > > > How many different blocks of addresses do you put your IBGP loopbacks > in? Last I counted it was one. You don't have to treat your customer > aggregates this way if you don't want to, just the aggregate that > covers your backbone. And btw - with machine generated configs there > is no problem generating aggregates on each EBGP speaking router - its > only when you try to hand configure your 1,000+ routers (or whatever). > > Anyway, we already seemed to agree that this at most ends up in a > separate new document. > > Curtis > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA15438 for ; Mon, 1 Mar 2004 19:36:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxtE-0006LU-IW; Mon, 01 Mar 2004 19:36:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axtf0-0001y7-A5 for idr@optimus.ietf.org; Mon, 01 Mar 2004 15:05:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02284 for ; Mon, 1 Mar 2004 15:05:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axtex-0001rt-00 for idr@ietf.org; Mon, 01 Mar 2004 15:05:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axte6-0001jW-00 for idr@ietf.org; Mon, 01 Mar 2004 15:04:10 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AxtdT-0001cL-00 for idr@ietf.org; Mon, 01 Mar 2004 15:03:31 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i21K2DRX074068; Mon, 1 Mar 2004 15:02:13 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403012002.i21K2DRX074068@workhorse.fictitious.org> To: Parantap Lahiri cc: curtis@fictitious.org, "'Pekka Savola'" , "'John G. Scudder'" , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: Your message of "Mon, 01 Mar 2004 12:25:27 EST." <01c101c3ffb2$300c2630$c8922799@mcilink.com> From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 15:02:13 -0500 In message <01c101c3ffb2$300c2630$c8922799@mcilink.com>, Parantap Lahiri writes : > If you aggregate the prefixes just towards EBGP neighbors it definitely does > solve the problem, but the issue is you will have to touch all your ebgp > sessions once you get a new block to aggregate. Operator motto is have a > design which requires least touching. Of course that can be equated to > laziness, but it depends on which side of fence you are on. How many different blocks of addresses do you put your IBGP loopbacks in? Last I counted it was one. You don't have to treat your customer aggregates this way if you don't want to, just the aggregate that covers your backbone. And btw - with machine generated configs there is no problem generating aggregates on each EBGP speaking router - its only when you try to hand configure your 1,000+ routers (or whatever). Anyway, we already seemed to agree that this at most ends up in a separate new document. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA15434 for ; Mon, 1 Mar 2004 19:36:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxtD-0006KX-AX; Mon, 01 Mar 2004 19:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxsJ-0006HG-GT for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:35:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15792 for ; Mon, 1 Mar 2004 19:35:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxsH-000045-00 for idr@ietf.org; Mon, 01 Mar 2004 19:35:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxrM-0007lp-00 for idr@ietf.org; Mon, 01 Mar 2004 19:34:09 -0500 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx with esmtp (Exim 4.12) id 1Axxqh-0007fh-00 for idr@ietf.org; Mon, 01 Mar 2004 19:33:27 -0500 Received: (qmail 7726 invoked by uid 1021); 2 Mar 2004 00:33:14 -0000 From: vijay gill To: Pedro Roque Marques Cc: Pekka Savola , idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) Message-ID: <20040302003314.GA6255@vijaygill.com> References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> <200403020025.i220PI9P050138@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403020025.i220PI9P050138@roque-bsd.juniper.net> User-Agent: Mutt/1.3.28i Organization: vijay gill global logistics X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 00:33:14 +0000 On Mon, Mar 01, 2004 at 04:25:18PM -0800, Pedro Roque Marques wrote: > Pekka Savola writes: > > i'll repeat it: > - How can you prove that a given path that is learned by BGP is loop > free ? > - That can only be done if forwarding follows routing. I feel that BGP should only be concerned about creating loop free topologies. If the user then has a mechanism where the forwarding does not follow the routing properly and causes a loop (this is an important distinction), then this is their problem. I can always point a static back up a link if I so want and nothing bgp can do about it. > > Proof: configure a static route for a given prefix in a border router > that points to a BGP neighbor that selects this router as best > path... watch permanent forwarding loops. Yes, and this is a not a matter for BGP to worry about. /vijay _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA15415 for ; Mon, 1 Mar 2004 19:31:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxoM-0005nR-WA; Mon, 01 Mar 2004 19:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxnQ-0005jx-Vk for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:30:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15376 for ; Mon, 1 Mar 2004 19:30:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxnP-0007HD-00 for idr@ietf.org; Mon, 01 Mar 2004 19:30:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxmT-0007As-00 for idr@ietf.org; Mon, 01 Mar 2004 19:29:06 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AxxlX-0006zP-00 for idr@ietf.org; Mon, 01 Mar 2004 19:28:07 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9990B2D4838; Mon, 1 Mar 2004 19:27:33 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 42001-01-23; Mon, 1 Mar 2004 19:27:32 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9A3E22D481E; Mon, 1 Mar 2004 19:27:32 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i220RWx21603; Mon, 1 Mar 2004 19:27:32 -0500 (EST) From: Jeffrey Haas To: Pekka Savola Cc: idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes Message-ID: <20040301192732.A21492@nexthop.com> References: <200403012044.i21KijRX074248@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pekkas@netcore.fi on Tue, Mar 02, 2004 at 01:41:41AM +0200 X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 19:27:32 -0500 Pekka, On Tue, Mar 02, 2004 at 01:41:41AM +0200, Pekka Savola wrote: > I guess you weren't following. Discard routes are set up because > folks want to announce that aggregate route to their peers. That's > not a "very unusual circumstance". If I'm following you correctly, here's an example of the condition that you're talking about. C /| A | \| B B has prefix D1 - 192/17 C has prefix D2 - 192.128/17 B and C advertises these routes with loopback addresses. (next-hop-self) A synthesizes an aggregate, 192/16 using B and C's routes as contributors. A thus installs 192/16 in it's FIB as a reject route per accepted practice. C is nuked from space in a green fireball. Prior to BGP figuring out that C has gone away, C's loopback is no longer advertised, leaving B to use the aggregate from A to calculate the resolved nexthop for D2. Thus, B has a route to D2 via A, which will eventually reach a reject route. Is this your scenario? -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA15400 for ; Mon, 1 Mar 2004 19:28:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxlR-0005VX-C0; Mon, 01 Mar 2004 19:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxkg-0005Uq-7c for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:27:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15230 for ; Mon, 1 Mar 2004 19:27:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axxke-0006zB-00 for idr@ietf.org; Mon, 01 Mar 2004 19:27:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axxjs-0006su-00 for idr@ietf.org; Mon, 01 Mar 2004 19:26:25 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AxxjH-0006kB-00 for idr@ietf.org; Mon, 01 Mar 2004 19:25:47 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i220PI1K050141; Mon, 1 Mar 2004 16:25:18 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i220PI9P050138; Mon, 1 Mar 2004 16:25:18 -0800 (PST) Message-Id: <200403020025.i220PI9P050138@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pekka Savola Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: References: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 16:25:18 -0800 (PST) Pekka Savola writes: > On Mon, 1 Mar 2004, Pedro Roque Marques wrote: >> What is the #1 goal of BGP ? The establishment of *loop free* >> paths between autonomous systems. How can you guarantee loop free >> properties ? via the as-path loop detection mechanism... This means >> that you can only gurantee no forwarding loops if traffic always >> follows routing. > This is IMHO a bogus argument in this case. BGP already relies on > the consistency of the AS in its operations. This is just a matter > of the IGP and BGP in the AS being consistent. > As stated earlier, there is ample operational experience that this > modification works. > The operators, with or without this modification, can shoot > themselves in the foot and discard packets. It seems that you did not understand my argument... i'll repeat it: - How can you prove that a given path that is learned by BGP is loop free ? - That can only be done if forwarding follows routing. Proof: configure a static route for a given prefix in a border router that points to a BGP neighbor that selects this router as best path... watch permanent forwarding loops. Protocol correctness matters. The point of the BGP spec is not how to deal w/ implementation quirks... but it is about protocol correctness. Implementations may feel free to disregard safety rules... and allow uses "to shoot themselfs in the foot"... but it must be clear what the risks are and the BGP spec should be as conservative as possible. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA15313 for ; Mon, 1 Mar 2004 19:20:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxdi-0004CK-J7; Mon, 01 Mar 2004 19:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxd6-00045K-Le for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:19:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14736 for ; Mon, 1 Mar 2004 19:19:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axxd5-0005yb-00 for idr@ietf.org; Mon, 01 Mar 2004 19:19:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axxc5-0005r8-00 for idr@ietf.org; Mon, 01 Mar 2004 19:18:22 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AxxbU-0005h4-00 for idr@ietf.org; Mon, 01 Mar 2004 19:17:44 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i220HE1K050125; Mon, 1 Mar 2004 16:17:14 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i220HE0F050122; Mon, 1 Mar 2004 16:17:14 -0800 (PST) Message-Id: <200403020017.i220HE0F050122@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pekka Savola Cc: Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: References: <200403012044.i21KijRX074248@workhorse.fictitious.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 16:17:14 -0800 (PST) Pekka Savola writes: > You would think so, but the current spec does not say so. > Maybe a problem is that a discard route should not fail the > resolvability check when propagated as a DDoS prevention hack, > referred earlier. > IMHO, excluding these routes seems obvious to me And to me it seems obvious that a route is a route, regardless of next-hop type. The later being an implementation specific concept and not something to be addressed at the spec level... It is clear that what 'seems obvious' is highly subjective to the person in question. >, but as it wasn't > obvious to the implementors and they hadn't done it, it MUST be in > the spec in one form or another. imho, it MUST NOT be in the BGP specification in one way or another. The BGP specification deals w/ the protocol definition, not with how to implement it. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA15280 for ; Mon, 1 Mar 2004 19:11:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxUz-0003cV-J2; Mon, 01 Mar 2004 19:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxU6-0003Yx-Nn for idr@optimus.ietf.org; Mon, 01 Mar 2004 19:10:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14326 for ; Mon, 1 Mar 2004 19:10:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxU3-0004uq-00 for idr@ietf.org; Mon, 01 Mar 2004 19:10:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxT9-0004pu-00 for idr@ietf.org; Mon, 01 Mar 2004 19:09:08 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxSp-0004kD-00 for idr@ietf.org; Mon, 01 Mar 2004 19:08:47 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2208FC14582; Tue, 2 Mar 2004 02:08:15 +0200 From: Pekka Savola To: Pedro Roque Marques cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 02:08:15 +0200 (EET) On Mon, 1 Mar 2004, Pedro Roque Marques wrote: > What is the #1 goal of BGP ? > The establishment of *loop free* paths between autonomous > systems. How can you guarantee loop free properties ? via the as-path > loop detection mechanism... This means that you can only gurantee no > forwarding loops if traffic always follows routing. This is IMHO a bogus argument in this case. BGP already relies on the consistency of the AS in its operations. This is just a matter of the IGP and BGP in the AS being consistent. As stated earlier, there is ample operational experience that this modification works. The operators, with or without this modification, can shoot themselves in the foot and discard packets. > But there are more mundane practical consequences: > > outside > | | > ----------- > a --- b as x > | | > > A and B are border gateways for a stub as (x). Both are configured to > originate a given prefix 10.0.1/24 whenever that prefix is reachable > throught its IGP. > > Additionally, they are configured w/ a discard route to 10.0.1/24, > which discard traffic whenever the IGP route is not present. > > In case of failure, one likely gets one of the exit points w/ a > discard route as its forwarding state, while the other exit point has > a valid IGP route. [I don't quickly see how this is related to this specific issue, but I'm still grasping to understand the specific scenario and the failure model you're describing.] I don't see this happening. Which specific failure are you talking about? It seems to me that: - either the router (a/b) is down making the point moot (the other is in IGP) - either a link has failed (e.g., between a and b), but then the IGP redundancy fixes this problem by rerouting through the stub area (by your description I get that the prefix is learned from some other router in the area). If a link has failed but rerouting is not possible (i.e.: a and b become isolated from each other, or both a and b become isolated from the route originator), the internal consistency has failed. But as they have configured a discard route, this is an intended consequence -- the routers by its definition are supposed to know everything in the area. > If the gateway that has a discard route in the forwarding table does > advertise the route from its peer gateway it will cause traffic to be > dropped. I didn't quite follow this description, but if the stub had a discard route configured, but the IGP is inconsistent, this should definitely be the expected behaviour. > Generalizing: > - whenever BGP advertises a route that it doesn't use for forwarding, > traffic can easily end up getting dropped. Spelling out the root cause: - having an inconsistent/wrong IGP configuration can cause easily traffic to be dropped -- nothing new there. > Would there be a kind soul that volunteers to keep a FAQ of this WG > list ? That way we wouldn't need to rehash this discussion and the > MRAI discussion every 6 months. No objection to having such a FAQ, as long as such a FAQ is not based on bogus arguments. Issue 11 was covered in the BGP issues list, for example, but with incorrect assumptions. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA15081 for ; Mon, 1 Mar 2004 18:45:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axx5s-0001KV-EY; Mon, 01 Mar 2004 18:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axx5A-0001Im-00 for idr@optimus.ietf.org; Mon, 01 Mar 2004 18:44:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13420 for ; Mon, 1 Mar 2004 18:44:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axx56-0002Nc-00 for idr@ietf.org; Mon, 01 Mar 2004 18:44:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axx4B-0002GQ-00 for idr@ietf.org; Mon, 01 Mar 2004 18:43:20 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axx3L-00024H-00 for idr@ietf.org; Mon, 01 Mar 2004 18:42:28 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i21NffY14129; Tue, 2 Mar 2004 01:41:42 +0200 From: Pekka Savola To: curtis@fictitious.org cc: Parantap Lahiri , "'John G. Scudder'" , Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-Reply-To: <200403012044.i21KijRX074248@workhorse.fictitious.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 01:41:41 +0200 (EET) On Mon, 1 Mar 2004, Curtis Villamizar wrote: > I suppose this is the original reason that the discard route was > mentioned, but with a failure to mention the entire context. You can > manually configure discard routes but that is generally only done in > very unusual circumstances, such as a DoS attack to a specific > destination. I guess you weren't following. Discard routes are set up because folks want to announce that aggregate route to their peers. That's not a "very unusual circumstance". > No need to modify the spec. If you've installed a special type of > route in the kernel that is there explicitly to indicate > non-reachability, then that route should not be allowed to indicate > reachability. I dont' think we really need to say that. You would think so, but the current spec does not say so. Maybe a problem is that a discard route should not fail the resolvability check when propagated as a DDoS prevention hack, referred earlier. IMHO, excluding these routes seems obvious to me, but as it wasn't obvious to the implementors and they hadn't done it, it MUST be in the spec in one form or another. Whether it should be discussed at more length in some other document (Targeting BCP or PS, I don't know). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA14660 for ; Mon, 1 Mar 2004 17:51:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxwFb-00087z-94; Mon, 01 Mar 2004 17:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxwFX-00087P-Eb for idr@optimus.ietf.org; Mon, 01 Mar 2004 17:50:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10695 for ; Mon, 1 Mar 2004 17:50:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxwFU-0004oW-00 for idr@ietf.org; Mon, 01 Mar 2004 17:50:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxwEW-0004kD-00 for idr@ietf.org; Mon, 01 Mar 2004 17:49:57 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1AxwDz-0004br-00 for idr@ietf.org; Mon, 01 Mar 2004 17:49:23 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i21Mmrl90128 for ; Mon, 1 Mar 2004 14:48:53 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i21Mmmo33958 for ; Mon, 1 Mar 2004 14:48:48 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200403012248.i21Mmmo33958@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8109.1078181328.1@juniper.net> From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Idr] WG Last Call on draft-ietf-idr-cease-subcode-04.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 14:48:48 -0800 Folks THis is to start the WG Last Call on advancing draft-ietf-idr-cease-subcode-04.txt to Proposed Standard. The Last Call ends March 21. Please send comments to the list. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA13571 for ; Mon, 1 Mar 2004 15:35:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axu7z-0008R3-86; Mon, 01 Mar 2004 15:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axu7s-0008Pk-1f for idr@optimus.ietf.org; Mon, 01 Mar 2004 15:34:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04860 for ; Mon, 1 Mar 2004 15:34:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axu7q-0005Mg-00 for idr@ietf.org; Mon, 01 Mar 2004 15:34:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axu6p-0005Cw-00 for idr@ietf.org; Mon, 01 Mar 2004 15:33:52 -0500 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1Axu5v-00050A-00 for idr@ietf.org; Mon, 01 Mar 2004 15:32:56 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HTW00B59ZMJXX@firewall.mci.com> for idr@ietf.org; Mon, 01 Mar 2004 20:30:19 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HTW00801ZMILT@pmismtp01.mcilink.com>; Mon, 01 Mar 2004 20:30:19 +0000 (GMT) Received: from WS344V8066292 ([153.39.146.200]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HTW007FIZMITB@pmismtp01.mcilink.com>; Mon, 01 Mar 2004 20:30:18 +0000 (GMT) From: Parantap Lahiri Subject: RE: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: <200403012002.i21K2DRX074068@workhorse.fictitious.org> To: curtis@fictitious.org Cc: "'Pekka Savola'" , "'John G. Scudder'" , idr@ietf.org Message-id: <01da01c3ffcc$03125450$c8922799@mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 15:30:18 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id PAA13571 Not to beat a dead horse here but in some major vendor implementations, you can't send an "aggregate" if it is not in your routing table. And it defeats the purpose. -----Original Message----- From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] Sent: Monday, March 01, 2004 3:02 PM To: Parantap Lahiri Cc: curtis@fictitious.org; 'Pekka Savola'; 'John G. Scudder'; idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In message <01c101c3ffb2$300c2630$c8922799@mcilink.com>, Parantap Lahiri writes : > If you aggregate the prefixes just towards EBGP neighbors it definitely does > solve the problem, but the issue is you will have to touch all your ebgp > sessions once you get a new block to aggregate. Operator motto is have a > design which requires least touching. Of course that can be equated to > laziness, but it depends on which side of fence you are on. How many different blocks of addresses do you put your IBGP loopbacks in? Last I counted it was one. You don't have to treat your customer aggregates this way if you don't want to, just the aggregate that covers your backbone. And btw - with machine generated configs there is no problem generating aggregates on each EBGP speaking router - its only when you try to hand configure your 1,000+ routers (or whatever). Anyway, we already seemed to agree that this at most ends up in a separate new document. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA13460 for ; Mon, 1 Mar 2004 15:19:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxtsT-0007AP-MO; Mon, 01 Mar 2004 15:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxtsQ-00079R-Qc for idr@optimus.ietf.org; Mon, 01 Mar 2004 15:18:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03854 for ; Mon, 1 Mar 2004 15:18:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxtsP-0003Mb-00 for idr@ietf.org; Mon, 01 Mar 2004 15:18:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxtrT-0003HT-00 for idr@ietf.org; Mon, 01 Mar 2004 15:18:00 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1Axtr5-0003C4-00 for idr@ietf.org; Mon, 01 Mar 2004 15:17:35 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D52232D4947 for ; Mon, 1 Mar 2004 15:17:05 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 36947-01-40 for ; Mon, 1 Mar 2004 15:17:04 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 87DCB2D4937 for ; Mon, 1 Mar 2004 15:17:03 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Idr] BGP-based VPLS Message-ID: Thread-Topic: [Idr] BGP-based VPLS Thread-Index: AcP/Z+OM98URFVCuTEiRHg0YjRgf5gAXP64g From: "Susan Hares" To: "Kireeti Kompella" , X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 15:17:03 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id PAA13460 Kireeti: Just to make sure, I understand you. You are suggesting: SAFI = 1,2,3 per draft SAFI = 65 per your draft Same afi, same BGP mechanisms in draft? Sue -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Monday, March 01, 2004 3:31 AM To: idr@ietf.org Subject: [Idr] BGP-based VPLS Following up on the discussion regarding BGP for L2VPN auto-discovery, draft-ietf-l2vpn-vpls-bgp-01.txt does auto-discovery and signaling for VPLS. Of special interest to this WG is section 3, where the NLRI format for this AFI/SAFI (*) pair, and other topics are described. (*) SAFI = 65; AFI not yet allocated. It seems sensible to use the AFI allocated for auto-discovery. Kireeti. ------- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA12999 for ; Mon, 1 Mar 2004 14:27:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt4B-0002Bn-9I; Mon, 01 Mar 2004 14:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqlR-0000Lx-5q for idr@optimus.ietf.org; Mon, 01 Mar 2004 11:59:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21282 for ; Mon, 1 Mar 2004 11:59:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxqbJ-0000gc-00 for idr@ietf.org; Mon, 01 Mar 2004 11:49:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axqa8-0000QO-00 for idr@ietf.org; Mon, 01 Mar 2004 11:47:53 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AxqZf-0000KR-00 for idr@ietf.org; Mon, 01 Mar 2004 11:47:23 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i21Gk6RX072941; Mon, 1 Mar 2004 11:46:06 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403011646.i21Gk6RX072941@workhorse.fictitious.org> To: Parantap Lahiri cc: curtis@fictitious.org, "'Pekka Savola'" , "'John G. Scudder'" , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: Your message of "Mon, 01 Mar 2004 10:33:11 EST." <019f01c3ffa2$81715960$c8922799@mcilink.com> From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 11:46:06 -0500 In message <019f01c3ffa2$81715960$c8922799@mcilink.com>, Parantap Lahiri writes : > Curtis, > > I was referring to a complete separate address space for the secondary > loopbacks and the idea was not to aggregate that space. It would be only in > IGP as discrete /32s, and if the node is gone, the /32 will be gone, thus > immediately invalidating the routes originated by it. The rest of the world > could still reach the box using the primary loopback address, which would be > aggregated and would be in BGP. > > Anyway, my initial message was delayed by the moderator and I found John > Scudder referring to this option in one of his later mails. So I think its > covered. > > -Parantap The way we did this when I was doing operations was we aggregated and sent the aggregate to EBGP peers. Since we didn't have the aggregate for our own address allocation within our AS this never came up. This also was not a problem because the loopback by definition cannot become unreachable, only interface addresses can become unreachable. IBGP peers should be announcing their loopback, which can never go down unless the router becomes completely unreachable. If the provider's aggregate is only sent outside the AS, then this is fine. I personally felt as an operator that if another provider is to *lazy* to configure the aggregate statement on each EBGP peer, and instead chooses to announce that aggreate into IBGP, then they get what they deserve. Working for a vendor now, I have to take the position that the customer can be as arbitrarily lazy as they like and thats just fine. This isn't a problem with the BGP protocol. Its a problem with the way some providers configure their networks (incorrectly) that is easily solved by not doing it that way, or can be solved by adding a config knob to the router to exclude aggreates from this AS from consideration in the reachability test or exclude specific prefixes. This is certainly something that can be addressed in a separate document. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA12995 for ; Mon, 1 Mar 2004 14:27:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt4C-0002DL-Pv; Mon, 01 Mar 2004 14:27:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxszH-00020v-9t for idr@optimus.ietf.org; Mon, 01 Mar 2004 14:21:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28881 for ; Mon, 1 Mar 2004 14:21:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxszE-0004Lg-00 for idr@ietf.org; Mon, 01 Mar 2004 14:21:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxsyM-0004GK-00 for idr@ietf.org; Mon, 01 Mar 2004 14:21:03 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1Axsxy-0004AU-00 for idr@ietf.org; Mon, 01 Mar 2004 14:20:38 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i21JJORX073772; Mon, 1 Mar 2004 14:19:24 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403011919.i21JJORX073772@workhorse.fictitious.org> To: Pedro Roque Marques cc: Yakov Rekhter , idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] Question on MinASOrig Timer In-reply-to: Your message of "Mon, 01 Mar 2004 09:54:34 PST." <200403011754.i21HsYHi049303@roque-bsd.juniper.net> From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 14:19:24 -0500 In message <200403011754.i21HsYHi049303@roque-bsd.juniper.net>, Pedro Roque Mar ques writes: > > Implementations are always free to and expected to have functionality > that is beyond what the standard specifies. Curtis can still add the > flexibility he believes necessary... while other implementors can make > their own judgement based on what they consider the best interest of > their users. Ultimately it is up to the operators whether to use such a feature or not. It does no harm to code it in and allow the operator the choice. I'm also fine with the idea of leaving the spec alone (which I'm sure will make Yakov and Sue a bit relieved). Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA12985 for ; Mon, 1 Mar 2004 14:27:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt4C-0002CZ-2B; Mon, 01 Mar 2004 14:27:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrLb-0003iz-54 for idr@optimus.ietf.org; Mon, 01 Mar 2004 12:36:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23951 for ; Mon, 1 Mar 2004 12:36:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxrLZ-0007Xx-00 for idr@ietf.org; Mon, 01 Mar 2004 12:36:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxrKi-0007Rh-00 for idr@ietf.org; Mon, 01 Mar 2004 12:36:01 -0500 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1AxrJz-0007IO-00 for idr@ietf.org; Mon, 01 Mar 2004 12:35:15 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HTW000BIR4ZDN@firewall.mci.com> for idr@ietf.org; Mon, 01 Mar 2004 17:26:59 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HTW00H01R3WSD@pmismtp01.mcilink.com>; Mon, 01 Mar 2004 17:26:59 +0000 (GMT) Received: from WS344V8066292 ([153.39.146.200]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HTW00HJLR2FBP@pmismtp01.mcilink.com>; Mon, 01 Mar 2004 17:25:27 +0000 (GMT) From: Parantap Lahiri Subject: RE: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: <200403011646.i21Gk6RX072941@workhorse.fictitious.org> To: curtis@fictitious.org Cc: "'Pekka Savola'" , "'John G. Scudder'" , idr@ietf.org Message-id: <01c101c3ffb2$300c2630$c8922799@mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 12:25:27 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id OAA12985 If you aggregate the prefixes just towards EBGP neighbors it definitely does solve the problem, but the issue is you will have to touch all your ebgp sessions once you get a new block to aggregate. Operator motto is have a design which requires least touching. Of course that can be equated to laziness, but it depends on which side of fence you are on. >This isn't a problem with the BGP protocol. Its a problem with the >way some providers configure their networks (incorrectly) that is >easily solved by not doing it that way, or can be solved by adding a >config knob to the router to exclude aggregates from this AS from >consideration in the reachability test or exclude specific prefixes. >This is certainly something that can be addressed in a separate >document. This is exactly what I suggested in the 2nd paragraph of my original mail. -----Original Message----- From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] Sent: Monday, March 01, 2004 11:46 AM To: Parantap Lahiri Cc: curtis@fictitious.org; 'Pekka Savola'; 'John G. Scudder'; idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In message <019f01c3ffa2$81715960$c8922799@mcilink.com>, Parantap Lahiri writes : > Curtis, > > I was referring to a complete separate address space for the secondary > loopbacks and the idea was not to aggregate that space. It would be only in > IGP as discrete /32s, and if the node is gone, the /32 will be gone, thus > immediately invalidating the routes originated by it. The rest of the world > could still reach the box using the primary loopback address, which would be > aggregated and would be in BGP. > > Anyway, my initial message was delayed by the moderator and I found John > Scudder referring to this option in one of his later mails. So I think its > covered. > > -Parantap The way we did this when I was doing operations was we aggregated and sent the aggregate to EBGP peers. Since we didn't have the aggregate for our own address allocation within our AS this never came up. This also was not a problem because the loopback by definition cannot become unreachable, only interface addresses can become unreachable. IBGP peers should be announcing their loopback, which can never go down unless the router becomes completely unreachable. If the provider's aggregate is only sent outside the AS, then this is fine. I personally felt as an operator that if another provider is to *lazy* to configure the aggregate statement on each EBGP peer, and instead chooses to announce that aggreate into IBGP, then they get what they deserve. Working for a vendor now, I have to take the position that the customer can be as arbitrarily lazy as they like and thats just fine. This isn't a problem with the BGP protocol. Its a problem with the way some providers configure their networks (incorrectly) that is easily solved by not doing it that way, or can be solved by adding a config knob to the router to exclude aggreates from this AS from consideration in the reachability test or exclude specific prefixes. This is certainly something that can be addressed in a separate document. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA12982 for ; Mon, 1 Mar 2004 14:27:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt49-0002AF-Pr; Mon, 01 Mar 2004 14:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axpum-00020Y-Nt for idr@optimus.ietf.org; Mon, 01 Mar 2004 11:05:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13110 for ; Mon, 1 Mar 2004 11:04:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxpqT-0002uE-00 for idr@ietf.org; Mon, 01 Mar 2004 11:00:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axpir-00000f-00 for idr@ietf.org; Mon, 01 Mar 2004 10:52:53 -0500 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx with esmtp (Exim 4.12) id 1AxpXd-0003m1-00 for idr@ietf.org; Mon, 01 Mar 2004 10:41:13 -0500 Received: from pmismtp05.wcomnet.com ([166.38.62.53]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HTW00H8DLVCM1@firewall.mci.com> for idr@ietf.org; Mon, 01 Mar 2004 15:33:12 +0000 (GMT) Received: from pmismtp05.wcomnet.com by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HTW00801LVBCQ@pmismtp05.mcilink.com>; Mon, 01 Mar 2004 15:33:12 +0000 (GMT) Received: from WS344V8066292 ([153.39.146.200]) by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HTW007VKLVBDL@pmismtp05.mcilink.com>; Mon, 01 Mar 2004 15:33:11 +0000 (GMT) From: Parantap Lahiri Subject: RE: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In-reply-to: <200402281824.i1SIO7RX049414@workhorse.fictitious.org> To: curtis@fictitious.org Cc: "'Pekka Savola'" , "'John G. Scudder'" , idr@ietf.org Message-id: <019f01c3ffa2$81715960$c8922799@mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 10:33:11 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id OAA12982 Curtis, I was referring to a complete separate address space for the secondary loopbacks and the idea was not to aggregate that space. It would be only in IGP as discrete /32s, and if the node is gone, the /32 will be gone, thus immediately invalidating the routes originated by it. The rest of the world could still reach the box using the primary loopback address, which would be aggregated and would be in BGP. Anyway, my initial message was delayed by the moderator and I found John Scudder referring to this option in one of his later mails. So I think its covered. -Parantap -----Original Message----- From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] Sent: Saturday, February 28, 2004 1:24 PM To: Parantap Lahiri Cc: 'Pekka Savola'; 'John G. Scudder'; idr@ietf.org Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes In message <00b801c3fd70$0badcd50$c8922799@mcilink.com>, Parantap Lahiri writes : > The problem Pekka is describing is definitely a very valid problem which > exists. I am not sure though if the fix is in some design modifications or > in fixing the spec itself. > > The ways to fix it by design modification would be ... > > The router R1 in question resets the BGP next-hop to some secondary loopback > address which is different from the primary loopback (part of the prefix/16) > and the secondary loopback address range is only in IGP as discrete /32s, > this problem might be mitigated. Though it's going to load the IGP with a > new set of IP prefixes and may be problematic in some situations since some > IGP protocols have limited capability to carry large number of IP prefixes. > > The other way to solve it might be a vendor implemented knob, where a > particular address range (like prefix/16) is never considered while doing > BGP next hop resolution. Though, I am not sure if this knob would be a part > of the spec. > > -Parantap I'm not sure what that has to do with discard routes unless you are talking about generating an aggregate and the next hop falling into the unused portion of the aggregate. If you allow the next hop to resolved to the unused portion of an aggregated, your implementation is simply broken. You can't forward on a aggregate you generate, you can only forward on the components that make up the aggregate and if you miss this distinction in your BGP implementation, that is just an implementation mistake. If OTOH, some other router did the aggregation and sent the aggregate into the IGP or IBGP, then the problem is not one that needs to be fixed in the spec. If allowing BGP learned routes to resolve BGP next hops, which is commonly configured, another knob that can be added is to exclude routes in which the aggregator is in the same AS. If that was not sufficient you'd need a knob to exclude specific prefixes. This is clearly outside of the BGP spec. It seems to me to be more a case of adding configuration knobs to cover up the problems caused by misconfiguration. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA12983 for ; Mon, 1 Mar 2004 14:27:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt4A-0002AN-CS; Mon, 01 Mar 2004 14:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqDH-0005VG-1O for idr@optimus.ietf.org; Mon, 01 Mar 2004 11:24:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16108 for ; Mon, 1 Mar 2004 11:24:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxqAr-0001qm-00 for idr@ietf.org; Mon, 01 Mar 2004 11:21:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axq9r-0001Lm-00 for idr@ietf.org; Mon, 01 Mar 2004 11:20:44 -0500 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1Axq8t-0001Ep-00 for idr@ietf.org; Mon, 01 Mar 2004 11:19:44 -0500 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i21GIVRX072804; Mon, 1 Mar 2004 11:18:31 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200403011618.i21GIVRX072804@workhorse.fictitious.org> To: Alex Zinin cc: idr@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Idr] Comments on draft-chen-bgp-redist-00.txt In-reply-to: Your message of "Mon, 01 Mar 2004 17:12:51 +0900." <5734391782.20040301171251@psg.com> From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 11:18:31 -0500 In message <5734391782.20040301171251@psg.com>, Alex Zinin writes: > Comments I brought up today: > > 1. The problem appears because there are two points within the router where > two routes are compared. The draft suggests that the BGP path selection > process is made consistent with the selection process in the routing > table (AdminDist-based). > > The question is whether the problem statement is applicable for the > implementations where BGP path selection and AD comparison happens > at the same time (from what I remember, gated did that). In other words, > the question is whether the problem is implementations specific or not, > and hence whether a change to the protocol is appropriate. > > 2. Suggestion: seems that the problem can be solved without changing the > best path selection process. > > The idea is to establish a 1:1 mapping between LOCAL_RPEF and AD, i.e. ta > ke > the AD value and use it as LOCAL_PREF value when importing (redistributin > g) > routes to BGP, and use the LOCAL_PREF value as the AD when installing rou > tes > in the routing table. The advantage is it automagically makes the route > selection decisions consistent not only within a single router, but > throughout the iBGP mesh too. > > Food for thoughts... > > -- > Alex > http://www.psg.com/~zinin/ Sounds like this could go in a follow up internet-draft. It is outside of BGP itself. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA12846 for ; Mon, 1 Mar 2004 14:10:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axsnj-0001SJ-NW; Mon, 01 Mar 2004 14:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxsnX-0001RE-P6 for idr@optimus.ietf.org; Mon, 01 Mar 2004 14:09:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28386 for ; Mon, 1 Mar 2004 14:09:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxsnV-00030u-00 for idr@ietf.org; Mon, 01 Mar 2004 14:09:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxsmW-0002tA-00 for idr@ietf.org; Mon, 01 Mar 2004 14:08:49 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AxslZ-0002jC-00 for idr@ietf.org; Mon, 01 Mar 2004 14:07:49 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id CDF592D485B for ; Mon, 1 Mar 2004 14:07:12 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 34976-02-70 for ; Mon, 1 Mar 2004 14:07:11 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 23BE72D480C for ; Mon, 1 Mar 2004 14:07:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Idr] FW: Here's the bundle for BGP to go to the IESG Message-ID: Thread-Topic: [Idr] FW: Here's the bundle for BGP to go to the IESG Thread-Index: AcP/RALSuN2jxTbUTESqu57qiw7g9QAFsoow From: "Susan Hares" To: "Alex Zinin" Cc: X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 14:07:10 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id OAA12846 http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-mibagent-survey-00.txt We'll make sure the -00.txt , -01.txt gets loaded next week. Sue -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Sunday, February 29, 2004 11:16 PM To: Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] FW: Here's the bundle for BGP to go to the IESG For information, the following two documents are not in the IETF draft repository-- > 6) BGP 4 Implementation Report draft-ietf-idr-bgp-implementation-00.txt > 7) BGP-4 V1 MIB implementation report draft-ietf-idr-bgp-mibagent-survey-01.txt --we'll have to wait until they are available before we can put them in the bundle and start the IETF LC on the whole group. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA12711 for ; Mon, 1 Mar 2004 13:54:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxsYD-0000NZ-Pl; Mon, 01 Mar 2004 13:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxsY5-0000N4-6V for idr@optimus.ietf.org; Mon, 01 Mar 2004 13:53:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27583 for ; Mon, 1 Mar 2004 13:53:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxsY2-0001Av-00 for idr@ietf.org; Mon, 01 Mar 2004 13:53:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxsX5-00013c-00 for idr@ietf.org; Mon, 01 Mar 2004 13:52:51 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AxsW9-0000sM-00 for idr@ietf.org; Mon, 01 Mar 2004 13:51:53 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i21IpN1K049437; Mon, 1 Mar 2004 10:51:23 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i21IpNKd049434; Mon, 1 Mar 2004 10:51:23 -0800 (PST) Message-Id: <200403011851.i21IpNKd049434@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pekka Savola Cc: idr@ietf.org Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd) In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 10:51:23 -0800 (PST) Pekka Savola writes: > What I'm arguing here that there seem to be very clear operational > reasons why the "BGP route must be used for forwarding" is very > counterproductive and we should fix/clarify the spec to have a more > useful definition for it. > Are there any killer arguments why this is *NOT* a good idea? What is the #1 goal of BGP ? The establishment of *loop free* paths between autonomous systems. How can you guarantee loop free properties ? via the as-path loop detection mechanism... This means that you can only gurantee no forwarding loops if traffic always follows routing. So advertising routes that are not used for forwarding breaks the BGP algorithm. And it means that you can no longer prove of trust the loop free property. But there are more mundane practical consequences: outside | | ----------- a --- b as x | | A and B are border gateways for a stub as (x). Both are configured to originate a given prefix 10.0.1/24 whenever that prefix is reachable throught its IGP. Additionally, they are configured w/ a discard route to 10.0.1/24, which discard traffic whenever the IGP route is not present. In case of failure, one likely gets one of the exit points w/ a discard route as its forwarding state, while the other exit point has a valid IGP route. If the gateway that has a discard route in the forwarding table does advertise the route from its peer gateway it will cause traffic to be dropped. Generalizing: - whenever BGP advertises a route that it doesn't use for forwarding, traffic can easily end up getting dropped. Would there be a kind soul that volunteers to keep a FAQ of this WG list ? That way we wouldn't need to rehash this discussion and the MRAI discussion every 6 months. Please file under: "Issues the WG as agreed not to agree". Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA12263 for ; Mon, 1 Mar 2004 13:15:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrwV-0006r1-IS; Mon, 01 Mar 2004 13:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrwK-0006qC-GK for idr@optimus.ietf.org; Mon, 01 Mar 2004 13:14:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26168 for ; Mon, 1 Mar 2004 13:14:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxrwI-0004ni-00 for idr@ietf.org; Mon, 01 Mar 2004 13:14:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxrvJ-0004gq-00 for idr@ietf.org; Mon, 01 Mar 2004 13:13:50 -0500 Received: from colossus.systems.pipex.net ([62.241.160.73]) by ietf-mx with esmtp (Exim 4.12) id 1AxruP-0004V7-00 for idr@ietf.org; Mon, 01 Mar 2004 13:12:53 -0500 Received: from tom3 (1Cust2.tnt15.lnd4.gbr.da.uu.net [62.188.144.2]) by colossus.systems.pipex.net (Postfix) with SMTP id A1FE51C00158; Mon, 1 Mar 2004 18:12:19 +0000 (GMT) Message-ID: <00b101c3ffb8$89bdf9a0$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Pekka Savola" , "idr" Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 18:10:44 -0000 It's a fair point but sounds more like draft-ietf-idr-bgp4-experience-protocol-03.txt than draft-ietf-idr-bgp4-23.txt Tom Petch -----Original Message----- From: Pekka Savola To: idr@ietf.org Date: 29 February 2004 06:24 Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes >After some off-list iteration, a revamped version of the possible text >could be: > >In certain common deployment scenarios, the next-hop addresses are >supposed to be valid only if resolved via routes of a specific type >(e.g., IGP, connected or local). There are likely less specific >routes from other sources (e.g., static or BGP) which may resolve the >next-hops as well, but such resolvability typically leads to problems >when the less specific route actually can't be used to reach the >next-hop, and the BGP routes are not invalidated even though their >next-hop is, for all intents and purposes, unroutable. Therefore, it >is advisable that the implementations allow the operator to specify >which routes should yield a positive result if they covered the the >next-hop. > >.. thoughts? This doesn't have any MAY/SHOULD etc. terminology, at >least yet -- maybe it should. > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA12078 for ; Mon, 1 Mar 2004 12:58:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axrg1-0005GS-Qe; Mon, 01 Mar 2004 12:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axrf7-0005EH-14 for idr@optimus.ietf.org; Mon, 01 Mar 2004 12:57:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24730 for ; Mon, 1 Mar 2004 12:57:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axrf5-0002AL-00 for idr@ietf.org; Mon, 01 Mar 2004 12:57:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxreG-00022W-00 for idr@ietf.org; Mon, 01 Mar 2004 12:56:12 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AxrdA-0001o3-00 for idr@ietf.org; Mon, 01 Mar 2004 12:55:04 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i21HsY1K049306; Mon, 1 Mar 2004 09:54:34 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i21HsYHi049303; Mon, 1 Mar 2004 09:54:34 -0800 (PST) Message-Id: <200403011754.i21HsYHi049303@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Yakov Rekhter Cc: idr@ietf.org Subject: Re: [Idr] Question on MinASOrig Timer In-Reply-To: <200402290009.i1T09Oo29392@merlot.juniper.net> References: <200402270722.i1R7MvRX031806@workhorse.fictitious.org> <200402290009.i1T09Oo29392@merlot.juniper.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 09:54:34 -0800 (PST) Yakov Rekhter writes: > Curtis, [clipped...] >> Pedro, >> >> If you have separate timers for route origination/advertisement and >> up/down and the best solution is to set them all the same then it >> is possible to set them all the same. >> >> If you specify that they must be the same and that doesn't turn out >> to be the best way to do things you are stuck. >> >> Its clear that there isn't agreement on the best solution, so for >> the time being flexibility is needed. > One point to keep in mind is that since we are moving the spec to a > Draft Standard, a *necessary* condition for relaxing the spec to > support the flexibility you mentioned above would be more than one > implementation that supports such flexibility. Just for the record... Regardless of the ietf process I'm opposed to modifying the spec. imho, the propagating withdrawls faster than updates is detrimental in a significant number of realistic scenarios. Also, it doesn't seem to me that the proponents of such change have considered the potential drawbacks that are inherent to any change in behaviour. Implementations are always free to and expected to have functionality that is beyond what the standard specifies. Curtis can still add the flexibility he believes necessary... while other implementors can make their own judgement based on what they consider the best interest of their users. This is also not by far the most confusing aspect regarding interoperability in MRAI. I belive the WG as decided previously that we agree not to agree on MRAI. But if we are going to discuss the topic then we should discuss not what timer values but what do the timer values mean exactly. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA08295 for ; Mon, 1 Mar 2004 05:30:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxkgT-0002SX-LS; Mon, 01 Mar 2004 05:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axkg2-0002Mz-KX for idr@optimus.ietf.org; Mon, 01 Mar 2004 05:29:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07865 for ; Mon, 1 Mar 2004 05:29:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axkfz-0002PK-00 for idr@ietf.org; Mon, 01 Mar 2004 05:29:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axkf2-0002KA-00 for idr@ietf.org; Mon, 01 Mar 2004 05:28:33 -0500 Received: from web25210.mail.ukl.yahoo.com ([217.12.10.70]) by ietf-mx with smtp (Exim 4.12) id 1AxkeG-0002AU-00 for idr@ietf.org; Mon, 01 Mar 2004 05:27:44 -0500 Message-ID: <20040301102712.85640.qmail@web25210.mail.ukl.yahoo.com> Received: from [67.170.234.128] by web25210.mail.ukl.yahoo.com via HTTP; Mon, 01 Mar 2004 10:27:12 GMT From: =?iso-8859-1?q?BGP=20Guru?= Subject: Re: [Idr] Question on MinASOrig Timer To: curtis@fictitious.org, Pedro Roque Marques Cc: idr@ietf.org In-Reply-To: <200402270722.i1R7MvRX031806@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 10:27:12 +0000 (GMT) --- Curtis Villamizar wrote: > > In message > <200402270650.i1R6oBuU039747@roque-bsd.juniper.net>, > Pedro Roque Mar > ques writes: > > Curtis Villamizar writes: > > > > > If withdraws propogate faster first the > unfeasible AS paths are > > > removed, then the feasible ones start > propogating. The result is > > > some withdraw followed by add but much less AS > path change in the > > > presence of cycles. > > > > The point in which we differ is that you equate > withdraws and updates > > w/ unfeasible and feasible paths. I don't believe > one can make that > > assumption. > > > > For a given AS, if you have as input an withdraw > that can result in an > > update being generated or vice-versa, depending on > the policy. > > > > You can have a link up event result in withdrawns > being generated, and > > a link down event result in updates. In other > words the addition of > > feasible paths, can result via policy, in > withdrawls. > > > > > Providing separate timers allows us to defer the > question of which > > > is preferable. > > > > Providing separate timers, imho, will just further > confuse the issue > > :-). It has already been showen that there is no > single choice of MRAI > > timer that is appropriate for all situations. Now > you propose an > > additional one. That is two parameters nobody > knows what the optimal > > setting should be. > > > > Furthermore, i believe that, due to the meshed > nature of internet > > connectivity, using different delays may increase > the duration of > > transients. > > > > Lets say that you start w/ a current path through > as3 and > > you have a link up event (a) that brings up a > prefered path. > > > > as 3 > > | > > --a-> as 1 --> as 4 > > > > --a-> as 2 --> as 4 > > > > If a is a peer route for as 1 but a customer route > for as 2, then by > > propagating the withdrawl faster you are > increasing the transient time > > and causing increase connectivity to create a > blackhole for as4. > > > > imho, currently there is only one good known value > for MRAI for both > > updates and withdrawls, and that is 0. Let BGP > speakers propagate > > updates as fast as they can, taking into account > that BGP itself > > already has embedded flow control mechanisms that > allow a receiver to > > pace a sender appropriatly. > > > > Unfortunatly, even that setting (0) has its > drawbacks. One is that > > values should probably be consistent within an as, > and there are very > > different interpretations of MRAI between > different vendors. The > > second is that in case of MED oscillations, MRAI > helps reduce the > > ammount of churn. > > > > regards, > > Pedro. > > > Pedro, > > If you have separate timers for route > origination/advertisement and > up/down and the best solution is to set them all the > same then it is > possible to set them all the same. > > If you specify that they must be the same and that > doesn't turn out to > be the best way to do things you are stuck. > > Its clear that there isn't agreement on the best > solution, so for the > time being flexibility is needed. > As everyone may know, Cisco SWs have the same MRAI of 30sec for both Advertised as well as Withdrawn NLRIs since IOS 12S and ISPs, including our NWs in Asia, dont seem to be having issues with this. I guess Juniper's implementation is the same, need to check (JUNOS guys please pitch in). IMO, the default configuration on the SWs should be good enough and capable of handling over 95% of deployment senarios. ISPs would like to play with knobs as little as possible on live NWs. 30sec is a good approx of transient link flaps and time-staggered Withdrawals do reduce traffic on the wire due to transient flaps. One would be more worried about loosing 150-200 peerings due to excessive control traffic rather than a few data-flows being black-holed for a few seconds. Hence it would be better to keep the MRAI/MAOI for withdrawals as well. One comment here, Cisco's 5sec MAOI seems far to frequent - desirable would be 15sec atleast. Also, I think per-peer MRAI/MAOI timers are a bit too excessive. I shudder at the thought that a Route-reflector/route-collector with 500 peerings will have 500 timers popping every 5secs. Is this standard and common-practise in implementations or can this be bettered? ___________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA07348 for ; Mon, 1 Mar 2004 03:33:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxirF-0000kx-RL; Mon, 01 Mar 2004 03:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axiqp-0000ji-Dz for idr@optimus.ietf.org; Mon, 01 Mar 2004 03:32:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02097 for ; Mon, 1 Mar 2004 03:32:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axiqn-00066Z-00 for idr@ietf.org; Mon, 01 Mar 2004 03:32:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axiq0-00061o-00 for idr@ietf.org; Mon, 01 Mar 2004 03:31:45 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=kummer.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AxipM-0005rb-00 for idr@ietf.org; Mon, 01 Mar 2004 03:31:04 -0500 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id i218UZPg027790 for ; Mon, 1 Mar 2004 00:30:35 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id i218UZLn027787 for ; Mon, 1 Mar 2004 00:30:35 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs From: Kireeti Kompella To: idr@ietf.org Message-ID: <20040301001457.L27706@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] BGP-based VPLS Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 00:30:35 -0800 (PST) Following up on the discussion regarding BGP for L2VPN auto-discovery, draft-ietf-l2vpn-vpls-bgp-01.txt does auto-discovery and signaling for VPLS. Of special interest to this WG is section 3, where the NLRI format for this AFI/SAFI (*) pair, and other topics are described. (*) SAFI = 65; AFI not yet allocated. It seems sensible to use the AFI allocated for auto-discovery. Kireeti. ------- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA07256 for ; Mon, 1 Mar 2004 03:22:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axign-0006Nj-Do; Mon, 01 Mar 2004 03:22:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axifv-0006HG-Db for idr@optimus.ietf.org; Mon, 01 Mar 2004 03:21:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01065 for ; Mon, 1 Mar 2004 03:21:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiYT-0003qt-00 for idr@ietf.org; Mon, 01 Mar 2004 03:13:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiXR-0003ky-00 for idr@ietf.org; Mon, 01 Mar 2004 03:12:33 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AxiWi-0003g8-00 for idr@ietf.org; Mon, 01 Mar 2004 03:11:48 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxiWj-000HNl-Ic for idr@ietf.org; Mon, 01 Mar 2004 08:11:49 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <9934308202.20040301171127@psg.com> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Idr] Experimental code-points Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 17:11:27 +0900 As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. -- Alex http://www.psg.com/~zinin/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA07250 for ; Mon, 1 Mar 2004 03:22:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axigg-0006LB-W0; Mon, 01 Mar 2004 03:22:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axifs-0006Gg-Pk for idr@optimus.ietf.org; Mon, 01 Mar 2004 03:21:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01031 for ; Mon, 1 Mar 2004 03:21:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiZU-0003xv-00 for idr@ietf.org; Mon, 01 Mar 2004 03:14:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiYb-0003sK-00 for idr@ietf.org; Mon, 01 Mar 2004 03:13:46 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AxiY4-0003lc-00 for idr@ietf.org; Mon, 01 Mar 2004 03:13:12 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxiY5-000HTj-1k for idr@ietf.org; Mon, 01 Mar 2004 08:13:13 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5734391782.20040301171251@psg.com> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Idr] Comments on draft-chen-bgp-redist-00.txt Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 17:12:51 +0900 Comments I brought up today: 1. The problem appears because there are two points within the router where two routes are compared. The draft suggests that the BGP path selection process is made consistent with the selection process in the routing table (AdminDist-based). The question is whether the problem statement is applicable for the implementations where BGP path selection and AD comparison happens at the same time (from what I remember, gated did that). In other words, the question is whether the problem is implementations specific or not, and hence whether a change to the protocol is appropriate. 2. Suggestion: seems that the problem can be solved without changing the best path selection process. The idea is to establish a 1:1 mapping between LOCAL_RPEF and AD, i.e. take the AD value and use it as LOCAL_PREF value when importing (redistributing) routes to BGP, and use the LOCAL_PREF value as the AD when installing routes in the routing table. The advantage is it automagically makes the route selection decisions consistent not only within a single router, but throughout the iBGP mesh too. Food for thoughts... -- Alex http://www.psg.com/~zinin/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr