From idr-bounces@ietf.org Thu Mar 01 10:52:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMnXg-0005mf-Jq; Thu, 01 Mar 2007 10:50:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMnXf-0005mB-6H for idr@ietf.org; Thu, 01 Mar 2007 10:50:03 -0500 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMnXc-0000qS-Mq for idr@ietf.org; Thu, 01 Mar 2007 10:50:03 -0500 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 246884E4A4; Thu, 1 Mar 2007 10:49:46 -0500 (EST) Date: Thu, 1 Mar 2007 10:49:46 -0500 From: Jeffrey Haas To: idr@ietf.org Subject: Re: [Idr] AFI IANA Considerations Message-ID: <20070301154946.GA6184@scc.mi.org> References: <200702241834.l1OIY2Bq045966@workhorse.brookfield.occnc.com> <20070227165125.GA27970@scc.mi.org> <200702271741.l1RHfcAD020331@bright.research.att.com> <32C55AD1-79D1-46E8-B14D-9CDF6096C70B@bgp.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32C55AD1-79D1-46E8-B14D-9CDF6096C70B@bgp.nu> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Thu, Mar 01, 2007 at 08:20:52AM +0800, John G. Scudder wrote: > Now that I come to think of it, here's Yet Another Variant which I > may have mentioned at the meeting where we discussed this: > > 25-16383: Standards Action + Early Assignment > 16384-32767: FCFS > 32768-65535: Reserved I'm in favor of this. > --John -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Mar 01 11:02:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMnil-0003RQ-1C; Thu, 01 Mar 2007 11:01:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMnik-0003RE-30 for idr@ietf.org; Thu, 01 Mar 2007 11:01:30 -0500 Received: from web31409.mail.mud.yahoo.com ([68.142.198.121]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HMnih-0002d1-Og for idr@ietf.org; Thu, 01 Mar 2007 11:01:30 -0500 Received: (qmail 74831 invoked by uid 60001); 1 Mar 2007 16:01:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=h9gNHyq6+vozdQNoefqfCtAgclFdc3b3Idap3Bqo8rRVqDKrC8A5Wl8oNkleOJ/jiHWc3CQuQqa8J5cZGTG3fC/+brT70Xq8csIGq6cEUBvDgusJpfnU5GuzNppQlfKlsRDbckVCin7EPqMzQu0rtBNRkJyTvoHiSY5yyQqOGUI=; X-YMail-OSG: PtioFskVM1mugRvYhb7m1.eT3OZmGP4lWpIDbxmLhoeREFgJb1xzc8nX4J_wjRWMcmep74lTZd0NjkcY2uReU5U_f.AmXG6TeJcSgOkaoWmzBkqD8Tiw Received: from [129.247.247.238] by web31409.mail.mud.yahoo.com via HTTP; Thu, 01 Mar 2007 08:01:26 PST Date: Thu, 1 Mar 2007 08:01:26 -0800 (PST) From: Serkan To: idr@ietf.org MIME-Version: 1.0 Message-ID: <97962.73654.qm@web31409.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Idr] Different inter domain routing protocols X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0385430810==" Errors-To: idr-bounces@ietf.org --===============0385430810== Content-Type: multipart/alternative; boundary="0-1811782370-1172764886=:73654" Content-Transfer-Encoding: 8bit --0-1811782370-1172764886=:73654 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, I started to work on inter domain routing algorithms and I am wondering how two different inter-domain routing algorihms run in one network simultaneously. Is there any RFC, web site or book explaining this concept? Kindly Regards, Serkan --------------------------------- Have a burning question? Go to Yahoo! Answers and get answers from real people who know. --0-1811782370-1172764886=:73654 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello,
I started to work on inter domain routing algorithms and I am wondering how two different inter-domain routing algorihms run in one network simultaneously. Is there any RFC, web site or book explaining this concept?
 
Kindly Regards,
 
Serkan

Have a burning question? Go to Yahoo! Answers and get answers from real people who know. --0-1811782370-1172764886=:73654-- --===============0385430810== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --===============0385430810==-- From idr-bounces@ietf.org Mon Mar 05 03:37:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO8do-0000zk-Vs; Mon, 05 Mar 2007 03:33:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO8dn-0000zX-KC for idr@ietf.org; Mon, 05 Mar 2007 03:33:55 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO8dm-0002lS-DL for idr@ietf.org; Mon, 05 Mar 2007 03:33:55 -0500 Received: from [192.168.1.3] (VDSL-151-118-37-135.DNVR.QWEST.NET [151.118.37.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 2460B64702 for ; Mon, 5 Mar 2007 01:33:38 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20070301154946.GA6184@scc.mi.org> References: <200702241834.l1OIY2Bq045966@workhorse.brookfield.occnc.com> <20070227165125.GA27970@scc.mi.org> <200702271741.l1RHfcAD020331@bright.research.att.com> <32C55AD1-79D1-46E8-B14D-9CDF6096C70B@bgp.nu> <20070301154946.GA6184@scc.mi.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <656C50E9-D804-4262-AA06-53E6DA06459D@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] AFI IANA Considerations Date: Mon, 5 Mar 2007 01:33:34 -0700 To: Inter-Domain Routing List X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Mar 1, 2007, at 8:49 AM, Jeffrey Haas wrote: > On Thu, Mar 01, 2007 at 08:20:52AM +0800, John G. Scudder wrote: >> Now that I come to think of it, here's Yet Another Variant which I >> may have mentioned at the meeting where we discussed this: >> >> 25-16383: Standards Action + Early Assignment >> 16384-32767: FCFS >> 32768-65535: Reserved > > I'm in favor of this. Me too.. I prefer this model, as I echoed at the mic at the last meeting. -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Mar 05 09:46:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEPC-0007Vs-41; Mon, 05 Mar 2007 09:43:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEPB-0007VB-De for idr@ietf.org; Mon, 05 Mar 2007 09:43:13 -0500 Received: from mail-red.research.att.com ([192.20.225.110]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOEP8-0007Gh-B0 for idr@ietf.org; Mon, 05 Mar 2007 09:43:13 -0500 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id 8EB13147B66; Mon, 5 Mar 2007 09:43:06 -0500 (EST) Received: (from fenner@localhost) by bright.research.att.com (8.13.1/8.12.10/Submit) id l25Eh611025541; Mon, 5 Mar 2007 06:43:06 -0800 From: Bill Fenner Message-Id: <200703051443.l25Eh611025541@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: "John G. Scudder" Subject: Re: [Idr] AFI IANA Considerations References: <200702241834.l1OIY2Bq045966@workhorse.brookfield.occnc.com> <20070227165125.GA27970@scc.mi.org> <200702271741.l1RHfcAD020331@bright.research.att.com> <32C55AD1-79D1-46E8-B14D-9CDF6096C70B@bgp.nu> Date: Mon, 5 Mar 2007 06:43:05 -0800 Versions: dmail (linux) 2.7/makemail 2.14 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: idr@ietf.org, Paul Jakma X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org >Now that I come to think of it, here's Yet Another Variant which I >may have mentioned at the meeting where we discussed this: > >25-16383: Standards Action + Early Assignment >16384-32767: FCFS >32768-65535: Reserved Seems like something that everyone can get behind. Barring an outcry before Thursday, this is what I will take to the IESG conference call to be approved. Bill _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Mar 09 16:37:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPmk0-0001UJ-OJ; Fri, 09 Mar 2007 16:35:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPmjz-0001UA-5R; Fri, 09 Mar 2007 16:35:07 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPmjy-0007T0-PK; Fri, 09 Mar 2007 16:35:07 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id AED5C2ACF8; Fri, 9 Mar 2007 21:34:36 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPmjU-0007x2-FT; Fri, 09 Mar 2007 16:34:36 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Fri, 09 Mar 2007 16:34:36 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: idr mailing list , idr chair , Internet Architecture Board , RFC Editor Subject: [Idr] Protocol Action: 'BGP Support for Four-octet AS Number Space' to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org The IESG has approved the following document: - 'BGP Support for Four-octet AS Number Space ' as a Proposed Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are Bill Fenner and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-13.txt Technical Summary Currently the Autonomous System number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity. Based on historical and current allocation rates, the range available to two-octet AS numbers is expected to run out in 2010. Working Group Summary This is a long-standing work item for the working group, with the first draft being published in February 2001. The approach described in the draft to support 4 Byte AS numbers is one of no change to BGP in terms of protocol in all but one aspect: The OPEN message uses a 4-Byte capability advertisement and the use of a 2 Byte MyAS field value. In all other respects there is no change to the protocol elements of BGP, other than using 4 bytes where ASs are used. The other substantive topic of the draft is in the interoperation of 4-Byte AS speakers with 2-Byte AS speakers. The OPEN message with capability advertisement has attracted one comment that this is contrary to RFC3392, however a detailed analysis of this comment has not lead to substantiation of this comment. Using this as a dynamic capability rather than an OPEN capability was raised as a comment, with the response that there is no reason to make the capability dynamic in this case. The tunnelling technique of using an opaque transitive community attribute to carry the 4-Byte AS Path attracted some comment. The comment was concerned with the reconstruction of the 4-Byte AS path across a 2-to-4 byte BGP boundary, where the algorithm for the reconstruction was, in some comments, not sufficiently well-defined. However it is also the case that the critical elements of the role of the AS Path are adequately described in the draft. The AS path length is used as a metric in the BGP path selection process, and the AS path itself is used for loop prevention. The draft specifies that the reconstruction of the AS path across a 2-byte to 4-byte AS transition should preserve the AS path length. The draft does not cover every possible eventuality of reconstruction of the 4-byte AS path, but a closer examination of the loop detection issue reveals that loops that may occur across a mixed 2 Byte / 4 Byte path are detectable within one iteration of the loop within the 2-Byte component of the mixed loop path in all circumstances. Accordingly, both the use of the AS path length as a path metric and the use of the AS path as a loop detection mechanism are preserved in this approach, even though the draft is not definitive in describing the AS path reassembly algorithm in every possible eventuality. In other words the draft contains the necessary and sufficient minimum set of properties for AS path reconstruction, leaving the precise algorithm up to the implementation. This approach is not seen as impairing the functionality, interoperability or integrity of BGP, either within the context of the individual peering session or in the context of the broader IDR framework. A comment was raised that on-the-wire inspection of BGP updates would not know in all cases whether they were seeing 2-byte or 4-byte AS BGP updates. The BGP update contains no additional control flags, and unless the on-the-wire device collects the initial OPEN message with the capability negotiation then the information as to 2-byte or 4-byte AS updates is not explicit. It has been noted that heuristics could be readily applied here, and the presence of the reserved 2-byte AS value 0 in the AS path is one indicator that the momitor is applying a 2-byte interpretation to a 4-byte BGP update. There were no other approaches referenced in the working group during Last Call, and the choice of this draft as representing one that is backwards compatible with existing BGP appears to have been an obvious obvious choice to the working group. The IETF Last call comments concernd the RFC3392 Capability Advertisement examination of these comments indicates that the concerns relating to RFC3392 are unwarranted, and the treatment of the capability advertisement is consistent with a conventional use of RFC3392 and is compatible with older versions of BGP. The IETF Last Call comments touched upon the larger size of BGP updates, and the desireability of using a compressed representation of AS Path. The Working Group did not see any need to include a compressed representation of AS paths in BGP updates. It appears that the onus of making a case that some form of compressed encoding of these BGP fields is of merit lies with the proponents of this as a potential source of problem, and the solution with respect to the AS_PATH representation lies in RFC3392 with additional capabilities being negotiated, either at session OPEN time or possibly dynamically. Thus, this 4-byte spec, that does not used compressed representation of AS_PATH is adequate, and those who believe that more compact representations are called for have a clear path of proposing such a specification to the IDR working group as a negotiated capability. The task for those who are of the opinion that such compact encodings are important to show why and propose a capability to be negotiated to do so in both the 4Byte and 2Byte worlds in the IDR Working Group. Protocol Quality Bill Fenner and Geoff Huston reviewed the document for the IESG. There are implementations; see the implementation report at http://www.ietf.org/IESG/Implementations/bgp4_impleme.txt _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Mar 16 09:36:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSCWd-0001ph-4V; Fri, 16 Mar 2007 09:31:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSCWb-0001pc-Bb for idr@ietf.org; Fri, 16 Mar 2007 09:31:17 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSCWV-0006TM-AM for idr@ietf.org; Fri, 16 Mar 2007 09:31:17 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by borg.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 16 Mar 2007 06:31:11 -0700 X-IronPort-AV: i="4.14,292,1170662400"; d="scan'208"; a="691350450:sNHT38848676" Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l2GDVAJ71547 for ; Fri, 16 Mar 2007 06:31:10 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200703161331.l2GDVAJ71547@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <56512.1174051870.1@juniper.net> Date: Fri, 16 Mar 2007 06:31:10 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Idr] slides X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Folks, If you are presenting at the upcoming IDR WG meeting in Prague, please send me your slides asap, so that I can make them available on-line. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Mar 16 17:34:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSJzy-0008M6-SC; Fri, 16 Mar 2007 17:30:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSJzx-0008JL-2G for idr@ietf.org; Fri, 16 Mar 2007 17:30:05 -0400 Received: from smtp-7.smtp.ucla.edu ([169.232.46.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSJzv-0001ZC-Mn for idr@ietf.org; Fri, 16 Mar 2007 17:30:05 -0400 Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.151]) by smtp-7.smtp.ucla.edu (8.13.8/8.13.8) with ESMTP id l2GLU2to030722 for ; Fri, 16 Mar 2007 14:30:02 -0700 Received: from [131.179.96.243] (Cs-96-243.CS.UCLA.EDU [131.179.96.243]) (authenticated bits=0) by mail.ucla.edu (8.13.8/8.13.8) with ESMTP id l2GLU2YE017135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 16 Mar 2007 14:30:02 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <4187324E-AF45-47ED-BF4C-2C5C51632837@cs.ucla.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: idr@ietf.org From: "Ricardo V. Oliveira" Date: Fri, 16 Mar 2007 14:31:20 -0700 X-Mailer: Apple Mail (2.752.2) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.46.138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Idr] Question about aggregation X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi, I have a question related to route aggregation, that I could not find specified in RFC4271. Suppose a router aggregates two entries: 10.0.1/24 and 10.0.2/24 with same ASPATH [A B C] into a single entry: 10.0/16 [A B C] Then 10.0.1/24 decides to change provider and switches to a new aspath [A D C], and we'll have in the table: 10.0/16 [A B C] 10.0.1/24 [A D C] which is fine since forwarding will follow longest match. Now suppose 10.0.2/24 decides to change providers to path [A E C], then we end up w/: 10.0/16 [A B C] 10.0.1/24 [A D C] 10.0.2/24 [A E C] And the initial entry is now a bogus entry. How do routers usually get rid of these stale entries? The same question applies if all more specific routes are withdrawn, is the aggregate also withdrawn? Do routers keep state of more specific routes in Adj-RIB-In and update Local-RIB accordingly? Also, in section 9.1.4 of the RFC (overlapping routes) it's said: "If a BGP speaker receives overlapping routes, the Decision Process MUST consider both routes based on the configured acceptance policy. If both a less and a more specific route are accepted, then the Decision Process MUST install, in Loc-RIB, either both the less and the more specific routes or aggregate the two routes and install, in Loc-RIB, the aggregated route, provided that both routes have the same value of the NEXT_HOP attribute." But in section 9.2.2.2 (aggregating routing information) it's said: "Path attributes of the same type code may be aggregated, according to the following rules: NEXT_HOP: When aggregating routes that have different NEXT_HOP attributes, the NEXT_HOP attribute of the aggregated route SHALL identify an interface on the BGP speaker that performs the aggregation. " So it seems the first sentence was not updated according to the aggregation rules of the new RFC. Thanks, --Ricardo _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Mar 21 06:25:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxxv-000760-7r; Wed, 21 Mar 2007 06:22:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxxt-00075s-Sh for idr@ietf.org; Wed, 21 Mar 2007 06:22:45 -0400 Received: from gateout01.mbox.net ([165.212.64.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTxxo-0002x4-HM for idr@ietf.org; Wed, 21 Mar 2007 06:22:45 -0400 Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id 249C01768 for ; Wed, 21 Mar 2007 10:22:21 +0000 (GMT) Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.34P) with ESMTP id XID483LcukwV1024Xo1; Wed, 21 Mar 2007 10:22:21 -0000 X-USANET-Source: 165.212.116.254 IN skh@nexthop.com GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID483LcukwV1024Xo1 Received: from VS4.EXCHPROD.USA.NET ([10.116.208.141]) by GW1.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 04:22:21 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Mar 2007 04:22:22 -0600 Message-ID: <6F44D7F6B24A8F4DA0AB46C9BE924F0209F07D6F@VS4.EXCHPROD.USA.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BGP MIB v2 input Thread-Index: AcdrotBYf0SL4lJPTAyCNAxIr0uEVg== From: "Susan Hares" To: X-OriginalArrivalTime: 21 Mar 2007 10:22:21.0147 (UTC) FILETIME=[CF611AB0:01C76BA2] X-Spam-Score: 0.2 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Cc: Jeffrey Haas , shares@nexthop.com Subject: [Idr] BGP MIB v2 input X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1026531845==" Errors-To: idr-bounces@ietf.org This is a multi-part message in MIME format. --===============1026531845== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76BA2.CF490F4B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76BA2.CF490F4B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working group: =20 Simon Leinen and Pekka Savola indicated the current MIB is not sufficient, And that portions of BGP MIBv2 that allow operators to see the: =20 - amount of prefixes received, and - amount of prefixes filtered. =20 Please send what in BGP MIB v2 is useful to you. =20 The BGP MIB v2 has been in limbo for 5 years due to lack of feedback.=20 =20 We would like to encourage feedback from operators who actually use these variables.=20 =20 Please send what variables you use to the list. =20 Sue Hares =20 ------_=_NextPart_001_01C76BA2.CF490F4B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Working group:

 

Simon Leinen and Pekka Savola indicated the current MIB is not = sufficient,

And that portions of BGP MIBv2 that allow = operators to see the:

 

-       = amount of prefixes received, and

-       = amount of prefixes filtered.

 

Please send what in BGP MIB v2 is useful to = you.

 

The BGP MIB v2 has been in limbo for 5 years = due to lack of feedback.

 

We would like to encourage feedback from = operators who actually use these variables.

 

Please send what variables you use to the = list.

 

Sue Hares

 

------_=_NextPart_001_01C76BA2.CF490F4B-- --===============1026531845== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --===============1026531845==-- From idr-bounces@ietf.org Wed Mar 21 11:08:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU2O2-00048x-7G; Wed, 21 Mar 2007 11:06:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU2O0-00048k-3j for idr@ietf.org; Wed, 21 Mar 2007 11:06:00 -0400 Received: from diotima.switch.ch ([2001:620:0:4:203:baff:fe4c:d751]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU2Nh-0000uA-5e for idr@ietf.org; Wed, 21 Mar 2007 11:06:00 -0400 Received: from diotima (localhost [127.0.0.1]) by diotima.switch.ch (8.13.8+Sun/8.13.8) with ESMTP id l2LF5YGa007551; Wed, 21 Mar 2007 16:05:35 +0100 (CET) From: Simon Leinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17921.18878.834053.856771@limmat.switch.ch> Date: Wed, 21 Mar 2007 16:05:34 +0100 To: "Susan Hares" Subject: Re: [Idr] BGP MIB v2 input In-Reply-To: <6F44D7F6B24A8F4DA0AB46C9BE924F0209F07D6F@VS4.EXCHPROD.USA.NET> References: <6F44D7F6B24A8F4DA0AB46C9BE924F0209F07D6F@VS4.EXCHPROD.USA.NET> X-Mailer: VM 7.18 under Emacs 22.0.95.1 X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` X-Spam-Score: -2.8 (--) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: idr@ietf.org, Jeffrey Haas , shares@nexthop.com X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Susan Hares writes: > Working group: > Simon Leinen and Pekka Savola indicated the current MIB is not > sufficient, For reference, the current MIB is now RFC 4273, which is almost identical to the venerable RFC 1657. The "MIBv2" I-D has expired (not for the first time), but can be retrieved from: http://tools.ietf.org/wg/idr/draft-ietf-idr-bgp4-mibv2/ > And that portions of BGP MIBv2 that allow operators to see the: > - amount of prefixes received, and > - amount of prefixes filtered. Pekka raised these, and as an operator, I would also find them quite useful for monitoring peerings' sanity (peer going berserk?) and evolution (when it might be time for me to update filters, max-prefixes, get rid of the peering because it has become insignificant etc.) They are available in MIBv2 as "bgpM2PrefixInPrefixes" (number of prefixes currently received from a peer for an address family), and "bgpM2PrefixInPrefixesAccepted/bgpM2PrefixInPrefixesRejected", respectively. It seems to me that these three variables are slightly redundant (although as an operator, I should probably like redundancy :-), as ...InPrefixes = ...InPrefixesAccepted + ...InPrefixesRejected. (I asked a MIB doctor who happened to be sitting next to me, and he said it would be better to avoid this kind of redundancy in a MIB.) > Please send what in BGP MIB v2 is useful to you. Definitely useful: Everything that's under bgpM2PrefixCountersTable (except one of the three objects mentioned above, to remove the redundancy). I especially like the fact that this table (and all others) allow peerings over IPv6 to be monitoring. We cannot currently do this in our network, and that is a pain. > The BGP MIB v2 has been in limbo for 5 years due to lack of feedback. > We would like to encourage feedback from operators who actually use > these variables. We cannot use them since they don't exist, but we would use them almost instantly if we had software that supported them, even in vendor-specific variants. > Please send what variables you use to the list. -- Simon. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Mar 22 04:26:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUIa1-000642-Du; Thu, 22 Mar 2007 04:23:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUIa0-00063s-1m for idr@ietf.org; Thu, 22 Mar 2007 04:23:28 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUIZy-00036Y-OC for idr@ietf.org; Thu, 22 Mar 2007 04:23:28 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id 0EE4123F3A; Thu, 22 Mar 2007 09:23:12 +0100 (CET) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id 3F21923EFD; Thu, 22 Mar 2007 09:23:11 +0100 (CET) Received: from [127.0.0.1] (gorilla.ripe.net [193.0.1.204]) by herring.ripe.net (Postfix) with ESMTP id 0CD482F583; Thu, 22 Mar 2007 09:23:11 +0100 (CET) Message-ID: <46023CD5.4020101@ripe.net> Date: Thu, 22 Mar 2007 09:22:45 +0100 From: Henk Uijterwaal Organization: RIPE NCC User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Simon Leinen Subject: Re: [Idr] BGP MIB v2 input References: <6F44D7F6B24A8F4DA0AB46C9BE924F0209F07D6F@VS4.EXCHPROD.USA.NET> <17921.18878.834053.856771@limmat.switch.ch> In-Reply-To: <17921.18878.834053.856771@limmat.switch.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.004007 / -4.4 X-RIPE-Signature: 5ffdfa32b3f8ab8f223e7c098819bff8 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Susan Hares , idr@ietf.org, Jeffrey Haas , shares@nexthop.com X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Simon and others: Simon Leinen wrote: > Susan Hares writes: >> Working group: >> Please send what in BGP MIB v2 is useful to you. It supports 32 bit AS Numbers, the current MIB doesn't as it says: bgpPathAttrASPAth OBJECT-TYPE SYNTAX OCTET STRING (SIZE (2..255)) [...] EAch AS is represented as a pair of octets according to the following algorithm: first-byte-of-pair = ASNumber / 256 second-byte-of-pair = ASNumber & 255; [...] bgpPeerRemoteAs OBJECT-TYPE SYNTAX Integer32 (0...65535) Either one will fail for AS1.0 and everything beyond that. The new draft has an AS type that fixes this. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ # Lawyer: "Now sir, I'm sure you are an intelligent and honest man--" # Witness: "Thank you. If I weren't under oath, I'd return the compliment." _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Mar 22 08:43:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUMb8-0001J8-0L; Thu, 22 Mar 2007 08:40:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUMb6-0001J3-Pr for idr@ietf.org; Thu, 22 Mar 2007 08:40:52 -0400 Received: from gateout01.mbox.net ([165.212.64.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUMb5-0003ep-Dv for idr@ietf.org; Thu, 22 Mar 2007 08:40:52 -0400 Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id D40D21AF5 for ; Thu, 22 Mar 2007 12:40:28 +0000 (GMT) Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.34P) with ESMTP id XID159LcVmOC0378Xo1; Thu, 22 Mar 2007 12:40:28 -0000 X-USANET-Source: 165.212.116.254 IN skh@nexthop.com GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID159LcVmOC0378Xo1 Received: from VS4.EXCHPROD.USA.NET ([10.116.208.141]) by GW2.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 06:39:53 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 Mar 2007 06:40:27 -0600 Message-ID: <6F44D7F6B24A8F4DA0AB46C9BE924F0209F9BBE7@VS4.EXCHPROD.USA.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BGP MIBv2 implementations Thread-Index: Acdsf0UMCZIEL7GdTDCgg+PqG5UUNw== From: "Susan Hares" To: X-OriginalArrivalTime: 22 Mar 2007 12:39:53.0132 (UTC) FILETIME=[305BD6C0:01C76C7F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Subject: [Idr] BGP MIBv2 implementations X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0352953520==" Errors-To: idr-bounces@ietf.org This is a multi-part message in MIME format. --===============0352953520== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76C7F.458F4589" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76C7F.458F4589 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If anyone has implemented any portion of the BGP MIBv2, would you please send mail to the mail list Indicating: =20 1) What you've implemented 2) What's useful. =20 sue ------_=_NextPart_001_01C76C7F.458F4589 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If anyone has implemented any portion of the BGP = MIBv2, would you please send mail to the mail list

Indicating:

 

1)     = What you’ve implemented

2)     = What’s useful.

 

sue

------_=_NextPart_001_01C76C7F.458F4589-- --===============0352953520== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --===============0352953520==-- From idr-bounces@ietf.org Thu Mar 22 10:54:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOcv-0004uc-1O; Thu, 22 Mar 2007 10:50:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOcA-0003p1-Ox; Thu, 22 Mar 2007 10:50:06 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUOc9-0003Xe-Lj; Thu, 22 Mar 2007 10:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 5A84926F2B; Thu, 22 Mar 2007 14:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HUOc6-0008AI-Rl; Thu, 22 Mar 2007 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 22 Mar 2007 10:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-avoid-transition-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org --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 : Avoid BGP Best Path Transitions from One External to Another Author(s) : E. Chen, S. Sangli Filename : draft-ietf-idr-avoid-transition-05.txt Pages : 7 Date : 2007-3-22 In this document we propose an extension to the BGP route selection rules that would avoid unnecessary best path transitions between external paths under certain conditions. The proposed extension would help the overall network stability, and more importantly, would eliminate certain BGP route oscillations in which more than one external path from one BGP speaker contributes to the churn. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-avoid-transition-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-avoid-transition-05.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-avoid-transition-05.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: <2007-3-22061338.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-avoid-transition-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-avoid-transition-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-22061338.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- From idr-bounces@ietf.org Thu Mar 22 13:36:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUR9j-0006Uw-Lk; Thu, 22 Mar 2007 13:32:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUR9h-0006Qh-F6 for idr@ietf.org; Thu, 22 Mar 2007 13:32:53 -0400 Received: from utopia.opentransit.net ([193.251.151.78]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HUR9T-0003fa-2O for idr@ietf.org; Thu, 22 Mar 2007 13:32:53 -0400 Received: from utopia.opentransit.net (localhost [127.0.0.1]) by utopia.opentransit.net (8.13.8/8.13.8/Debian-3) with ESMTP id l2MHWWPk010767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2007 18:32:33 +0100 Received: (from vgi@localhost) by utopia.opentransit.net (8.13.8/8.13.8/Submit) id l2MHWPOv010766; Thu, 22 Mar 2007 18:32:25 +0100 Date: Thu, 22 Mar 2007 18:32:25 +0100 From: Vincent GILLET - Orange - France Telecom To: Susan Hares Subject: Re: [Idr] BGP MIBv2 implementations Message-ID: <20070322173224.GA10666@opentransit.net> References: <6F44D7F6B24A8F4DA0AB46C9BE924F0209F9BBE7@VS4.EXCHPROD.USA.NET> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <6F44D7F6B24A8F4DA0AB46C9BE924F0209F9BBE7@VS4.EXCHPROD.USA.NET> User-Agent: Mutt/1.5.13 (2006-08-11) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (utopia.opentransit.net [127.0.0.1]); Thu, 22 Mar 2007 18:32:33 +0100 (CET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org skh@nexthop.com disait : > If anyone has implemented any portion of the BGP MIBv2, would you please > send mail to the mail list > > Indicating: > > > > 1) What you've implemented > > 2) What's useful. We (France telecom) are using BGPMIBv2 implemented by Juniper year ago in their .enterprise. node (1.3.6.1.4.1.2636.5.1.1.2....). It is working just fine and bring feature we were missing in legacy mib : . accepted prefixes . sent prefixes. We monitor hundreds box running full bgp routing (Juniper, Cisco, IOX) and are happy to monitor these counters on Juniper. We are really missing such data from other vendor. It also provide v6 flavour we are missing. Without such MIB, we are currently using telnet to monitor ipv6 session :-( Monitoring via telnet is done once a day whereas SNMP run every 5 minutes. Just to let you know that we are happy with this new MIB implemented in Juniper Private area. This MIB in "standard" tracks would help for widely implementation. Vincent. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Mar 26 00:59:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVhAI-0008Lz-Pt; Mon, 26 Mar 2007 00:50:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVhAH-0008Ls-Md for idr@ietf.org; Mon, 26 Mar 2007 00:50:41 -0400 Received: from mail-red.research.att.com ([192.20.225.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVhAG-00037c-G7 for idr@ietf.org; Mon, 26 Mar 2007 00:50:41 -0400 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-green.research.att.com (Postfix) with ESMTP id 2060E8757 for ; Mon, 26 Mar 2007 00:50:38 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.13.1/8.12.10/Submit) id l2Q4obpc001219; Mon, 26 Mar 2007 06:50:38 +0200 From: Bill Fenner Message-Id: <200703260450.l2Q4obpc001219@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: idr@ietf.org Subject: Re: [Idr] BGP MIB v2 input References: <6F44D7F6B24A8F4DA0AB46C9BE924F0209F07D6F@VS4.EXCHPROD.USA.NET> <17921.18878.834053.856771@limmat.switch.ch> Date: Mon, 26 Mar 2007 06:50:37 +0100 Versions: dmail (linux) 2.7/makemail 2.14 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org It may be worth breaking this down into areas of limitation of the current MIB: 1. v6 peer support 2. v6 and other NLRI support 3. 4-byte AS support 4. extra counters desired (Others?) #1 can be taken care of with a rev of the peer table using the InetAddressType/InetAddress TCs. For #2, I have a somewhat radical proposal, which is to eliminate the reporting of the BGP table contents via SNMP. The radical replacement would be a "lookup request" which you do by writing an AFI, SAFI, NLRI to a lookup table, specifying whether you want longest match or all matches, and you read the results from a lookup results table. (a few reasons for this change: a) It's not very efficient to have an SNMP table with 200k+ rows; b) It's hard to represent, e.g., VPN routes; and c) You probably want to know "what routes do you know for this destination", which is not easy to answer even with the existing indexing, since "destination" is probably a /32 and the prefix in the table is probably not) #3 is straightforward, especially since between #1 and #2 we're probably changing most of the places you see an AS number anyway. #4 is straightforward too if we know exactly which counters are useful. Although there are problems that the original BGP MIBv2 effort tried to solve that aren't on my list, I'd propose ignoring them for now in order to make *some* progress. Bill _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Mar 26 01:42:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVhx7-0002iN-Bs; Mon, 26 Mar 2007 01:41:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVhx6-0002h6-Jp for idr@ietf.org; Mon, 26 Mar 2007 01:41:08 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVhx5-0000Uy-0n for idr@ietf.org; Mon, 26 Mar 2007 01:41:08 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l2Q5eeTG020674 for ; Mon, 26 Mar 2007 08:40:41 +0300 Date: Mon, 26 Mar 2007 08:40:40 +0300 (EEST) From: Pekka Savola To: idr@ietf.org Subject: Re: [Idr] BGP MIB v2 input In-Reply-To: <200703260450.l2Q4obpc001219@bright.research.att.com> Message-ID: References: <6F44D7F6B24A8F4DA0AB46C9BE924F0209F07D6F@VS4.EXCHPROD.USA.NET> <17921.18878.834053.856771@limmat.switch.ch> <200703260450.l2Q4obpc001219@bright.research.att.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.1/2924/Sun Mar 25 15:56:14 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=5.0 tests=NO_RELAYS, TW_JN autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Mon, 26 Mar 2007, Bill Fenner wrote: > It may be worth breaking this down into areas of limitation of the > current MIB: > 1. v6 peer support > 2. v6 and other NLRI support > 3. 4-byte AS support > 4. extra counters desired > (Others?) .. As I mentioned at the mike, I believe the counters for prefixes rejected by policy (whether this also includes AS-path loops, invalid next-hops etc. doesn't matter to me) apart from those that are accepted by policy but not necessarily the preferred ones right now. This can be used for monitoring how well BGP prefix filters etc. are functioning. As a bonus, it'd be nice to be able to see which prefixes are stuck in the inbound policy filter, but that's not mandatory. Support for reporting information on IPv6 peers and non-IPv4 NLRIs would also be very welcome. ... Below is some information about what some implementations do: Juniper reports the following support on their web page (which we are already using) for JunOS: ==8<== Internet draft draft-ietf-idr-bgp4-mibv2-04.txt, Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), Second Version (only the objects jnxBgpM2PrefixInPrefixes, jnxBgpM2PrefixInPrefixesAccepted, and jnxBgpM2PrefixInPrefixesRejected) ==8<== [Note: they actually support slightly more than that, e.g., most or all of peer-status objects, but for example not dumping all the BGP routes using SNMP.] With the MIB at: http://www.juniper.net/techpubs/software/junos/junos82/swconfig82-net-mgmt/html/mib-jnx-bgpmib2.txt Note: Juniper's current implementation of BgpM2PrefixInPrefixesRejected is broken as it counts all non-active routes instead of those rejected by policy. Surfing around a bit, Cisco IOS XR 3.4 at least claims to support draft-ietf-idr-bgp4-mibv2-05.txt (though under 'BGP Next Hop Tracking enhancements' so I suspect they don't implement the full MIB either). In some other software trains, Cisco also seems to support some of the features of the new BGP mib, such as the number of 'received routes' but not the whole MIB as such: http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00802259e0.html#wp1059248 -- 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-bounces@ietf.org Mon Mar 26 09:38:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVpJz-0002po-5y; Mon, 26 Mar 2007 09:33:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVpJy-0002l2-0Q for idr@ietf.org; Mon, 26 Mar 2007 09:33:14 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVpJv-0006g0-OP for idr@ietf.org; Mon, 26 Mar 2007 09:33:13 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 027FE4E4AA; Mon, 26 Mar 2007 09:32:51 -0400 (EDT) Date: Mon, 26 Mar 2007 09:32:50 -0400 From: Jeffrey Haas To: Bill Fenner Subject: Re: [Idr] BGP MIB v2 input Message-ID: <20070326133250.GB8422@scc.mi.org> References: <6F44D7F6B24A8F4DA0AB46C9BE924F0209F07D6F@VS4.EXCHPROD.USA.NET> <17921.18878.834053.856771@limmat.switch.ch> <200703260450.l2Q4obpc001219@bright.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200703260450.l2Q4obpc001219@bright.research.att.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Mon, Mar 26, 2007 at 06:50:37AM +0100, Bill Fenner wrote: > It may be worth breaking this down into areas of limitation of the > current MIB: > > 1. v6 peer support > 2. v6 and other NLRI support > 3. 4-byte AS support > 4. extra counters desired > (Others?) > > #1 can be taken care of with a rev of the peer table using > the InetAddressType/InetAddress TCs. > > For #2, I have a somewhat radical proposal, which is to eliminate > the reporting of the BGP table contents via SNMP. The radical > replacement would be a "lookup request" which you do by writing > an AFI, SAFI, NLRI to a lookup table, specifying whether you want > longest match or all matches, and you read the results from a > lookup results table. > > (a few reasons for this change: > a) It's not very efficient to have an SNMP table with 200k+ rows; > b) It's hard to represent, e.g., VPN routes; and > c) You probably want to know "what routes do you know for > this destination", which is not easy to answer even with the > existing indexing, since "destination" is probably a /32 and > the prefix in the table is probably not) #2 is an intriguing idea. Existing UI implementations already cover having multiple "processes" access the routing table simultaneously. However, I think this may have some interesting implementation headaches. Could you please comment on them? - This would require set/write access to the MIB, correct? If so, that's one of the things that people expressed serious reservations about for any purpose previously. If not, are people on board with dynamic queries using get operations where getnext wouldn't work? - The results would likely be some sort of dynamically created OID tree for each query. UIs such as a CLI tend to have reasonably well understood lifetimes for their route table walking routines, but MIBs have a much less well defined interface. Additionally, if you're running the same query over and over, you may end up with multiple views instatiated which may have excessive overhead. Further, you don't have any sort of static OID you can use to monitor the state of a particular route. - The results of this query would seem to be the same MIB structure as one would have for the entire routing table. MIB structure-wise, I don't think we save any complexity. If these premises are true to one extent or another, that still leads to an interesting possibility. We could still have the necessary query objects. The result would then be a rowpointer to the root of the existing routing table's subtree that matched the query. There would be no need to dynamically generate views of the routing table, however there would need to be a little intelligence in the querying routine to stop walking after you've hit a less specific route. > #3 is straightforward, especially since between #1 and #2 > we're probably changing most of the places you see an > AS number anyway. The choice I made in the updates was to simply have the base routing table be 4-byte aware. The annoying case is a 2-byte to 4-byte transition speaker where three versions of the objects may be present: The active derived set, the received 2-byte path attributes and the received 4-byte path attributes. In the interest of simplicity in the base MIB, I'm suggesting the additional transitional views be left to an extention MIB. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Mar 26 12:15:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVrod-0005PZ-Rz; Mon, 26 Mar 2007 12:13:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVroc-0005PU-Kt for idr@ietf.org; Mon, 26 Mar 2007 12:13:02 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVrob-00089i-3a for idr@ietf.org; Mon, 26 Mar 2007 12:13:02 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by borg.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 26 Mar 2007 09:12:56 -0700 X-IronPort-AV: i="4.14,330,1170662400"; d="scan'208"; a="696978428:sNHT35864108" Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l2QGCuJ10341 for ; Mon, 26 Mar 2007 09:12:56 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200703261612.l2QGCuJ10341@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <44256.1174925576.1@juniper.net> Date: Mon, 26 Mar 2007 09:12:56 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Subject: [Idr] IDR WG minutes X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Folks, Please review the minutes for correctness. The deadline for comments is April 8. Yakov. ----------------------------------------------------------------- IDR WG minutes IETF-68 Prague March 21 2007 0900 1. Document status report (Yakov) Lots of progress in publishing docs as RFCs -- many published, many more in queue, see slides. Procedures for handling AFI allocations -- brief discussion at last IETF, subsequently on mailing list. Rules approved by IESG. We have SA, FCFS, and reserved. See slides for details. List of docs on which no progress -- see slides. No objections for draft-lefaucheur-idr-v4nlri-v6nh-00 as WG doc, but weak support. Since revised to -01. Note that softwire mesh framework refs this as normative, so there is need for this doc to exist, so will be accepted as IDR WG doc. BGP MIBv2 -- been around for six years. -05 version of draft expired a year ago and nobody seems to care. Editors seem to have abandoned it. Yakov and Sue periodically bump milestone forward a couple years. What should WG do with this draft? - - Pekka Savola -- speaking as an operator, current MIB isn't sufficient, we are using new MIB and some vendors are implementing, for example being able to see amount of prefixes we receive and have filtered out is useful. Would be good to survey what is actually useful in MIBv2 - - Sue Hares -- Pekka, can you do the MIB revision? - - Pekka -- I'd be happy to send feedback but not to edit it. - - Yakov -- unless we get an editor to adopt it, we won't have progress on it. Pekka, you have a valid point but without someone to work on it, there's nothing to be done. - - Simon Leinen -- I also have concerns that this is really required to operate BGP in a multiprotocol world. I volunteer to do what's necessary to help. I'm not normally on the IDR mailing list, but I'm concerned about this. - - Yakov -- OK, how about this? We extend the milestone one more year. If we make progress, great. If there's again no progress on the MIB, we remove the milestone. - - Simon -- fair enough. draft-fedyk-bgp-te-attribute-02.txt (Hamid Ould-Brahim) Traffic Engineering Attribute -- completing VPN auto-discovery for L1VPN. See slides for details. - - JP Vasseur -- should we resurrect 2 year old TE attribute draft we did for L3VPN and integrate the two? - - Yakov -- which WG should it be in? L1VPN, L3VPN, CCAMP, IDR...? - - Adrian Farrel -- we should discuss at routing area open meeting. CCAMP seems like the right place. - - Yakov -- will integrate John Scudder's comments. - - JP -- how about old draft? - - Yakov -- old draft introduces new SAFI, we don't understand why. - - JP -- would need to discuss with authors of old draft. draft-asati-bgp-mpls-blackhole-avoidance-00.txt (Rajiv Asati) Data plane failure in MPLS networks has bad consequences. Should fix this in the route resolvability check. See slides for details. - - Ina Minei -- seems to me that this is implementation specific. Why should this be fixed at protocol level? Other implementations don't suffer from similar problems. - - Rajiv -- fair enough. Just because some implementations don't suffer from a subset of the problem, doesn't mean it's not a valid problem. For example if you use ordered LDP that hides the problem, but what about data plane failures, e.g. data corruption? - - Ina -- OK you agree that LDP-ordered fixes it. What about corruption in labeled path? Other implementations have a fix for that too. So, why spec it? - - Rajiv -- well we can fix anything in theory. What is sense from operators in the room? - - Ina -- AND, should solution be at protocol level or implementation level? - - Yakov -- for presenter: what specific changes do you require from the protocol? What do I need to change to support this? - - Rajiv -- bestpath changes. That's all. Not a change within the on- the-wire protocol at all. Other change is the means to interact with LSP Health DB. - - Yakov -- LHD is outside scope of BGP, base spec doesn't talk about how to interact with ANY other protocols. Sounds like you want this WG to change route selection algorithm. - - Chandra Appanna -- I pretty much agree that there is not much to standardize here. - - Rajiv -- changing the route resolvability check is the only part relevant for the WG. - - Ina -- and does that need to be spec'd? - - Yakov -- well the current spec is nebulous. - - Chandra -- maybe we need to say that implementations should be smart about interpreting what "next hop reachability means" - - Yakov -- exactly. They shouldn't be dogmatic when reading the BGP spec. - - ??? (name not stated at mic) -- I agree with Yakov. I suggest this is informational. LDP black holing is an implementation problem. I think that this is very helpful. - - Yakov -- any closure on what to do with this doc? Anyone read it? (Lots of hands.) OK what do you want to do with doc? - - Chandra -- if there is interest on the list, maybe this can be informational. Other than that, not much point in making the "be smart" statement. - - Yakov -- one thing we should try to avoid is to prescribe a certain way of implementing. Not our business. - - John Scudder -- fundamental premise OK but seems like a lot of pages to make a simple point, and too much implementation details. Isn't basic point that if network layer foo is used for forwarding, network layer foo reachability is needed to qualify NH? - - John -- could make this a one-page doc that says "please be careful about selecting a next hop if j. random network layer reachability isn't there". - - Yakov -- yes, that could be a one-page draft (one line plus boilerplate). - - Yakov -- up to authors to do what they like bearing in mind comments. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Mar 26 12:28:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVs1E-0001wJ-9A; Mon, 26 Mar 2007 12:26:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVs1C-0001vf-Pm for idr@ietf.org; Mon, 26 Mar 2007 12:26:02 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVs1C-0002JY-9x for idr@ietf.org; Mon, 26 Mar 2007 12:26:02 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.6/8.13.4) with ESMTP id l2QGIDM6074927; Mon, 26 Mar 2007 11:18:13 -0500 (EST) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v0.5.2 workhorse.brookfield.occnc.com l2QGIDM6074927 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=occnc.com; s=workhorse; t=1174925893; bh=nKtEjDpfw0m5ExeN1keSfULb/uQ=; h=To:cc:Reply-To: From:Subject:In-reply-to:Date; b=fDAbwMbYSpgkJQhxrLmRlcnpDO+HL2RrzI jnQltcm3s+V3uGgPDYBNw+OgwtI2SSvyvkeyxGmxplkqBebkh0Qw== Message-Id: <200703261618.l2QGIDM6074927@workhorse.brookfield.occnc.com> To: Jeffrey Haas From: Curtis Villamizar Subject: Re: [Idr] BGP MIB v2 input In-reply-to: Your message of "Mon, 26 Mar 2007 09:32:50 EDT." <20070326133250.GB8422@scc.mi.org> Date: Mon, 26 Mar 2007 12:18:13 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: Bill Fenner , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org In message <20070326133250.GB8422@scc.mi.org> Jeffrey Haas writes: > > On Mon, Mar 26, 2007 at 06:50:37AM +0100, Bill Fenner wrote: > > It may be worth breaking this down into areas of limitation of the > > current MIB: > > > > 1. v6 peer support > > 2. v6 and other NLRI support > > 3. 4-byte AS support > > 4. extra counters desired > > (Others?) > > > > #1 can be taken care of with a rev of the peer table using > > the InetAddressType/InetAddress TCs. > > > > For #2, I have a somewhat radical proposal, which is to eliminate > > the reporting of the BGP table contents via SNMP. The radical > > replacement would be a "lookup request" which you do by writing > > an AFI, SAFI, NLRI to a lookup table, specifying whether you want > > longest match or all matches, and you read the results from a > > lookup results table. > > > > (a few reasons for this change: > > a) It's not very efficient to have an SNMP table with 200k+ rows; > > b) It's hard to represent, e.g., VPN routes; and > > c) You probably want to know "what routes do you know for > > this destination", which is not easy to answer even with the > > existing indexing, since "destination" is probably a /32 and > > the prefix in the table is probably not) > > #2 is an intriguing idea. Existing UI implementations already cover > having multiple "processes" access the routing table simultaneously. > However, I think this may have some interesting implementation > headaches. Could you please comment on them? > > - This would require set/write access to the MIB, correct? If so, > that's one of the things that people expressed serious reservations > about for any purpose previously. If not, are people on board with > dynamic queries using get operations where getnext wouldn't work? > - The results would likely be some sort of dynamically created OID tree > for each query. UIs such as a CLI tend to have reasonably well > understood lifetimes for their route table walking routines, but MIBs > have a much less well defined interface. Additionally, if you're > running the same query over and over, you may end up with multiple > views instatiated which may have excessive overhead. Further, you > don't have any sort of static OID you can use to monitor the state of > a particular route. > - The results of this query would seem to be the same MIB structure as > one would have for the entire routing table. MIB structure-wise, I > don't think we save any complexity. > > If these premises are true to one extent or another, that still leads to > an interesting possibility. We could still have the necessary query > objects. The result would then be a rowpointer to the root of the > existing routing table's subtree that matched the query. There would be > no need to dynamically generate views of the routing table, however > there would need to be a little intelligence in the querying routine to > stop walking after you've hit a less specific route. > > > #3 is straightforward, especially since between #1 and #2 > > we're probably changing most of the places you see an > > AS number anyway. > > The choice I made in the updates was to simply have the base routing > table be 4-byte aware. The annoying case is a 2-byte to 4-byte > transition speaker where three versions of the objects may be present: > The active derived set, the received 2-byte path attributes and the > received 4-byte path attributes. In the interest of simplicity in the > base MIB, I'm suggesting the additional transitional views be left to an > extention MIB. > > -- Jeff Jeff, Regarding #2 above. If we are going to play games that allow stateful SNMP access to solve the routing table dump problem I suggest we create a MIB pseudo write to take a snapshot of the routing table with a given identifier. The snapshot could then be transferred gradually but would 1) provide a consistent view (atomic operation) of the routing table, 2) incur little load on the router. The snapshot would have limited lifetime and could be refused if load was high (too many NMS stations asking for snapshots, etc). For routers that happen to have a fork operation with copy-on-write semantics this would be a very minimal impact and be similar to the "gated dump" of olden days. The forked process would then answer MIB queries. Separate memory pages would exist only as a result of routes that change during the lifetime of the snapshot. Routers built on more primative OS could implement the snapshot in some other way, but could incorporate a copy-on-write semantic within the routing table itself (with some complexity in doing so but that's their fault for not using a modern OS). As is (current MIB) from a practical standpoint the BGP routing table cannot be dumped via SNMP. Either you have to try to be aggressive and get it fast, or it changes while being dumped. I'm not sure if anyone has implemented a TCP GET-BULK on the entire routing table as a fork with copy-on-write, but that would have the same effect. The process making the TCP transfer could be given a low priority making the operation atomic yet low impact. If that is an acceptable alternative, then no change is needed. I'm not sure if this addresses one implied requirement (or imagined on my part?) of #2 above, which is to dump a specific prefix only. I thought that would already be possible with GET-NEXT and the existing ordering used in the MIB. Disclaimer - I'm far from an SNMP expert. Curtis ps - No I don't work for Juniper. :-) _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Mar 26 13:22:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVspO-0004zs-0q; Mon, 26 Mar 2007 13:17:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVspM-0004zn-O5 for idr@ietf.org; Mon, 26 Mar 2007 13:17:52 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVspJ-0001Hm-D4 for idr@ietf.org; Mon, 26 Mar 2007 13:17:52 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id E0A904E541; Mon, 26 Mar 2007 13:17:46 -0400 (EDT) Date: Mon, 26 Mar 2007 13:17:46 -0400 From: Jeffrey Haas To: Curtis Villamizar Subject: Re: [Idr] BGP MIB v2 input Message-ID: <20070326171746.GA5090@scc.mi.org> References: <20070326133250.GB8422@scc.mi.org> <200703261618.l2QGIDM6074927@workhorse.brookfield.occnc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200703261618.l2QGIDM6074927@workhorse.brookfield.occnc.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Bill Fenner , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Curtis, On Mon, Mar 26, 2007 at 12:18:13PM -0400, Curtis Villamizar wrote: > If we are going to play games that allow stateful SNMP access to solve > the routing table dump problem I suggest we create a MIB pseudo write > to take a snapshot of the routing table with a given identifier. I may have mis-interpreted Bill, but I think he simply wanted a better way to get at a specific set of routes rather than an atomic routing table dump. When I was pondering the "sub-view" problem, I had many of the same thoughts you put in your reply. My next thought was, "Ew, gross!" I think the snapshot mechanism may be nice for some implementations, but I'd hesitate to recommend it go into the IETF standard mib for BGP. > As is (current MIB) from a practical standpoint the BGP routing table > cannot be dumped via SNMP. [All very much IMO:] I'd agree. I also don't know if it's the right problem to be solved. SNMP is very good at getting you to specific instances of some data. It is okay for getting you the "next" data instance, but its idea of "next" is a bit weak for routing table dumps. As a data abstraction format, it has some ugly limits. You're recommended to not use OCTET STRINGs longer than 255 bytes, but BGP has several object that in binary format would be longer than that. This has meant that canonicalizing objects such as AS_PATHs require a pointer to another table which breaks out the elements into effectively an array of an array. As an abstract data transport, it's weak in that it wants a pull rather than a push. This means that you end up making several potentially expensive API calls to your routing table to pull data with the possibility of caches going stale due to the time involved. This may be less so with GETBULK, but that depends on the user. > I'm not sure if this addresses one implied requirement (or imagined on > my part?) of #2 above, which is to dump a specific prefix only. I > thought that would already be possible with GET-NEXT and the existing > ordering used in the MIB. Fetching a specific prefix is easy. Bill's suggestion was "fetch the most specific prefix" or "fetch more specific prefixes". The current RFC 4273 MIB would return data: bgp4PathAttrEntry OBJECT-TYPE SYNTAX Bgp4PathAttrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a path to a network." INDEX { bgp4PathAttrIpAddrPrefix, bgp4PathAttrIpAddrPrefixLen, bgp4PathAttrPeer } ::= { bgp4PathAttrTable 1 } Prefix (an ip addres), followed by the prefix length, followed by the peers who have that prefix. (The update actually has the indexes the other way - all routes for a peer. That's broken and I'll fix it.) This means that 10.0.0.0/8 and more specific will give you something like: 10.0.0.0/8 10.0.0.0/9 10.1.0.0/24 You and I would expect 10.1/24 to fall after 10/8 as a more specific, but SNMP wouldn't. This lexicographic threading of a radix trie already gives developers heartburn and introduces all sorts of fun inefficiencies. Perhaps the better question to ask is, "Is having access to the routing table via SNMP even worth it?" After several years of thinking about this (and a little bit of time before that as an operator), I think the answer is "maybe", but certainly not for dumping. I've provided a representation that lets you do it. I can't even argue it's the best one, but I seemed to have played "stump the mib doctor" a few times over the past few years. :-) -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Mar 26 14:33:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVtwB-0007Yu-N7; Mon, 26 Mar 2007 14:28:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVtwB-0007Yk-A8 for idr@ietf.org; Mon, 26 Mar 2007 14:28:59 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVtw9-0005NM-Sh for idr@ietf.org; Mon, 26 Mar 2007 14:28:59 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.6/8.13.4) with ESMTP id l2QILAae076038; Mon, 26 Mar 2007 13:21:10 -0500 (EST) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v0.5.2 workhorse.brookfield.occnc.com l2QILAae076038 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=occnc.com; s=workhorse; t=1174933270; bh=fPsrSNIyXMmbURGUMy1JCrYip60=; h=To:cc:Reply-To: From:Subject:In-reply-to:Date; b=cnNWBzn7p8DdDAmvdXaABq01hM/zu3OzV/ g3q3r5k0kKY3YqP3oX0QVFPk37HXoBaMxPfvqbqX/69cU0NTj9JQ== Message-Id: <200703261821.l2QILAae076038@workhorse.brookfield.occnc.com> To: Jeffrey Haas From: Curtis Villamizar Subject: Re: [Idr] BGP MIB v2 input In-reply-to: Your message of "Mon, 26 Mar 2007 13:17:46 EDT." <20070326171746.GA5090@scc.mi.org> Date: Mon, 26 Mar 2007 14:21:10 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Bill Fenner , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org In message <20070326171746.GA5090@scc.mi.org> Jeffrey Haas writes: > > Fetching a specific prefix is easy. Bill's suggestion was "fetch the > most specific prefix" or "fetch more specific prefixes". The current > RFC 4273 MIB would return data: > > bgp4PathAttrEntry OBJECT-TYPE > SYNTAX Bgp4PathAttrEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Information about a path to a network." > INDEX { bgp4PathAttrIpAddrPrefix, > bgp4PathAttrIpAddrPrefixLen, > bgp4PathAttrPeer } > ::= { bgp4PathAttrTable 1 } > > Prefix (an ip addres), followed by the prefix length, followed by the > peers who have that prefix. (The update actually has the indexes the > other way - all routes for a peer. That's broken and I'll fix it.) > > This means that 10.0.0.0/8 and more specific will give you something > like: > 10.0.0.0/8 > 10.0.0.0/9 > 10.1.0.0/24 > > You and I would expect 10.1/24 to fall after 10/8 as a more specific, > but SNMP wouldn't. This lexicographic threading of a radix trie already > gives developers heartburn and introduces all sorts of fun > inefficiencies. That's not terrible for the NMS. GET-NEXT on 9.255.255.255/32 and get 10/x or GET-NEXT on 10/7 and walk 10/8, 10/9, etc until you are out of the 10/8 range (in a prefix/mask sense). The ordering in effect requires two trees in the router, one for the normal radix trie acxess and one for the MIB. At least that is what one implementation does. Fixing the ordering would eliminate that. > Perhaps the better question to ask is, "Is having access to the routing > table via SNMP even worth it?" After several years of thinking about > this (and a little bit of time before that as an operator), I think the > answer is "maybe", but certainly not for dumping. I've provided a > representation that lets you do it. I can't even argue it's the best > one, but I seemed to have played "stump the mib doctor" a few times over > the past few years. :-) > > -- Jeff IMO Its useful for enterprise but currently not practical for ISPs. As a result ISPs don't dump the routing table or use SNMP to query the routing table for debugging, but instead use other means. If it could be made useful for ISPs it would make the job of writing NOC software tools and ISP NMS tools all the easier. The only use I found for periodically dumping the routing table was to check for inconsistency across a network due to some vendors MED handling and non-deterministic route install issues. You could say BGP was a bit more buggy then. ISPs today might only find it interesting to periodically see how non-deterministic routing choices fall if they are doing traffic matrix estimation in a BGP/IGP only (no MPLS TE) network which some (most?) do for planning purposes. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Mar 26 14:41:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVu7g-0005BY-FV; Mon, 26 Mar 2007 14:40:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVu7f-0005BR-NN for idr@ietf.org; Mon, 26 Mar 2007 14:40:51 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVu7d-00081J-Ff for idr@ietf.org; Mon, 26 Mar 2007 14:40:51 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 090A24E4DD; Mon, 26 Mar 2007 14:40:45 -0400 (EDT) Date: Mon, 26 Mar 2007 14:40:45 -0400 From: Jeffrey Haas To: Curtis Villamizar Subject: Re: [Idr] BGP MIB v2 input Message-ID: <20070326184044.GA11264@scc.mi.org> References: <20070326171746.GA5090@scc.mi.org> <200703261821.l2QILAae076038@workhorse.brookfield.occnc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200703261821.l2QILAae076038@workhorse.brookfield.occnc.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Bill Fenner , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Mon, Mar 26, 2007 at 02:21:10PM -0400, Curtis Villamizar wrote: > That's not terrible for the NMS. GET-NEXT on 9.255.255.255/32 and get > 10/x or GET-NEXT on 10/7 and walk 10/8, 10/9, etc until you are out of > the 10/8 range (in a prefix/mask sense). Right, but that means the NMS isn't a very good tool to manage your router when looking at routing tables. People want prefix order, not MIB order. > The ordering in effect requires two trees in the router, one for the > normal radix trie acxess and one for the MIB. At least that is what > one implementation does. Fixing the ordering would eliminate that. Every router that implements the MIB would have to do something like this. Sane ones (presumably IMO) all just keep the routes on two trees. Less sane ones that are less sensitive to scaling may have copies of routing information. > IMO Its useful for enterprise but currently not practical for ISPs. > As a result ISPs don't dump the routing table or use SNMP to query the > routing table for debugging, but instead use other means. > > If it could be made useful for ISPs it would make the job of writing > NOC software tools and ISP NMS tools all the easier. This is wrong tool To re-ask the question - drop the routing database from the MIB? -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Mar 26 15:54:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVvCy-00075j-Lx; Mon, 26 Mar 2007 15:50:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVvCx-00075e-QW for idr@ietf.org; Mon, 26 Mar 2007 15:50:23 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVvCx-0005fY-Ai for idr@ietf.org; Mon, 26 Mar 2007 15:50:23 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l2QJoIlx006000; Mon, 26 Mar 2007 22:50:18 +0300 Date: Mon, 26 Mar 2007 22:50:18 +0300 (EEST) From: Pekka Savola To: Jeffrey Haas Subject: Re: [Idr] BGP MIB v2 input In-Reply-To: <20070326184044.GA11264@scc.mi.org> Message-ID: References: <20070326171746.GA5090@scc.mi.org> <200703261821.l2QILAae076038@workhorse.brookfield.occnc.com> <20070326184044.GA11264@scc.mi.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.1/2924/Sun Mar 25 15:56:14 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Bill Fenner , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Mon, 26 Mar 2007, Jeffrey Haas wrote: >> If it could be made useful for ISPs it would make the job of writing >> NOC software tools and ISP NMS tools all the easier. > > This is wrong tool > > To re-ask the question - drop the routing database from the MIB? Just wondering: the current BGP4 MIB already supports the routing databse (BGP4-MIB::bgp4PathAttrBest at least). Are you proposing dropping the equivalent functionality from the new MIB or just some more exciting new variants? Similar information for the whole FIB exists under IP-FORWARD-MIB. Both are widely implemented AFAIK, which seems like a proof that an implementation is feasible. FWIW, I agree that using SNMP to dump 200K+ prefixes from routing tables across all routers is likely not very useful in most cases, especially if you want to compare the tables, as the tables are going change over time. (Though in restricted contexts like without DFZ this may or may not be useful.) An example: I currently use both IP-FORWARD-MIB and BGP4-MIB::bgp4PathAttrBest in SNMP scripts by parsing the config files (interface-related routing protocol config to be exact) and checking them against operational policy (e.g., certain kinds of interface addresses must be in OSPF; others must not be in OSPF; some others must be in BGP; static routes must be in BGP; etc.). -- 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-bounces@ietf.org Mon Mar 26 16:18:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVvc8-00014F-OF; Mon, 26 Mar 2007 16:16:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVvc7-00014A-OF for idr@ietf.org; Mon, 26 Mar 2007 16:16:23 -0400 Received: from mail-red.research.att.com ([192.20.225.110]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HVvc4-0004pC-El for idr@ietf.org; Mon, 26 Mar 2007 16:16:23 -0400 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-green.research.att.com (Postfix) with ESMTP id 1F3AA8580; Mon, 26 Mar 2007 16:16:14 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.13.1/8.12.10/Submit) id l2QKGEVi013401; Mon, 26 Mar 2007 22:16:14 +0200 From: Bill Fenner Message-Id: <200703262016.l2QKGEVi013401@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Pekka Savola Subject: Re: [Idr] BGP MIB v2 input References: <20070326171746.GA5090@scc.mi.org> <200703261821.l2QILAae076038@workhorse.brookfield.occnc.com> <20070326184044.GA11264@scc.mi.org> Date: Mon, 26 Mar 2007 22:16:13 +0100 Versions: dmail (linux) 2.7/makemail 2.14 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org >Just wondering: the current BGP4 MIB already supports the routing >databse (BGP4-MIB::bgp4PathAttrBest at least). Are you proposing >dropping the equivalent functionality from the new MIB or just some >more exciting new variants? That was my proposal, since getting a pathattr table that nicely handles IP and non-IP NLRI is ... confusing. It also can result in less than ideal behavior when walking the whole MIB on a device that has hundreds of thousands of prefixes. >An example: I currently use both IP-FORWARD-MIB and >BGP4-MIB::bgp4PathAttrBest in SNMP scripts by parsing the config files >(interface-related routing protocol config to be exact) and checking >them against operational policy (e.g., certain kinds of interface >addresses must be in OSPF; others must not be in OSPF; some others >must be in BGP; static routes must be in BGP; etc.). Interesting. I was looking it from the point of view of not knowing exactly what prefix you were looking for (e.g., "show ip bgp 12.106.35.1" without knowing that it's in a /22). The obvious thing to do is to grab the whole table (probably inadvisable); there are more subtle ways but none are very efficient. Bill _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Mar 26 16:34:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVvsQ-0001vg-0c; Mon, 26 Mar 2007 16:33:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVvsO-0001vC-RI for idr@ietf.org; Mon, 26 Mar 2007 16:33:12 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVvrz-0002aD-Ij for idr@ietf.org; Mon, 26 Mar 2007 16:33:12 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id C1DA54E542; Mon, 26 Mar 2007 16:32:42 -0400 (EDT) Date: Mon, 26 Mar 2007 16:32:42 -0400 From: Jeffrey Haas To: Pekka Savola Subject: Re: [Idr] BGP MIB v2 input Message-ID: <20070326203242.GC11264@scc.mi.org> References: <20070326171746.GA5090@scc.mi.org> <200703261821.l2QILAae076038@workhorse.brookfield.occnc.com> <20070326184044.GA11264@scc.mi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Bill Fenner , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Mon, Mar 26, 2007 at 10:50:18PM +0300, Pekka Savola wrote: > Just wondering: the current BGP4 MIB already supports the routing > databse (BGP4-MIB::bgp4PathAttrBest at least). Are you proposing > dropping the equivalent functionality from the new MIB or just some > more exciting new variants? A deficiency that I had originally been asked to address in the second version of the MIB was access to structured data. I'll give two examples: - The AS_PATH in the RFC 4273 MIB is contained in: bgp4PathAttrASPathSegment OBJECT-TYPE SYNTAX OCTET STRING (SIZE (2..255)) MAX-ACCESS read-only STATUS current Pretty much memcpy() the AS_PATH into the MIB and truncate. This had two issues: 1) It's truncated in some circumstances 2) It required the management appliance to have a function that could parse AS_PATHs (and potentially truncated ones at that). That's not useful. For the AS_PATH, we probably want two pieces of data: 1) Something humanly readable 2) Something that's a canonicalized version of the data structure that doesn't lose information. These can be solved using roughly this structure: NlriTable contains pathattrindex PathAttrTable[pathattrindex] contains path attributes: - MED, etc. - Human readable AS_PATH - aspathindex AsPathTable[aspathindex][subindex] is a table that canonicalizes the entirety of the AS_PATH. Problems with this representation: - The human readable bit will likely be vendor specific. That's okay as long as we have something canonical. However, it's going to be limited to 255 characters courtesy of SnmpAdminString - The AsPathTable is convoluted enough that you probably still don't want to look at it.It could be interpreted by a human without decoding TLVs in your head, but it's still not pretty. *However*, it is cachacble. The second example is communities. It has all of the same problems. Additionally, communities aren't required to be supported in order to do BGP. This means putting them in the base BGP mib is probably a bad idea. You still want the data, so you put them in an extensions mib. Note: IDR feedback has had me try things both ways over the last several years with regards to extentions/not extentions. > Similar information for the whole FIB exists under IP-FORWARD-MIB. With all respect to that MIB author: The data was easier to represent. > An example: I currently use both IP-FORWARD-MIB and > BGP4-MIB::bgp4PathAttrBest in SNMP scripts by parsing the config files > (interface-related routing protocol config to be exact) and checking > them against operational policy (e.g., certain kinds of interface > addresses must be in OSPF; others must not be in OSPF; some others > must be in BGP; static routes must be in BGP; etc.). I think this answers some of Curtis' questions. :-) -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Mar 26 19:01:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVy6t-0002ie-9a; Mon, 26 Mar 2007 18:56:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVy6s-0002iZ-4C for idr@ietf.org; Mon, 26 Mar 2007 18:56:18 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVy6q-0005mw-OD for idr@ietf.org; Mon, 26 Mar 2007 18:56:18 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.6/8.13.4) with ESMTP id l2QMmHVK077479; Mon, 26 Mar 2007 17:48:17 -0500 (EST) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v0.5.2 workhorse.brookfield.occnc.com l2QMmHVK077479 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=occnc.com; s=workhorse; t=1174949298; bh=F3JNUyntTPG8BJZK7DyPp7JuxV0=; h=To:cc:Reply-To: From:Subject:In-reply-to:Date; b=AypvZv08q3taZ2ah+mkw4tgItGy8Wy+uZ3 dQXA5mDsVqw31RlHx/HS8MzMLKdehjV096OC4OCKBkahZwU2SOgQ== Message-Id: <200703262248.l2QMmHVK077479@workhorse.brookfield.occnc.com> To: Jeffrey Haas From: Curtis Villamizar Subject: Re: [Idr] BGP MIB v2 input In-reply-to: Your message of "Mon, 26 Mar 2007 14:40:45 EDT." <20070326184044.GA11264@scc.mi.org> Date: Mon, 26 Mar 2007 18:48:17 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Bill Fenner , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org In message <20070326184044.GA11264@scc.mi.org> Jeffrey Haas writes: > > On Mon, Mar 26, 2007 at 02:21:10PM -0400, Curtis Villamizar wrote: > > That's not terrible for the NMS. GET-NEXT on 9.255.255.255/32 and get > > 10/x or GET-NEXT on 10/7 and walk 10/8, 10/9, etc until you are out of > > the 10/8 range (in a prefix/mask sense). > > Right, but that means the NMS isn't a very good tool to manage your > router when looking at routing tables. People want prefix order, not > MIB order. A MIB dump is never a good tool. A tool that uses the MIB could reorder such a query. I've already agreed with you that radix trie order would be better. > > The ordering in effect requires two trees in the router, one for the > > normal radix trie acxess and one for the MIB. At least that is what > > one implementation does. Fixing the ordering would eliminate that. > > Every router that implements the MIB would have to do something like > this. Sane ones (presumably IMO) all just keep the routes on two trees. > Less sane ones that are less sensitive to scaling may have copies of > routing information. Extra copies? Might be worth taking this off list. Could have humor value. btw- Really bad first implementations might try to scan the routing table for each GET or GET-NEXT. There is existance proof of this. > > IMO Its useful for enterprise but currently not practical for ISPs. > > As a result ISPs don't dump the routing table or use SNMP to query the > > routing table for debugging, but instead use other means. > > > > If it could be made useful for ISPs it would make the job of writing > > NOC software tools and ISP NMS tools all the easier. > > This is wrong tool > > To re-ask the question - drop the routing database from the MIB? > > -- Jeff All IMHO ... If its useful for enterprise it shouldn't be dropped in the MIB just because it is not useful for ISPs. I think it can become ever so slightly more useful for ISPs if the sorting order is changed. It can also become less of a burden on routers if the sorting order is changed. Then any good reason to drop it is eliminated. At most a router can have a knob to disable it (and save the trouble of creating the extra tree if using the old sorting order). If some router running an OS with VM copy-on-write semantics implements a TCP GET-BULK dump of full BGP routing table as a special case using a fork to make the operation efficient, more power to them. Some ISPs might think thats great. Others might not case as long as it can't become a means of denial of service attack. I think I've said enough so shutting up now. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Mar 26 19:09:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVyIl-0001mb-8q; Mon, 26 Mar 2007 19:08:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVyIj-0001mR-Us for idr@ietf.org; Mon, 26 Mar 2007 19:08:33 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVyIi-0007Ui-J5 for idr@ietf.org; Mon, 26 Mar 2007 19:08:33 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.6/8.13.4) with ESMTP id l2QN0hN6077543; Mon, 26 Mar 2007 18:00:44 -0500 (EST) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v0.5.2 workhorse.brookfield.occnc.com l2QN0hN6077543 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=occnc.com; s=workhorse; t=1174950044; bh=7u6kpt9dlukdYI4QE9Cp17IYNHU=; h=To:cc:Reply-To: From:Subject:In-reply-to:Date; b=q2iKpUnNnvjnIvIWd3hvmv80Og4LYNkWBi V9Mdr8QI2PaXiQOlW5CFXH7ci5qE7sQ/wZNq9QyqK6WT+1rZD6hg== Message-Id: <200703262300.l2QN0hN6077543@workhorse.brookfield.occnc.com> To: Bill Fenner From: Curtis Villamizar Subject: Re: [Idr] BGP MIB v2 input In-reply-to: Your message of "Mon, 26 Mar 2007 22:16:13 BST." <200703262016.l2QKGEVi013401@bright.research.att.com> Date: Mon, 26 Mar 2007 19:00:43 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: idr@ietf.org, Pekka Savola X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org In message <200703262016.l2QKGEVi013401@bright.research.att.com> Bill Fenner writes: > > > >Just wondering: the current BGP4 MIB already supports the routing > >databse (BGP4-MIB::bgp4PathAttrBest at least). Are you proposing > >dropping the equivalent functionality from the new MIB or just some > >more exciting new variants? > > That was my proposal, since getting a pathattr table that > nicely handles IP and non-IP NLRI is ... confusing. It also > can result in less than ideal behavior when walking the whole > MIB on a device that has hundreds of thousands of prefixes. I completely missed the non-IP issue here with the need for a MIB entry and sorting order covering both IP and non-IP. > >An example: I currently use both IP-FORWARD-MIB and > >BGP4-MIB::bgp4PathAttrBest in SNMP scripts by parsing the config files > >(interface-related routing protocol config to be exact) and checking > >them against operational policy (e.g., certain kinds of interface > >addresses must be in OSPF; others must not be in OSPF; some others > >must be in BGP; static routes must be in BGP; etc.). > > Interesting. I was looking it from the point of view of not knowing > exactly what prefix you were looking for (e.g., "show ip bgp 12.106.35.1" > without knowing that it's in a /22). The obvious thing to do is to grab > the whole table (probably inadvisable); there are more subtle ways but > none are very efficient. More likely do GET on a 12.106.35.1/32, and decrement prefix length to /31, etc, until something comes up. Not terribly efficient either. The route covering this could be 0/0. To handle IP and non-IP cleanly you almost need an object oriented MIB entry, where one order is used for IP and other types can define other orders. No such thing in SNMP AFAIK. > Bill Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Mar 27 02:00:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW4bR-0005RR-Sk; Tue, 27 Mar 2007 01:52:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW4bQ-0005RJ-Tn for idr@ietf.org; Tue, 27 Mar 2007 01:52:16 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HW4bQ-0007nU-Cx for idr@ietf.org; Tue, 27 Mar 2007 01:52:16 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l2R5q2xu017612; Tue, 27 Mar 2007 08:52:02 +0300 Date: Tue, 27 Mar 2007 08:52:02 +0300 (EEST) From: Pekka Savola To: Bill Fenner Subject: Re: [Idr] BGP MIB v2 input In-Reply-To: <200703262016.l2QKGEVi013401@bright.research.att.com> Message-ID: References: <20070326171746.GA5090@scc.mi.org> <200703261821.l2QILAae076038@workhorse.brookfield.occnc.com> <20070326184044.GA11264@scc.mi.org> <200703262016.l2QKGEVi013401@bright.research.att.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.1/2931/Mon Mar 26 11:43:40 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org off-list, On Mon, 26 Mar 2007, Bill Fenner wrote: >> Just wondering: the current BGP4 MIB already supports the routing >> databse (BGP4-MIB::bgp4PathAttrBest at least). Are you proposing >> dropping the equivalent functionality from the new MIB or just some >> more exciting new variants? > > That was my proposal, since getting a pathattr table that > nicely handles IP and non-IP NLRI is ... confusing. It also > can result in less than ideal behavior when walking the whole > MIB on a device that has hundreds of thousands of prefixes. If non-IP NLRI's are considerably difficult, maybe those should not be presented in the MIB (at least in the basic version)? >> An example: I currently use both IP-FORWARD-MIB and >> BGP4-MIB::bgp4PathAttrBest in SNMP scripts by parsing the config files >> (interface-related routing protocol config to be exact) and checking >> them against operational policy (e.g., certain kinds of interface >> addresses must be in OSPF; others must not be in OSPF; some others >> must be in BGP; static routes must be in BGP; etc.). > > Interesting. I was looking it from the point of view of not knowing > exactly what prefix you were looking for (e.g., "show ip bgp 12.106.35.1" > without knowing that it's in a /22). The obvious thing to do is to grab > the whole table (probably inadvisable); there are more subtle ways but > none are very efficient. I'm not sure how the SNMP agent implementation actually does it (i.e. whether it needs to do memory copy of the whole table), but this what I do is without a subnet mask (because I have been too lazy to convert it between different prefix length representations :-): $ snmpwalk -v 2c -c $comm -m BGP4-MIB $rtr bgp4PathAttrBest.193.167.190.0 BGP4-MIB::bgp4PathAttrBest.193.167.190.0.25.172.31.5.199 = INTEGER: true(2) BGP4-MIB::bgp4PathAttrBest.193.167.190.0.30.172.31.5.199 = INTEGER: true(2) .. and if I wanted to get more than just one prefix, I could walk a whole /16 with, e.g.: $ snmpwalk -v 2c -c $comm -m BGP4-MIB $rtr bgp4PathAttrBest.193.166 ... -- 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-bounces@ietf.org Tue Mar 27 12:06:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWE94-0002IP-32; Tue, 27 Mar 2007 12:03:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWE92-0002IB-Vb for idr@ietf.org; Tue, 27 Mar 2007 12:03:36 -0400 Received: from softy.ision.net ([194.163.250.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWE91-0004nl-L4 for idr@ietf.org; Tue, 27 Mar 2007 12:03:36 -0400 Received: from paul.de.easynet.net ([195.180.208.152] helo=paul.adoffice.de.easynet.net) by softy.ision.net with esmtp (Exim 4.50) id 1HWE8w-00036C-Ge; Tue, 27 Mar 2007 18:03:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Question about aggregation Date: Tue, 27 Mar 2007 18:03:29 +0200 Message-ID: <7000E71D8C525042A815432358B2F124B1C45D@paul.adoffice.local.de.easynet.net> In-Reply-To: <4187324E-AF45-47ED-BF4C-2C5C51632837@cs.ucla.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Question about aggregation thread-index: AcdoEuH/MJFBbqx/QemBTFMokjTLfQIbqh0A References: <4187324E-AF45-47ED-BF4C-2C5C51632837@cs.ucla.edu> From: "Ilya Varlashkin" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi,=20 > -----Original Message----- > From: Ricardo V. Oliveira [mailto:rveloso@cs.ucla.edu]=20 > Sent: Friday, March 16, 2007 10:31 PM > To: idr@ietf.org > Subject: [Idr] Question about aggregation >=20 > Hi, >=20 > I have a question related to route aggregation, that I could=20 > not find specified in RFC4271. > Suppose a router aggregates two entries: 10.0.1/24 and=20 > 10.0.2/24 with same ASPATH [A B C] into a single entry: > 10.0/16 [A B C] > Then 10.0.1/24 decides to change provider and switches to a=20 > new aspath [A D C], and we'll have in the table: > 10.0/16 [A B C] > 10.0.1/24 [A D C] >=20 > which is fine since forwarding will follow longest match. > Now suppose 10.0.2/24 decides to change providers to path [A=20 > E C], then we end up w/: > 10.0/16 [A B C] > 10.0.1/24 [A D C] > 10.0.2/24 [A E C] >=20 > And the initial entry is now a bogus entry. How do routers=20 > usually get rid of these stale entries? In this case 10.0/16 should disappear as soon as there is no longer any specific route matching AS-PATH attribute (per section 9.2.2.2, paragraph about AS-PATH). > The same question applies if all more specific routes are=20 > withdrawn, is the aggregate also withdrawn? It should be (also per 9.2.2.2). > Do routers keep state of more specific routes in Adj-RIB-In=20 > and update Local-RIB accordingly? >=20 Adj-RIB-In and Local-RIB are not necessarily stored separately, at least RFC does not require this. Implementation could in store specific routes along with aggregate in the Local-RIB (which is result of applying policy to Adj-RIB-In), but propagate to Adj-RIB-Out only aggregated route (as result of applying outgoing policy). > Also, in section 9.1.4 of the RFC (overlapping routes) it's said: [...] > Loc-RIB, the aggregated route, provided that both routes have the > same value of the NEXT_HOP attribute." >=20 > But in section 9.2.2.2 (aggregating routing information) it's said: [...] > NEXT_HOP: > When aggregating routes that have different NEXT_HOP > attributes, the NEXT_HOP attribute of the aggregated route > SHALL identify an interface on the BGP speaker that performs > the aggregation. > " > So it seems the first sentence was not updated according to=20 > the aggregation rules of the new RFC. >=20 There doesn't seem to be contradiction - one sentence is dealing with routes that have same value of NEXT-HOP, the other one is dealing with aggregation of different NEXT-HOP attributes. Both are practical cases. Second case just exaplins what to do when routes do not fit description in 9.1.4. Cheers, iLya _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Mar 27 14:09:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWG2K-0000iN-3b; Tue, 27 Mar 2007 14:04:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWG2J-0000iI-7B for idr@ietf.org; Tue, 27 Mar 2007 14:04:47 -0400 Received: from smtp-6.smtp.ucla.edu ([169.232.48.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWG2H-0001zZ-LV for idr@ietf.org; Tue, 27 Mar 2007 14:04:47 -0400 Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.146]) by smtp-6.smtp.ucla.edu (8.13.8/8.13.8) with ESMTP id l2RI4iAK000612 for ; Tue, 27 Mar 2007 11:04:44 -0700 Received: from [131.179.96.243] (Cs-96-243.CS.UCLA.EDU [131.179.96.243]) (authenticated bits=0) by mail.ucla.edu (8.13.8/8.13.8) with ESMTP id l2RI4iwK001196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 27 Mar 2007 11:04:44 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <7000E71D8C525042A815432358B2F124B1C45D@paul.adoffice.local.de.easynet.net> References: <4187324E-AF45-47ED-BF4C-2C5C51632837@cs.ucla.edu> <7000E71D8C525042A815432358B2F124B1C45D@paul.adoffice.local.de.easynet.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6B765C35-61F5-4BBB-B101-771D58FC37BB@CS.UCLA.EDU> Content-Transfer-Encoding: 7bit From: "Ricardo V. Oliveira" Subject: Re: [Idr] Question about aggregation Date: Tue, 27 Mar 2007 11:06:15 -0700 To: idr@ietf.org X-Mailer: Apple Mail (2.752.2) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.48.137 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org >> Also, in section 9.1.4 of the RFC (overlapping routes) it's said: > [...] >> Loc-RIB, the aggregated route, provided that both routes have the >> same value of the NEXT_HOP attribute." >> >> But in section 9.2.2.2 (aggregating routing information) it's said: > [...] >> NEXT_HOP: >> When aggregating routes that have different NEXT_HOP >> attributes, the NEXT_HOP attribute of the aggregated route >> SHALL identify an interface on the BGP speaker that >> performs >> the aggregation. >> " >> So it seems the first sentence was not updated according to >> the aggregation rules of the new RFC. >> > > There doesn't seem to be contradiction - one sentence is dealing with > routes that have same value of NEXT-HOP, the other one is dealing with > aggregation of different NEXT-HOP attributes. Both are practical > cases. > Second case just exaplins what to do when routes do not fit > description > in 9.1.4. Thanks fo the reply Ilya. Section 9.2.2.2. is suppose to describe the necessary conditions for aggregation of different routes. None of these conditions require that NEXT_HOP be the same for different routes (which was required by previous RFC). However, this condition is described in section 9.1.4 as a necessary condition for aggregation, which to me seems a contradiction. If the scenario in 9.1.4 is a special case, then it should be mentioned as such in the text to avoid confusion with the later section. --Ricardo _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Mar 28 15:54:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWe9s-0008Vm-Qh; Wed, 28 Mar 2007 15:50:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWe9i-0008TY-Uw; Wed, 28 Mar 2007 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWe9i-0001wy-JP; Wed, 28 Mar 2007 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 8ABA432946; Wed, 28 Mar 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HWe9i-0004aA-Ek; Wed, 28 Mar 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Mar 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-v4nlri-v6nh-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org --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 : Advertising an IPv4 NLRI with an IPv6 Next Hop Author(s) : F. Le Faucheur, E. Rosen Filename : draft-ietf-idr-v4nlri-v6nh-00.txt Pages : 12 Date : 2007-3-28 MultiProtocol-BGP (MP-BGP) specifies that the set of Network Layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising an IPv4 Network Layer Reachability Information (NLRI) or a VPN-IPv4 NLRI. This document specifies the extensions necessary to allow advertising an IPv4 NLRI or a VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for an IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-v4nlri-v6nh-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-v4nlri-v6nh-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-v4nlri-v6nh-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: <2007-3-28121633.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-v4nlri-v6nh-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-v4nlri-v6nh-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-28121633.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart--