From idr-bounces@ietf.org Tue Jun 1 04:12:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04370 for ; Tue, 1 Jun 2004 04:12:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BV4No-0001Eq-FW for idr-archive@ietf.org; Tue, 01 Jun 2004 04:12:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BV4LQ-0000Y7-00 for idr-archive@ietf.org; Tue, 01 Jun 2004 04:10:01 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BV4Jx-0007M6-00; Tue, 01 Jun 2004 04:08:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV4A4-0005dA-Hw; Tue, 01 Jun 2004 03:58:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV442-0004my-AM for idr@megatron.ietf.org; Tue, 01 Jun 2004 03:52:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03084 for ; Tue, 1 Jun 2004 03:52:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BV440-0007l7-2K for idr@ietf.org; Tue, 01 Jun 2004 03:52:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BV42y-0007HZ-00 for idr@ietf.org; Tue, 01 Jun 2004 03:50:57 -0400 Received: from bay17-f17.bay17.hotmail.com ([64.4.43.67] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BV42F-0006o9-00 for idr@ietf.org; Tue, 01 Jun 2004 03:50:11 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 1 Jun 2004 00:49:42 -0700 Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Tue, 01 Jun 2004 07:49:42 GMT X-Originating-IP: [61.16.170.194] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: idr@ietf.org Date: Tue, 01 Jun 2004 07:49:42 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Jun 2004 07:49:42.0391 (UTC) FILETIME=[FFBF9870:01C447AC] Subject: [Idr] A question on longest match 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Hello, Is there any specific reason why the BGP algorithm relies on the longest match paradigm? Is there any reason why one cannot simply propogate the "range of addresses" and use different metrics? For example one could say "address numbers 100000 - 212123 are here and 212124 - 312127 are there? Would this not lead to considerable reduction of the size of the forwarding table? -- (&) Little John. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 1 04:40:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06250 for ; Tue, 1 Jun 2004 04:40:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BV4oy-0005fs-Vc for idr-archive@ietf.org; Tue, 01 Jun 2004 04:40:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BV4no-00058C-00 for idr-archive@ietf.org; Tue, 01 Jun 2004 04:39:20 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BV4mr-0004bF-00; Tue, 01 Jun 2004 04:38:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV4bz-0002AE-Ak; Tue, 01 Jun 2004 04:27:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV4Wu-00018E-1m for idr@megatron.ietf.org; Tue, 01 Jun 2004 04:21:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04968 for ; Tue, 1 Jun 2004 04:21:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BV4Wr-00050B-EY for idr@ietf.org; Tue, 01 Jun 2004 04:21:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BV4Vk-0004YW-00 for idr@ietf.org; Tue, 01 Jun 2004 04:20:41 -0400 Received: from bay17-f7.bay17.hotmail.com ([64.4.43.57] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BV4Ul-0003ff-00 for idr@ietf.org; Tue, 01 Jun 2004 04:19:39 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 1 Jun 2004 01:19:10 -0700 Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Tue, 01 Jun 2004 08:19:09 GMT X-Originating-IP: [61.16.170.194] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: jsmith4112003@yahoo.co.uk Subject: RE: [Idr] A question on longest match Date: Tue, 01 Jun 2004 08:19:09 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Jun 2004 08:19:10.0093 (UTC) FILETIME=[1D6183D0:01C447B1] 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Hello Big Brother, It is specifically releated to BGP. Aggregation in non DV protocols is not a possibility unless one goes across Area/Level boundarys. This is due to their inherent nature of sending advertisements of "all connected networks" to "all nodes in the same level or area". Now you do believe aggregation is good, do you not? I am sure you do! Now to further that assumption, if aggregation is good, and one was to make a forwarding device which would not do Layer 3 lookup based on the bit aligned boundaries, but on ranges, would it be considered bad or good? Also please let me know if this is not an item to dicuss on idr, or should the be specifically targetted to the routing-discussion mailing list? In that case I shall not cc the list further on these queries. -- (&) Little John. >From: "John Smith" >To: >Subject: RE: [Idr] A question on longest match >Date: Tue, 1 Jun 2004 13:43:25 +0530 > >Is your question related to BGP or is it related to general routing >(networking) principles? > >If its the latter then you need to start with a good book on basic >networking principles (unless ofcourse i am missing your point altogether!) >and if its the latter, then it doesn't make much sense to me ! Care to >elaborate? > >-- >(&) >Big brother John > >----- Original Message ----- >From: "john smith" >To: >Sent: Tuesday, June 01, 2004 1:19 PM >Subject: [Idr] A question on longest match > > > > Hello, > > > > Is there any specific reason why the BGP algorithm relies on the longest > > match paradigm? > > > > Is there any reason why one cannot simply propogate the "range of >addresses" > > and use different metrics? > > For example one could say "address numbers 100000 - 212123 are here and > > 212124 - 312127 are there? > > > > Would this not lead to considerable reduction of the size of the >forwarding > > table? > > > > -- > > (&) > > Little John. > > > > _________________________________________________________________ > > Add photos to your messages with MSN 8. Get 2 months FREE*. > > http://join.msn.com/?page=features/featuredemail > > > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www1.ietf.org/mailman/listinfo/idr > > > > _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From mailman-bounces@ietf.org Tue Jun 1 07:43:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19717 for ; Tue, 1 Jun 2004 07:43:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BV7gL-00027W-Rh for idr-archive@ietf.org; Tue, 01 Jun 2004 07:43:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BV7fR-0001ho-00 for idr-archive@ietf.org; Tue, 01 Jun 2004 07:42:54 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BV7eX-0000rq-00 for idr-archive@ietf.org; Tue, 01 Jun 2004 07:41:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV5Ys-00050N-9I for idr-archive@ietf.org; Tue, 01 Jun 2004 05:27:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: idr-archive@ietf.org X-No-Archive: yes Message-ID: Date: Tue, 01 Jun 2004 05:04:58 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for idr-archive@ietf.org: List Password // URL ---- -------- idr@ietf.org omkeeh https://www1.ietf.org/mailman/options/idr/idr-archive%40ietf.org From mailman-admin@ietf.org Tue Jun 1 11:50:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17854 for ; Tue, 1 Jun 2004 11:50:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVBWs-00039o-5B for idr-archive@ietf.org; Tue, 01 Jun 2004 11:50:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVBV2-0002Pi-00 for idr-archive@ietf.org; Tue, 01 Jun 2004 11:48:25 -0400 Received: from jupiter.cnri.reston.va.us ([132.151.1.18] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1BVBU4-0001wn-00 for idr-archive@ietf.org; Tue, 01 Jun 2004 11:47:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BV956-00089C-UQ for idr-archive@ietf.org; Tue, 01 Jun 2004 09:13:28 -0400 Date: Tue, 01 Jun 2004 09:13:28 -0400 Message-ID: <20040601131328.26555.8267.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: idr-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, idr-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for idr-archive@ietf.org: List Password // URL ---- -------- idr@ietf.org omkeeh https://www1.ietf.org/mailman/options/idr/idr-archive%40ietf.org From idr-bounces@ietf.org Tue Jun 1 17:01:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24417 for ; Tue, 1 Jun 2004 17:01:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVGOK-0000uX-Vv for idr-archive@ietf.org; Tue, 01 Jun 2004 17:01:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVGMT-0000LE-00 for idr-archive@ietf.org; Tue, 01 Jun 2004 16:59:54 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BVGJX-00079N-00; Tue, 01 Jun 2004 16:56:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVG42-0001TU-A9; Tue, 01 Jun 2004 16:40:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVCXV-0005bp-1y for idr@megatron.ietf.org; Tue, 01 Jun 2004 12:55:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25100 for ; Tue, 1 Jun 2004 12:54:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVCXT-0003TB-VX for idr@ietf.org; Tue, 01 Jun 2004 12:55:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVCSx-00020j-00 for idr@ietf.org; Tue, 01 Jun 2004 12:50:20 -0400 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1BVCNz-0000Mz-00 for idr@ietf.org; Tue, 01 Jun 2004 12:45:11 -0400 Received: from [192.168.0.2] (pcp09296126pcs.arlngt01.va.comcast.net[69.143.165.226]) by comcast.net (sccrmhc11) with ESMTP id <20040601164440011009lu73e> (Authid: hcb8); Tue, 1 Jun 2004 16:44:40 +0000 Mime-Version: 1.0 X-Sender: hcb8@smtp.comcast.net (Unverified) Message-Id: In-Reply-To: References: Date: Tue, 1 Jun 2004 12:44:38 -0400 To: idr@ietf.org From: "Howard C. Berkowitz" Subject: RE: [Idr] A question on longest match Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 At 8:19 AM +0000 6/1/04, john smith wrote: >Hello Big Brother, > >It is specifically releated to BGP. > >Aggregation in non DV protocols is not a possibility unless one goes >across Area/Level boundarys. Maybe I'm missing something, but I wouldn't make that claim. Hierarchical topology and multiple levels are not a requirement of routing protocols. Many large ISPs run very big single ISIS areas. So, there very well may not be Area/Level boundaries to cross. Hierarchical information hiding MAY be a useful deployment technique in LS protocols to reduce the computational load of the Dijkstra algorithm, but it's perfectly reasonable and plausible to build hierarchical networks in protocols as simple as RIPv1 -- start with Class C (usually private space) at the edge and work up, eventually going to Class B. > >This is due to their inherent nature of sending advertisements of >"all connected networks" to "all nodes in the same level or area". > >Now you do believe aggregation is good, do you not? I am sure you do! > >Now to further that assumption, if aggregation is good, and one was >to make a forwarding device which would not do Layer 3 lookup based >on the bit aligned boundaries, but on ranges, would it be considered >bad or good? > >Also please let me know if this is not an item to dicuss on idr, or >should the be specifically targetted to the routing-discussion >mailing list? In that case I shall not cc the list further on these >queries. > >-- >(&) >Little John. > >>From: "John Smith" >>To: >>Subject: RE: [Idr] A question on longest match >>Date: Tue, 1 Jun 2004 13:43:25 +0530 >> >>Is your question related to BGP or is it related to general routing >>(networking) principles? >> >>If its the latter then you need to start with a good book on basic >>networking principles (unless ofcourse i am missing your point altogether!) >>and if its the latter, then it doesn't make much sense to me ! Care to >>elaborate? >> >>-- >>(&) >>Big brother John >> >>----- Original Message ----- >>From: "john smith" >>To: >>Sent: Tuesday, June 01, 2004 1:19 PM >>Subject: [Idr] A question on longest match >> >> >>> Hello, >>> >>> Is there any specific reason why the BGP algorithm relies on the longest >>> match paradigm? >>> >>> Is there any reason why one cannot simply propogate the "range of >>addresses" >>> and use different metrics? >>> For example one could say "address numbers 100000 - 212123 are here and >>> 212124 - 312127 are there? >>> >>> Would this not lead to considerable reduction of the size of the >>forwarding >>> table? >>> >>> -- >>> (&) >>> Little John. >>> >>> _________________________________________________________________ >>> Add photos to your messages with MSN 8. Get 2 months FREE*. >>> http://join.msn.com/?page=features/featuredemail >>> >>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www1.ietf.org/mailman/listinfo/idr >>> >> > >_________________________________________________________________ >The new MSN 8: advanced junk mail protection and 2 months FREE* >http://join.msn.com/?page=features/junkmail > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 1 22:07:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14068 for ; Tue, 1 Jun 2004 22:07:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVLA3-0005bq-9a for idr-archive@ietf.org; Tue, 01 Jun 2004 22:07:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVL93-00054n-00 for idr-archive@ietf.org; Tue, 01 Jun 2004 22:06:22 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BVL7q-00048E-00; Tue, 01 Jun 2004 22:05:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVKjg-0002yl-Nx; Tue, 01 Jun 2004 21:40:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVF3z-0003mm-0d for idr@megatron.ietf.org; Tue, 01 Jun 2004 15:36:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16077 for ; Tue, 1 Jun 2004 15:36:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVF3v-0006xE-20 for idr@ietf.org; Tue, 01 Jun 2004 15:36:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVEiA-0002Ru-00 for idr@ietf.org; Tue, 01 Jun 2004 15:14:11 -0400 Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx with esmtp (Exim 4.12) id 1BVEEX-0004i7-00 for idr@ietf.org; Tue, 01 Jun 2004 14:43:33 -0400 Received: from [192.168.0.2] (pcp09296126pcs.arlngt01.va.comcast.net[69.143.165.226]) by comcast.net (sccrmhc12) with ESMTP id <2004060118430301200e1rc9e> (Authid: hcb8); Tue, 1 Jun 2004 18:43:03 +0000 Mime-Version: 1.0 X-Sender: hcb8@smtp.comcast.net (Unverified) Message-Id: Date: Tue, 1 Jun 2004 14:43:01 -0400 To: idr@ietf.org From: "Howard C. Berkowitz" Subject: RE: [Idr] A question on longest match Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 At 8:19 AM +0000 6/1/04, john smith wrote: >Hello Big Brother, > >It is specifically releated to BGP. > >Aggregation in non DV protocols is not a possibility unless one goes >across Area/Level boundarys. Maybe I'm missing something, but I wouldn't make that claim. Hierarchical topology and multiple levels are not a requirement of routing protocols. Many large ISPs run very big single ISIS areas. So, there very well may not be Area/Level boundaries to cross. Hierarchical information hiding MAY be a useful deployment technique in LS protocols to reduce the computational load of the Dijkstra algorithm, but it's perfectly reasonable and plausible to build hierarchical networks in protocols as simple as RIPv1 -- start with Class C (usually private space) at the edge and work up, eventually going to Class B. > >This is due to their inherent nature of sending advertisements of >"all connected networks" to "all nodes in the same level or area". > >Now you do believe aggregation is good, do you not? I am sure you do! > >Now to further that assumption, if aggregation is good, and one was >to make a forwarding device which would not do Layer 3 lookup based >on the bit aligned boundaries, but on ranges, would it be considered >bad or good? > >Also please let me know if this is not an item to dicuss on idr, or >should the be specifically targetted to the routing-discussion >mailing list? In that case I shall not cc the list further on these >queries. > >-- >(&) >Little John. > >>From: "John Smith" >>To: >>Subject: RE: [Idr] A question on longest match >>Date: Tue, 1 Jun 2004 13:43:25 +0530 >> >>Is your question related to BGP or is it related to general routing >>(networking) principles? >> >>If its the latter then you need to start with a good book on basic >>networking principles (unless ofcourse i am missing your point altogether!) >>and if its the latter, then it doesn't make much sense to me ! Care to >>elaborate? >> >>-- >>(&) >>Big brother John >> >>----- Original Message ----- >>From: "john smith" >>To: >>Sent: Tuesday, June 01, 2004 1:19 PM >>Subject: [Idr] A question on longest match >> >> >>> Hello, >>> >>> Is there any specific reason why the BGP algorithm relies on the longest >>> match paradigm? >>> >>> Is there any reason why one cannot simply propogate the "range of >>addresses" >>> and use different metrics? >>> For example one could say "address numbers 100000 - 212123 are here and >>> 212124 - 312127 are there? >>> >>> Would this not lead to considerable reduction of the size of the >>forwarding >>> table? >>> >>> -- >>> (&) >>> Little John. >>> >>> _________________________________________________________________ >>> Add photos to your messages with MSN 8. Get 2 months FREE*. >>> http://join.msn.com/?page=features/featuredemail >>> >>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www1.ietf.org/mailman/listinfo/idr >>> >> > >_________________________________________________________________ >The new MSN 8: advanced junk mail protection and 2 months FREE* >http://join.msn.com/?page=features/junkmail > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jun 2 03:09:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03942 for ; Wed, 2 Jun 2004 03:09:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVPsJ-0003zp-OK for idr-archive@ietf.org; Wed, 02 Jun 2004 03:09:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVPr2-0003Mm-00 for idr-archive@ietf.org; Wed, 02 Jun 2004 03:08:05 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BVPp8-0002Kd-00; Wed, 02 Jun 2004 03:06:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVP9N-00011D-JC; Wed, 02 Jun 2004 02:22:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVOjH-0006ti-1f for idr@megatron.ietf.org; Wed, 02 Jun 2004 01:56:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00726 for ; Wed, 2 Jun 2004 01:55:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVOjE-0002HP-Ru for idr@ietf.org; Wed, 02 Jun 2004 01:55:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVOiC-0001jE-00 for idr@ietf.org; Wed, 02 Jun 2004 01:54:53 -0400 Received: from bay17-f8.bay17.hotmail.com ([64.4.43.58] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BVOhA-0000nd-00 for idr@ietf.org; Wed, 02 Jun 2004 01:53:48 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 1 Jun 2004 22:53:19 -0700 Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Wed, 02 Jun 2004 05:53:18 GMT X-Originating-IP: [61.16.170.194] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: hcb@gettcomm.com, idr@ietf.org Subject: RE: [Idr] A question on longest match Date: Wed, 02 Jun 2004 05:53:18 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Jun 2004 05:53:19.0370 (UTC) FILETIME=[E7F4E6A0:01C44865] 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.7 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Thanks Howard, My question is more specific to the paradigm of longest match. In most cases, we have: (Routing protocols)-->Best routes_based_on_metric/prefix_size/protocol_metric/foobar-->RIB-->FIB My question specifically is that do most vendors aggregate the entries when they go from the RIB to the FIB? The problem specifically cropped up when I realised that some peers were sending multiple /24s (even though they were contiguous) to a node I was working on though the next-hop was the same. I was wondering if there is an "aggregation" performed based on next-hop when putting routes into the FIB. Of course a more pragmatic approach is ofcourse to enforce aggregation rather than have a prefix range propogation. However, I assume the biggest problem is the population of the FIB and hence the need for prefix range filtering. Would it not be easier, for starters, to simply aggregate routes based on next-hop when populating the FIB? this would not even break the longest match method used to balance links, but would solve the FIB explosion problem. -John >From: "Howard C. Berkowitz" >To: idr@ietf.org >Subject: RE: [Idr] A question on longest match >Date: Tue, 1 Jun 2004 14:43:01 -0400 > >At 8:19 AM +0000 6/1/04, john smith wrote: >>Hello Big Brother, >> >>It is specifically releated to BGP. >> >>Aggregation in non DV protocols is not a possibility unless one goes >>across Area/Level boundarys. > >Maybe I'm missing something, but I wouldn't make that claim. Hierarchical >topology and multiple levels are not a requirement of routing protocols. >Many large ISPs run very big single ISIS areas. So, there very well may not >be Area/Level boundaries to cross. > >Hierarchical information hiding MAY be a useful deployment technique in LS >protocols to reduce the computational load of the Dijkstra algorithm, but >it's perfectly reasonable and plausible to build hierarchical networks in >protocols as simple as RIPv1 -- start with Class C (usually private space) >at the edge and work up, eventually going to Class B. > >> >>This is due to their inherent nature of sending advertisements of "all >>connected networks" to "all nodes in the same level or area". >> >>Now you do believe aggregation is good, do you not? I am sure you do! >> >>Now to further that assumption, if aggregation is good, and one was to >>make a forwarding device which would not do Layer 3 lookup based on the >>bit aligned boundaries, but on ranges, would it be considered bad or good? >> >>Also please let me know if this is not an item to dicuss on idr, or should >>the be specifically targetted to the routing-discussion mailing list? In >>that case I shall not cc the list further on these queries. >> >>-- >>(&) >>Little John. >> >>>From: "John Smith" >>>To: >>>Subject: RE: [Idr] A question on longest match >>>Date: Tue, 1 Jun 2004 13:43:25 +0530 >>> >>>Is your question related to BGP or is it related to general routing >>>(networking) principles? >>> >>>If its the latter then you need to start with a good book on basic >>>networking principles (unless ofcourse i am missing your point >>>altogether!) >>>and if its the latter, then it doesn't make much sense to me ! Care to >>>elaborate? >>> >>>-- >>>(&) >>>Big brother John >>> >>>----- Original Message ----- >>>From: "john smith" >>>To: >>>Sent: Tuesday, June 01, 2004 1:19 PM >>>Subject: [Idr] A question on longest match >>> >>> >>>> Hello, >>>> >>>> Is there any specific reason why the BGP algorithm relies on the >>>>longest >>>> match paradigm? >>>> >>>> Is there any reason why one cannot simply propogate the "range of >>>addresses" >>>> and use different metrics? >>>> For example one could say "address numbers 100000 - 212123 are here >>>>and >>>> 212124 - 312127 are there? >>>> >>>> Would this not lead to considerable reduction of the size of the >>>forwarding >>>> table? >>>> >>>> -- >>>> (&) >>>> Little John. >>>> >>>> _________________________________________________________________ >>>> Add photos to your messages with MSN 8. Get 2 months FREE*. >>>> http://join.msn.com/?page=features/featuredemail >>>> >>>> >>>> _______________________________________________ >>>> Idr mailing list >>>> Idr@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/idr >>>> >>> >> >>_________________________________________________________________ >>The new MSN 8: advanced junk mail protection and 2 months FREE* >>http://join.msn.com/?page=features/junkmail >> >> >>_______________________________________________ >>Idr mailing list >>Idr@ietf.org >>https://www1.ietf.org/mailman/listinfo/idr > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jun 2 22:19:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10867 for ; Wed, 2 Jun 2004 22:19:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVhp3-0006es-Q0 for idr-archive@ietf.org; Wed, 02 Jun 2004 22:19:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVhnH-00062l-00 for idr-archive@ietf.org; Wed, 02 Jun 2004 22:17:24 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BVhmD-0005Ez-00; Wed, 02 Jun 2004 22:16:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVhQp-0006WY-6I; Wed, 02 Jun 2004 21:54:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVbZt-0006YV-IY for idr@megatron.ietf.org; Wed, 02 Jun 2004 15:39:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14321 for ; Wed, 2 Jun 2004 15:39:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVbZs-00027U-6z for idr@ietf.org; Wed, 02 Jun 2004 15:39:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVbYr-0001gM-00 for idr@ietf.org; Wed, 02 Jun 2004 15:38:06 -0400 Received: from 69.37.59.162.adsl.snet.net ([69.37.59.162] helo=workhorse.faster-light.net) by ietf-mx with esmtp (Exim 4.12) id 1BVbXo-00012s-00 for idr@ietf.org; Wed, 02 Jun 2004 15:37:00 -0400 Received: from workhorse.faster-light.net (localhost.fictitious.org [127.0.0.1]) by workhorse.faster-light.net (8.12.9p2/8.12.8) with ESMTP id i52JYL3W080016; Wed, 2 Jun 2004 15:34:21 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200406021934.i52JYL3W080016@workhorse.faster-light.net> To: "john smith" Subject: Re: [Idr] A question on longest match In-reply-to: Your message of "Wed, 02 Jun 2004 05:53:18 -0000." Date: Wed, 02 Jun 2004 15:34:21 -0400 From: Curtis Villamizar Cc: hcb@gettcomm.com, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message , "john smith" writes: > Thanks Howard, > > My question is more specific to the paradigm of longest match. > > In most cases, we have: > > (Routing protocols)-->Best > routes_based_on_metric/prefix_size/protocol_metric/foobar-->RIB-->FIB > > My question specifically is that do most vendors aggregate the entries when > they go from the RIB to the FIB? > > The problem specifically cropped up when I realised that some peers were > sending multiple /24s (even though they were contiguous) to a node I was > working on though the next-hop was the same. > > I was wondering if there is an "aggregation" performed based on next-hop > when putting routes into the FIB. > > Of course a more pragmatic approach is ofcourse to enforce aggregation > rather than have a prefix range propogation. > > However, I assume the biggest problem is the population of the FIB and hence > the need for prefix range filtering. > > Would it not be easier, for starters, to simply aggregate routes based on > next-hop when populating the FIB? > > this would not even break the longest match method used to balance links, > but would solve the FIB explosion problem. > > -John Its not worth it to aggregate the FIB. There is very little gain if you don't aggregate over holes. If you aggregate over holes you'd need to include more specific reject routes. If you aggregate the FIB and a withdraw occurs you need to add a reject. You then need to be concerned about aggregating the rejects that you are adding. Gain is small. There is an increase in completity. Disallowing longest to allow automatic aggregation was discussed on BGP, BGPD, CIDR, or CIDRD more than 10 years ago. We didn't go that way and its way too late to turn back. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 3 07:12:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01644 for ; Thu, 3 Jun 2004 07:12:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVq8l-0003aN-Ju for idr-archive@ietf.org; Thu, 03 Jun 2004 07:12:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVq7E-0002jv-00 for idr-archive@ietf.org; Thu, 03 Jun 2004 07:10:33 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BVq5V-00028f-00; Thu, 03 Jun 2004 07:08:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVpt0-0004dv-VR; Thu, 03 Jun 2004 06:55:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVlZ5-0006I6-Pf for idr@megatron.ietf.org; Thu, 03 Jun 2004 02:18:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11579 for ; Thu, 3 Jun 2004 02:18:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVlYo-0005lO-IJ for idr@ietf.org; Thu, 03 Jun 2004 02:18:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVlXy-0005OF-00 for idr@ietf.org; Thu, 03 Jun 2004 02:17:51 -0400 Received: from bay17-f44.bay17.hotmail.com ([64.4.43.94] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BVlX6-0004Zf-00 for idr@ietf.org; Thu, 03 Jun 2004 02:16:56 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 2 Jun 2004 23:16:26 -0700 Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Thu, 03 Jun 2004 06:16:26 GMT X-Originating-IP: [61.16.170.194] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: curtis@faster-light.net Subject: Re: [Idr] A question on longest match Date: Thu, 03 Jun 2004 06:16:26 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jun 2004 06:16:26.0908 (UTC) FILETIME=[4D6825C0:01C44932] 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS autolearn=no version=2.60 Hello Curtis, That is strange indeed. I have seen very different results when doing the same. I am not talking about aggregating over holes at all. I am simply saying, I receive 20 prefixes of say /19 from 1 link and 40 of say /20 from the other. Most of these as far as I can see can be aggregated, but are still advertised as they are due to the presence of longest match paradigm However, I guess this is specific to my view, Though, why is there a problem in doing so? > >Its not worth it to aggregate the FIB. There is very little gain if >you don't aggregate over holes. > >If you aggregate over holes you'd need to include more specific reject >routes. > >If you aggregate the FIB and a withdraw occurs you need to add a >reject. You then need to be concerned about aggregating the rejects >that you are adding. > >Gain is small. There is an increase in completity. > >Disallowing longest to allow automatic aggregation was discussed on >BGP, BGPD, CIDR, or CIDRD more than 10 years ago. We didn't go that >way and its way too late to turn back. > >Curtis _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 3 08:06:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04839 for ; Thu, 3 Jun 2004 08:06:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVqyw-0001Wc-TO for idr-archive@ietf.org; Thu, 03 Jun 2004 08:06:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVqxv-00018x-00 for idr-archive@ietf.org; Thu, 03 Jun 2004 08:04:59 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BVqxO-0000kq-00; Thu, 03 Jun 2004 08:04:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVqBq-00015B-5c; Thu, 03 Jun 2004 07:15:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVnR8-0002YO-Lw for idr@megatron.ietf.org; Thu, 03 Jun 2004 04:18:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18883 for ; Thu, 3 Jun 2004 04:18:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVnR6-0006cW-Ei for idr@ietf.org; Thu, 03 Jun 2004 04:18:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVnQI-0006Ey-00 for idr@ietf.org; Thu, 03 Jun 2004 04:18:03 -0400 Received: from bay17-f29.bay17.hotmail.com ([64.4.43.79] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BVnPW-0005ly-00 for idr@ietf.org; Thu, 03 Jun 2004 04:17:14 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 3 Jun 2004 01:16:45 -0700 Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Thu, 03 Jun 2004 08:16:44 GMT X-Originating-IP: [61.16.170.194] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: idr@ietf.org Subject: Re: [Idr] A question on longest match Date: Thu, 03 Jun 2004 08:16:44 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jun 2004 08:16:45.0015 (UTC) FILETIME=[1BBBDE70:01C44943] 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS autolearn=no version=2.60 >Its not worth it to aggregate the FIB. There is very little gain if >you don't aggregate over holes. Curtis, the nodes where the holes occur are way down in the network. Infact the places where they do occur happen to be places where /24 networks may actually be connected. The offset for the same is the fact that the rest of the internet as seen from that point is "coniguous". So it offsets the same. This has been my observation. > >If you aggregate over holes you'd need to include more specific reject >routes. > I do not aggregate over holes. I suggest aggregate "what one can as long as the next-hop is the same" and populate the FIB. I agree it makes more sense to aggregate and propogate, but if not that, can we atleast aggregate what goes into the FIB? >If you aggregate the FIB and a withdraw occurs you need to add a >reject. You then need to be concerned about aggregating the rejects >that you are adding. > I could also break the aggregate at that point of time. I still have the specifics in the RIB rememeber? >Gain is small. There is an increase in completity. > It can be the same for *all protocols* Gain can be immense I think. >Disallowing longest to allow automatic aggregation was discussed on >BGP, BGPD, CIDR, or CIDRD more than 10 years ago. We didn't go that >way and its way too late to turn back. > :) >Curtis _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 3 11:52:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22180 for ; Thu, 3 Jun 2004 11:52:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVuW9-000159-4U for idr-archive@ietf.org; Thu, 03 Jun 2004 11:52:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVuUe-0000bk-00 for idr-archive@ietf.org; Thu, 03 Jun 2004 11:51:02 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BVuRw-0007U3-00; Thu, 03 Jun 2004 11:48:12 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BVuRx-0004Iv-8L; Thu, 03 Jun 2004 11:48:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVtfa-0004lP-7s; Thu, 03 Jun 2004 10:58:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVsHa-0007jp-OQ for idr@megatron.ietf.org; Thu, 03 Jun 2004 09:29:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09390 for ; Thu, 3 Jun 2004 09:29:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVsHW-0002QQ-2y for idr@ietf.org; Thu, 03 Jun 2004 09:29:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVsES-0001y0-00 for idr@ietf.org; Thu, 03 Jun 2004 09:26:09 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BVsDe-0001IT-00 for idr@ietf.org; Thu, 03 Jun 2004 09:25:19 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i53DOm959483 for ; Thu, 3 Jun 2004 06:24:48 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i53DOhJ23583 for ; Thu, 3 Jun 2004 06:24:43 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406031324.i53DOhJ23583@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <53329.1086269083.1@juniper.net> Date: Thu, 03 Jun 2004 06:24:43 -0700 From: Yakov Rekhter Subject: [Idr] proposed additional text in the Security Section 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, Based on the feedback we received so far the text in the attached will be added "as is" to the Security Considerations section of the BGP spec (and the Reference section will be updated as appropriate). Yakov. ------- Forwarded Message Date: Mon, 24 May 2004 07:32:55 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] proposed additional text Folks, Steve Kent proposed the following replacement for the text he suggested earlier (the text I posted on 5/17/2004). BGP makes use of TCP for reliable transport of its traffic between peer routers. To provide connection-oriented integrity and data origin authentication, on a point-to-point basis, BGP specifies use of the mechanism defined in RFC 2385. These services are intended to detect and reject active wiretapping attacks against the inter-router TCP connections. Absent use of mechanisms that effect these security services, attackers can disrupt these TCP connections and/or masquerade as a legitimate peer router. Because the mechanism defined in the RFC does not provide peer-entity authentication, these connections may be subject to some forms of replay attacks that will not be detected at the TCP layer. Such attacks might result in delivery (from TCP) of "broken" or "spoofed" BGP messages. The mechanism defined in RFC 2385 augments the normal TCP checksum with a 16-byte message authentication code (MAC) that is computed over the same data as the TCP checksum. This MAC is based on a one-way hash function (MD5) and use of a secret key. The key is shared between peer routers and is used to generate MAC values that are not readily computed by an attacker who does not have access to the key. A compliant implementation must support this mechanism, and must allow a network administrator to activate it on a per-peer basis. RFC 2385 does not specify a means of managing (e.g., generating, distributing, and replacing) the keys used to compute the MAC. RFC 3562 (an informational document) provides some guidance in this area, and provides rationale to support this guidance. It notes that a distinct key should be used for communication with each protected peer. If the same key is used for multiple peers, the offered security services may be degraded, e.g., due to increased risk of compromise at one router adversely affecting other routers. The keys used for MAC computation should be changed periodically, to minimize the impact of a key compromise or successful cryptanalytic attack. RFC 3562 suggest a crypto period (the interval during which a key is employed) of at most 90 days. More frequent key changes reduce the likelihood that replay attacks (as described above) will be feasible. However, absent a standard mechanism for effecting such changes in a coordinated fashion between peers, one cannot assume that BGP-4 implementations complying with this RFC will support frequent key changes. Obviously, each key also should be chosen so as to be hard for an attacker to guess. The techniques specified in RFC 1750 for random number generation provide a guide for generation of values that could be used as keys. RFC 2385 calls for implementations to support keys "composed of a string of printable ASCII of 80 bytes or less." RFC 3562 suggests keys used in this context be 12 to 24 bytes of random (pseudo-random) bits. This is fairly consistent with suggestions for analogous MAC algorithms, which typically employ keys in the range of 16-20 bytes. RFC 3562 also observes that, to provide enough random bits at the low end of this range, a typical ACSII text string would have to be close to the upper bound for key length specified in RFC 2385. Please review and comment. The deadline for comments is 6/2/2004. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 3 13:00:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25205 for ; Thu, 3 Jun 2004 13:00:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVvZq-0007O3-Sa for idr-archive@ietf.org; Thu, 03 Jun 2004 13:00:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVv8E-0000NY-00 for idr-archive@ietf.org; Thu, 03 Jun 2004 12:31:55 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BVv6O-0007Xp-00; Thu, 03 Jun 2004 12:30:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVtpP-0006Ws-Rg; Thu, 03 Jun 2004 11:08:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVsec-0002Ki-UE for idr@megatron.ietf.org; Thu, 03 Jun 2004 09:53:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11549 for ; Thu, 3 Jun 2004 09:52:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVseN-0003G3-4m for idr@ietf.org; Thu, 03 Jun 2004 09:52:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVsdP-0002sA-00 for idr@ietf.org; Thu, 03 Jun 2004 09:51:56 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BVscL-00025Y-00 for idr@ietf.org; Thu, 03 Jun 2004 09:50:50 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i53DoJBm007034 for ; Thu, 3 Jun 2004 06:50:19 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i53DoJJ25959 for ; Thu, 3 Jun 2004 06:50:19 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406031350.i53DoJJ25959@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <56931.1086270619.1@juniper.net> Date: Thu, 03 Jun 2004 06:50:19 -0700 From: Yakov Rekhter Subject: [Idr] missing text 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, As John Scudder pointed recently the following text in 5.1.2 is incomplete, as it does not cover the case when the route that is to be advertised was received with empty AS_PATH attribute (this could happen if the route was originated elsewhere in the AS and received via IBGP): b) When a given BGP speaker advertises the route to an external peer, then the advertising speaker updates the AS_PATH attribute as follows: 1) if the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS number as the last element of the sequence (put it in the leftmost position with respect to the position of octets in the protocol mes- sage). If the act of prepending will cause an overflow in the AS_PATH segment, i.e. more than 255 ASs, it SHOULD prepend a new segment of type AS_SEQUENCE and prepend its own AS number to this new segment. 2) if the first path segment of the AS_PATH is of type AS_SET, the local system prepends a new path segment of type AS_SEQUENCE to the AS_PATH, including its own AS number in that segment. So, to fix this I'd like to propose to add at the end of the above text the following: 3) if the AS_PATH is empty, the local system creates a path segment of type AS_SEQUENCE, places its own AS into that segment, and places that segment into the AS_PATH. Please comment on this. The deadline for comments is June 17, 2004. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 3 15:22:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05803 for ; Thu, 3 Jun 2004 15:22:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVxnI-0001r2-VG for idr-archive@ietf.org; Thu, 03 Jun 2004 15:22:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVxmL-0001Te-00 for idr-archive@ietf.org; Thu, 03 Jun 2004 15:21:30 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BVxlp-00016a-00; Thu, 03 Jun 2004 15:20:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVxDS-0004Q2-1c; Thu, 03 Jun 2004 14:45:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVwPM-00015s-Gq for idr@megatron.ietf.org; Thu, 03 Jun 2004 13:53:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24544 for ; Thu, 3 Jun 2004 12:58:24 -0400 (EDT) From: qning@chiaro.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVvXu-0007Ac-Ig for idr@ietf.org; Thu, 03 Jun 2004 12:58:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVvOz-000357-00 for idr@ietf.org; Thu, 03 Jun 2004 12:49:14 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BVvMr-0002GW-00 for idr@ietf.org; Thu, 03 Jun 2004 12:47:01 -0400 Received: from [62.90.11.34] (helo=cisex001.cis.chiaro.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BVv8K-0002MA-G9 for idr@ietf.org; Thu, 03 Jun 2004 12:32:00 -0400 Received: from rchst007.cus.chiaro.com ([192.168.8.120]) by cisex001.cis.chiaro.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 3 Jun 2004 19:21:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Jun 2004 11:21:03 -0500 Message-ID: <34B6386F843340459B22F59DFF7B12FF31917B@192-168-240-22.chiaro.com> Thread-Topic: [Idr] A question on longest match thread-index: AcRJEL5Ko4HwLBMDRRiwQGBJKpA09AAdanqg To: X-OriginalArrivalTime: 03 Jun 2004 16:21:02.0573 (UTC) FILETIME=[C36359D0:01C44986] Content-Transfer-Encoding: quoted-printable Subject: [Idr] Question about RFC 3107 Carrying label in bgp-4 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, I will use=20 192.168.0.0/16 as an ip prefix, and 0x102031 as an mpls label in the following questions. RFC 3107 (Carrying Label Information in BGP-4)=20 Section 3 states=20 0x102031:192.168.0.0/16 can be advertised in a MP_REACH_NLRI.=20 It can be withdrawn by either=20 a) a new route with a new label: 0xB1B2B3:192.168.0.0/16 in MP_REACG_NLRI or b) 0x800000:192.168.0.0/16 in a MP_UNREACH_NLRI. In Section 4, it states that multiple routes to the same destination, but different labels can be maintained and advertised.=20 This seams to contradict to Section 3 a). If Section 3 a) is used, both routes would have been kept by peer, instead of deleting 0x102031:192.168.0.0/16 and keeping 0xB1B2B3:192.168.0.0/16. Section 4 also states that a peer would keep both 192.168.0.0/16 and 0x102031:192.168.0.0/16=20 if 192.168.0.0/16 is advertised with=20 (AFI=3D1, SAFI=3D1) and 0x102031:192.168.0.0/16 is advertised with (AFI=3D1, SAFI=3D4). Does this contradicts to BGP's general principle that only one route from a peer is kept? Does this also implicitly mean that 0x102031:192.168.0.0/16 cannot be used for regular ipv4 unicast routing? It looks to me that the entire Section 4 is contradictory. -- Qi Ning _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 3 15:25:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06027 for ; Thu, 3 Jun 2004 15:25:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVxqg-00039j-DD for idr-archive@ietf.org; Thu, 03 Jun 2004 15:25:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVxpU-0002iL-00 for idr-archive@ietf.org; Thu, 03 Jun 2004 15:24:45 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BVxoy-0002IR-00; Thu, 03 Jun 2004 15:24:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVxDV-0004VO-SI; Thu, 03 Jun 2004 14:45:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVwPN-00015s-Lt for idr@megatron.ietf.org; Thu, 03 Jun 2004 13:53:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24394 for ; Thu, 3 Jun 2004 12:57:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVvWx-00076l-4c for idr@ietf.org; Thu, 03 Jun 2004 12:57:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVvU5-00062W-00 for idr@ietf.org; Thu, 03 Jun 2004 12:54:30 -0400 Received: from bay17-f43.bay17.hotmail.com ([64.4.43.93] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BVvTM-0005Ee-00 for idr@ietf.org; Thu, 03 Jun 2004 12:53:44 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 3 Jun 2004 09:53:13 -0700 Received: from 219.65.134.175 by by17fd.bay17.hotmail.msn.com with HTTP; Thu, 03 Jun 2004 16:53:13 GMT X-Originating-IP: [219.65.134.175] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: curtis@faster-light.net Subject: Re: [Idr] A question on longest match Date: Thu, 03 Jun 2004 16:53:13 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jun 2004 16:53:13.0881 (UTC) FILETIME=[42899090:01C4498B] 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Hello Curtis, > > Hello Curtis, > > > > That is strange indeed. > > > > I have seen very different results when doing the same. > > > > I am not talking about aggregating over holes at all. > > > > I am simply saying, > > > > I receive 20 prefixes of say /19 from 1 link and 40 of say /20 from the > > other. > > > > Most of these as far as I can see can be aggregated, but are still > > advertised as they are due to the presence of longest match paradigm > > > > However, I guess this is specific to my view, > > > > Though, why is there a problem in doing so? > > >The issue is really what gains can be made for the router with 300,000 >prefixes in the FIB. I did the analysis when the number of global >routes was well under 20,000 and the gains where not all that great >unless you aggregated over the holes. > Please check the specific examples I emailed you offline. Or for that matter please check any node on the internet. In most cases the reduction is quite a bit. >At this point there is no problem in doing so but the cost of FIB >storage isn't that great and the slow down in route insertion/deletion >would be a bad thing for the space reduction. The time lookup is no >issue either with modern hardware. > So we are saying that we will not have more routes? Or we are saying BGP is specifically meant only for vendors and operators who can cater to such hardware? >When you do packet filtering (all core routers need to be able to do >this on all interface types because private peerings can be over >OC192c POS) you have to keep a FIB for the router and then you have to >apply the packet filtering rules per interface. That already >increases the work (the same card can have one processor but more than >one interface, even OC192c or 10GbE). I think most people tend to do: ip route null0 and if they want to use *some RFC 1918 address space* internally, they put a route to pass that space as a more specific. That definately is not an issue which hampers this. Eitherways this is definately *not* packet filtering. > >Anything which further multiplies the change to the FIB makes route >convergence slower and that is a big issue today. Its not the size of >the FIB that matters today its trying to process the amount of change >that can occur in the "well under 1 second" time frame that providers >are looking for. > So can we have something to the effect of: "if there is a terrible impact in performance such a feature should be turned off but if not, it makes sense" ? How it is done can be an implementation issue. _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 3 18:54:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02346 for ; Thu, 3 Jun 2004 18:54:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BW16B-0000X7-JD for idr-archive@ietf.org; Thu, 03 Jun 2004 18:54:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BW0le-0004EV-00 for idr-archive@ietf.org; Thu, 03 Jun 2004 18:32:59 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BW0SX-0000Im-00; Thu, 03 Jun 2004 18:13:13 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BW0NU-000564-Pf; Thu, 03 Jun 2004 18:08:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVzsm-0002IU-9Y; Thu, 03 Jun 2004 17:36:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVyX9-0002JS-QJ for idr@megatron.ietf.org; Thu, 03 Jun 2004 16:09:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10985 for ; Thu, 3 Jun 2004 16:09:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVyX8-00062I-Kt for idr@ietf.org; Thu, 03 Jun 2004 16:09:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVyWH-0005b1-00 for idr@ietf.org; Thu, 03 Jun 2004 16:08:58 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BVyUl-0004Wf-00 for idr@ietf.org; Thu, 03 Jun 2004 16:07:23 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 5E1492D483F for ; Thu, 3 Jun 2004 16:06:53 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 33325-01-49 for ; Thu, 3 Jun 2004 16:06:41 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 1A2102D4900 for ; Thu, 3 Jun 2004 16:06:41 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i53K6fO14498 for idr@ietf.org; Thu, 3 Jun 2004 16:06:41 -0400 (EDT) Date: Thu, 3 Jun 2004 16:06:41 -0400 From: Jeffrey Haas To: idr@ietf.org Subject: Re: [Idr] missing text Message-ID: <20040603200640.GD13006@nexthop.com> References: <200406031350.i53DoJJ25959@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406031350.i53DoJJ25959@merlot.juniper.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, Jun 03, 2004 at 06:50:19AM -0700, Yakov Rekhter wrote: > So, to fix this I'd like to propose to add at the end of the above > text the following: > > 3) if the AS_PATH is empty, the local system creates > a path segment of type AS_SEQUENCE, places its own AS > into that segment, and places that segment into the AS_PATH. This looks fine to me. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 3 19:01:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03859 for ; Thu, 3 Jun 2004 19:01:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BW1DV-0002AZ-H4 for idr-archive@ietf.org; Thu, 03 Jun 2004 19:01:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BW0u0-0005oP-00 for idr-archive@ietf.org; Thu, 03 Jun 2004 18:41:37 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BW0V9-00010l-00; Thu, 03 Jun 2004 18:15:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BW0FK-0004OL-PM; Thu, 03 Jun 2004 17:59:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVyoK-0007qf-Ig for idr@megatron.ietf.org; Thu, 03 Jun 2004 16:27:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12580 for ; Thu, 3 Jun 2004 16:27:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVyoJ-000602-AV for idr@ietf.org; Thu, 03 Jun 2004 16:27:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVynE-0005Wa-00 for idr@ietf.org; Thu, 03 Jun 2004 16:26:29 -0400 Received: from bay17-f6.bay17.hotmail.com ([64.4.43.56] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BVym8-0004et-00 for idr@ietf.org; Thu, 03 Jun 2004 16:25:20 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 3 Jun 2004 13:24:50 -0700 Received: from 219.65.131.3 by by17fd.bay17.hotmail.msn.com with HTTP; Thu, 03 Jun 2004 20:24:50 GMT X-Originating-IP: [219.65.131.3] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: idr@ietf.org Subject: RE: [Idr] Question about RFC 3107 Carrying label in bgp-4 Date: Thu, 03 Jun 2004 20:24:50 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jun 2004 20:24:50.0328 (UTC) FILETIME=[D235A180:01C449A8] 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 >In Section 4, it states that multiple routes to the >same destination, but different labels can be >maintained and advertised. As if one route was not enough :)........... _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 3 19:20:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07288 for ; Thu, 3 Jun 2004 19:20:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BW1VN-00066i-D5 for idr-archive@ietf.org; Thu, 03 Jun 2004 19:20:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BW1NK-0004Sm-00 for idr-archive@ietf.org; Thu, 03 Jun 2004 19:11:56 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BW1A7-0001TO-00; Thu, 03 Jun 2004 18:58:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BW14A-0000G6-L2; Thu, 03 Jun 2004 18:52:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BW0uq-000543-IW for idr@megatron.ietf.org; Thu, 03 Jun 2004 18:42:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00018 for ; Thu, 3 Jun 2004 18:42:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BW0up-0005yJ-4K for idr@ietf.org; Thu, 03 Jun 2004 18:42:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BW0W2-0001Fr-00 for idr@ietf.org; Thu, 03 Jun 2004 18:16:52 -0400 Received: from relay.pair.com ([209.68.1.20]) by ietf-mx with smtp (Exim 4.12) id 1BW0Cp-00052R-00 for idr@ietf.org; Thu, 03 Jun 2004 17:56:59 -0400 Received: (qmail 20044 invoked from network); 3 Jun 2004 21:56:58 -0000 Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay.pair.com with SMTP; 3 Jun 2004 21:56:58 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.fictitious.org [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id i53Ltr72090334; Thu, 3 Jun 2004 17:55:53 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200406032155.i53Ltr72090334@workhorse.faster-light.net> To: "john smith" Subject: Re: [Idr] A question on longest match In-reply-to: Your message of "Thu, 03 Jun 2004 16:53:13 -0000." Date: Thu, 03 Jun 2004 17:55:53 -0400 From: Curtis Villamizar Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 John, I dropped the IDR Cc but I see you added it back. Comments inline. Curtis In message , "john smith" writes: > Hello Curtis, > > > > > Hello Curtis, > > > > > > That is strange indeed. > > > > > > I have seen very different results when doing the same. > > > > > > I am not talking about aggregating over holes at all. > > > > > > I am simply saying, > > > > > > I receive 20 prefixes of say /19 from 1 link and 40 of say /20 from the > > > other. > > > > > > Most of these as far as I can see can be aggregated, but are still > > > advertised as they are due to the presence of longest match paradigm > > > > > > However, I guess this is specific to my view, > > > > > > Though, why is there a problem in doing so? > > > > > >The issue is really what gains can be made for the router with 300,000 > >prefixes in the FIB. I did the analysis when the number of global > >routes was well under 20,000 and the gains where not all that great > >unless you aggregated over the holes. > > > > Please check the specific examples I emailed you offline. Or for that matter > please check any node on the internet. In most cases the reduction is quite > a bit. Yes I did. You pointed to the 4/8 prefix and some more specific, none of which were contiguous. You also pointed to a block that started at x.x.211/24 and fell under a /16 but I pointed out that a block starting at .211 doesn't compress well unless you fill the holes and then you just need the /16. > >At this point there is no problem in doing so but the cost of FIB > >storage isn't that great and the slow down in route insertion/deletion > >would be a bad thing for the space reduction. The time lookup is no > >issue either with modern hardware. > > > > So we are saying that we will not have more routes? There will be more routes. I did the analysis when there were less than 20,000 routes. There are now 300,000 routes or more depending on who you talk to. Back then this idea was known as "FIB compression" and if you like you can search the archives for a lot of discussion on the issue and quite a bit of measurement done at that time. > Or we are saying BGP is specifically meant only for vendors and operators > who can cater to such hardware? Providers can aggregate better but it requires better coordination among providers. It is up to providers to decide how they configure their routers. Having worked very closely with many router vendors over the last 12 years, and working at one now, I can tell you that the RIB with lots of peers is a much bigger problem than the size of the FIB. There is nothing to stop a vendor from compressing the FIB if they think that will make a better routers. It just happens that none do it an IMHO it would not be a good idea to do so. > >When you do packet filtering (all core routers need to be able to do > >this on all interface types because private peerings can be over > >OC192c POS) you have to keep a FIB for the router and then you have to > >apply the packet filtering rules per interface. That already > >increases the work (the same card can have one processor but more than > >one interface, even OC192c or 10GbE). > > > I think most people tend to do: > ip route null0 > > and if they want to use *some RFC 1918 address space* internally, they put a > route to pass that space as a more specific. That definately is not an issue > which hampers this. > > Eitherways this is definately *not* packet filtering. At peer and most customer boundaries, most providers also do things like block all traffic destined to port numbers for OSPF, BGP, SNMP, and a few others except their EBGP peerings. Some put other packet filters in place, many on source address to prevent spoofing. It to some extent depends on what their routers can do. Filtering is often applied on a per interface basis. It is at least different for outward facing interfaces (connected to peers or customers) than inward facing (connected to the core). For a router with lots of interfaces this is added work. It is not an important point though but it does affect convergence a little if there is lot of filtering that has to be applied after the RP sends the FIB. > >Anything which further multiplies the change to the FIB makes route > >convergence slower and that is a big issue today. Its not the size of > >the FIB that matters today its trying to process the amount of change > >that can occur in the "well under 1 second" time frame that providers > >are looking for. > > > > So can we have something to the effect of: > "if there is a terrible impact in performance such a feature should be > turned off but if not, it makes sense" ? > > How it is done can be an implementation issue. Its up to the providers to decide which trafeoff is more important. No provider has been telling me that they want their routers to do more computation and eat more memory in the RP to compress the FIB such that the line cards can have less entries. If you are a provider, talk to your router vendor if you think that's a good tradeoff. If you are a vendor, talk to providers and see it they are interested. AFAIK there is not interest in FIB compression. ps - but if FIB compression takes off I can claim to have thought of the idea first. :-) But I honestly don't think it will. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jun 4 02:37:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14802 for ; Fri, 4 Jun 2004 02:37:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BW8K6-0002sm-OD for idr-archive@ietf.org; Fri, 04 Jun 2004 02:37:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BW8J7-0002US-00 for idr-archive@ietf.org; Fri, 04 Jun 2004 02:36:02 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BW8Ia-00025G-00; Fri, 04 Jun 2004 02:35:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BW8Fd-0002Vm-IE; Fri, 04 Jun 2004 02:32:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BW88P-0001JS-Ba for idr@megatron.ietf.org; Fri, 04 Jun 2004 02:24:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14007 for ; Fri, 4 Jun 2004 02:24:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BW88N-0005oA-2C for idr@ietf.org; Fri, 04 Jun 2004 02:24:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BW87T-0005Qt-00 for idr@ietf.org; Fri, 04 Jun 2004 02:24:00 -0400 Received: from bay17-f7.bay17.hotmail.com ([64.4.43.57] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BW86V-0004gO-00 for idr@ietf.org; Fri, 04 Jun 2004 02:22:59 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 3 Jun 2004 23:22:29 -0700 Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Fri, 04 Jun 2004 06:22:29 GMT X-Originating-IP: [61.16.170.194] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: curtis@faster-light.net Subject: Re: [Idr] A question on longest match Date: Fri, 04 Jun 2004 06:22:29 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Jun 2004 06:22:29.0828 (UTC) FILETIME=[50231840:01C449FC] 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS autolearn=no version=2.60 Hi Curtis, > > > > Please check the specific examples I emailed you offline. Or for that >matter > > please check any node on the internet. In most cases the reduction is >quite > > a bit. > > >Yes I did. You pointed to the 4/8 prefix and some more specific, none >of which were contiguous. You also pointed to a block that started at >x.x.211/24 and fell under a /16 but I pointed out that a block >starting at .211 doesn't compress well unless you fill the holes and >then you just need the /16. > exactly. > > > >At this point there is no problem in doing so but the cost of FIB > > >storage isn't that great and the slow down in route insertion/deletion > > >would be a bad thing for the space reduction. The time lookup is no > > >issue either with modern hardware. > > > > > > > So we are saying that we will not have more routes? > > >There will be more routes. I did the analysis when there were less >than 20,000 routes. There are now 300,000 routes or more depending on >who you talk to. > Agreed. The point is that other than BGP no other protocol has to rely so heavily on the paradigm of longest match. Mainly as BGP has to carry that information. It really is not a problem to find a route-server equivalent PC which can store a considerable amount of routes without adding an expense to it. The problem is that out of those 300,000 routes, a lot of them are very redundant and I certainly do not appreciate vendors coming out with "1 million routes in the forwarding table" models for no rhyme or reason. Even if we add up the existing deployment of routers, most of them are sufficient to handle the existing prefixes when aggregated for a considerable amount of time. >Back then this idea was known as "FIB compression" and if you like you >can search the archives for a lot of discussion on the issue and quite >a bit of measurement done at that time. > It certainly is better than entring a "split brain" with NO_EXPORT :) > > > Or we are saying BGP is specifically meant only for vendors and >operators > > who can cater to such hardware? > > >Providers can aggregate better but it requires better coordination >among providers. > How has this got *anything* to do with coordination among providers? It is upto the IETF to make the providers cordinate. Eitherways if the IETF thinks the idea makes *any sense* then they should take a step in that direction rather than say "too late". If people can build terabit routers which can switch millions of packets and have a huge FIB, they can figure out ways to reduce the FIB size too. It is a matter of what the "specs" say. Are specs *not* made for scalaibilty? To quote someone from another list, is it not the job of the *specs* to say what is *techincally correct*? >It is up to providers to decide how they configure their routers. >Having worked very closely with many router vendors over the last 12 >years, and working at one now, I can tell you that the RIB with lots >of peers is a much bigger problem than the size of the FIB. > Is that the reason why they want to prefix limit? For that matter, may I be bold enough to ask what *high speed FIB* the merit route servers were using? >There is nothing to stop a vendor from compressing the FIB if they >think that will make a better routers. It just happens that none do >it an IMHO it would not be a good idea to do so. > You contradict the statement below :) where you say you thought of it first. You could probably do a quick search on google and you will find lots of folks who have asked for summarization feature of BGP routes. > > > >When you do packet filtering (all core routers need to be able to do > > >this on all interface types because private peerings can be over > > >OC192c POS) you have to keep a FIB for the router and then you have to > > >apply the packet filtering rules per interface. That already > > >increases the work (the same card can have one processor but more than > > >one interface, even OC192c or 10GbE). > > > > > > I think most people tend to do: > > ip route null0 > > > > and if they want to use *some RFC 1918 address space* internally, they >put a > > route to pass that space as a more specific. That definately is not an >issue > > which hampers this. > > > > Eitherways this is definately *not* packet filtering. > > >At peer and most customer boundaries, most providers also do things >like block all traffic destined to port numbers for OSPF, BGP, SNMP, >and a few others except their EBGP peerings. Some put other packet >filters in place, many on source address to prevent spoofing. It to >some extent depends on what their routers can do. > agreed. The answer was specific to your question. >Filtering is often applied on a per interface basis. It is at least >different for outward facing interfaces (connected to peers or >customers) than inward facing (connected to the core). For a router >with lots of interfaces this is added work. It is not an important >point though but it does affect convergence a little if there is lot >of filtering that has to be applied after the RP sends the FIB. > ?? How has that got anything to do with the question? > > > >Anything which further multiplies the change to the FIB makes route > > >convergence slower and that is a big issue today. Its not the size of > > >the FIB that matters today its trying to process the amount of change > > >that can occur in the "well under 1 second" time frame that providers > > >are looking for. > > > > > > > So can we have something to the effect of: > > "if there is a terrible impact in performance such a feature should be > > turned off but if not, it makes sense" ? > > > > How it is done can be an implementation issue. > > >Its up to the providers to decide which trafeoff is more important. >No provider has been telling me that they want their routers to do >more computation and eat more memory in the RP to compress the FIB >such that the line cards can have less entries. If you are a >provider, talk to your router vendor if you think that's a good >tradeoff. If you are a vendor, talk to providers and see it they are >interested. AFAIK there is not interest in FIB compression. > As i said, please do a google on the same. The question is simple, does the WG intend to scale in a suitable manner or not? > >ps - but if FIB compression takes off I can claim to have thought of >the idea first. :-) But I honestly don't think it will. :-) how many providers did you speak to? Eitherways, I believe it can be specified in the draft, how it is handled can be an implementation issue. _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jun 4 12:14:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20153 for ; Fri, 4 Jun 2004 12:14:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWHLF-00011G-T1 for idr-archive@ietf.org; Fri, 04 Jun 2004 12:14:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWHK8-0000cv-00 for idr-archive@ietf.org; Fri, 04 Jun 2004 12:13:41 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BWHJI-0000Dg-00; Fri, 04 Jun 2004 12:12:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWH5m-0006ap-IA; Fri, 04 Jun 2004 11:58:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWGwV-0004la-VI for idr@megatron.ietf.org; Fri, 04 Jun 2004 11:49:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18644 for ; Fri, 4 Jun 2004 11:49:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWGwU-00079D-LK for idr@ietf.org; Fri, 04 Jun 2004 11:49:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWGv8-0006Yu-00 for idr@ietf.org; Fri, 04 Jun 2004 11:47:50 -0400 Received: from relay.pair.com ([209.68.1.20]) by ietf-mx with smtp (Exim 4.12) id 1BWGtY-0005mW-00 for idr@ietf.org; Fri, 04 Jun 2004 11:46:12 -0400 Received: (qmail 40021 invoked from network); 4 Jun 2004 15:46:06 -0000 Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay.pair.com with SMTP; 4 Jun 2004 15:46:06 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.fictitious.org [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id i54FihqX097023; Fri, 4 Jun 2004 11:44:43 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200406041544.i54FihqX097023@workhorse.faster-light.net> To: "john smith" Subject: Re: [Idr] A question on longest match In-reply-to: Your message of "Fri, 04 Jun 2004 06:22:29 -0000." Date: Fri, 04 Jun 2004 11:44:43 -0400 From: Curtis Villamizar Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message , "john smith" writes: > > > >Back then this idea was known as "FIB compression" and if you like you > >can search the archives for a lot of discussion on the issue and quite > >a bit of measurement done at that time. > > > > It certainly is better than entring a "split brain" with NO_EXPORT :) We're talking about two different things. Automatic aggregation of the FIB is safe to do under all circumstances. Automatice aggregation and reannouncement is not always safe. > > > Or we are saying BGP is specifically meant only for vendors and > >operators > > > who can cater to such hardware? > > > > > >Providers can aggregate better but it requires better coordination > >among providers. > > > > How has this got *anything* to do with coordination among providers? If provider A has a aggregate and some customers are dual homed to provider B, then provider B or downstream can't safely aggregate those routes. If any of those dual homed customers loosed connection to A and most providers rightfully send traffic for the A aggregate to A, then those customers don't have backup through B. See 10 year old discussion on "hostile aggregation". The modern twist on this is that the "provider coordination" these days can be as simple as adding a BGP community. We now have a BGP communitity that can work across any number of AS crossings, the NOPEER. The classic example where this is a problem is the non-aggregation of Australian routes in the US and Europe. Unfortunately the NOPEER isn't being used enough so you need to use the "clue club" (as someone who has contributed a lot to operations has called it, or was it the "clue bat") with the provider origination the route. That too is a form of interprovider coordination, but not one easily standardized. That's what PTOMANE and GROW are all about. Or a big part of it. In the case of 4/8, there were a very small number of more specific. In all likelyhood these are only the ones that really needed to be there (or at least most of them) so you shouldn't touch them. > It is upto the IETF to make the providers cordinate. Eitherways if the IETF > thinks the idea makes *any sense* then they should take a step in that > direction rather than say "too late". > > If people can build terabit routers which can switch millions of packets and > have a huge FIB, they can figure out ways to reduce the FIB size too. It is > a matter of what the "specs" say. > > Are specs *not* made for scalaibilty? To quote someone from another list, is > it not the job of the *specs* to say what is *techincally correct*? Not to be rude but I chopped off the rest of your response. I responded the first time off list because I didn't want to get into an extended thread on this. You are not telling the IETF something that the IETF is not aware of or hasn't thought about. If you want to see what the IETF WGs have had to say about this topic, look in the archives. In particular you want to look at the PTOMAINE and GROW WG, more PTOMAINE. Thanks for the advice. :-) Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jun 4 12:47:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21972 for ; Fri, 4 Jun 2004 12:47:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWHrE-0004vv-AI for idr-archive@ietf.org; Fri, 04 Jun 2004 12:47:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWHoy-00045j-00 for idr-archive@ietf.org; Fri, 04 Jun 2004 12:45:32 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BWHmi-0003As-00; Fri, 04 Jun 2004 12:43:12 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BWHXX-00059I-2X; Fri, 04 Jun 2004 12:27:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWHE0-0008Am-Ee; Fri, 04 Jun 2004 12:07:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWGzZ-0005KR-WC for idr@megatron.ietf.org; Fri, 04 Jun 2004 11:52:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18925 for ; Fri, 4 Jun 2004 11:52:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWGzZ-0000fQ-0j for idr@ietf.org; Fri, 04 Jun 2004 11:52:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWGyh-0000K8-00 for idr@ietf.org; Fri, 04 Jun 2004 11:51:32 -0400 Received: from bay17-f38.bay17.hotmail.com ([64.4.43.88] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BWGy2-0007iT-00 for idr@ietf.org; Fri, 04 Jun 2004 11:50:50 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 4 Jun 2004 08:50:20 -0700 Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Fri, 04 Jun 2004 15:50:20 GMT X-Originating-IP: [61.16.170.194] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: curtis@faster-light.net Subject: Re: [Idr] A question on longest match Date: Fri, 04 Jun 2004 15:50:20 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Jun 2004 15:50:20.0378 (UTC) FILETIME=[A3C473A0:01C44A4B] 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Sorry for being rude Curtis, As I said it was an opinion, and I shared it, It is for the WG to decide. >From: Curtis Villamizar >Reply-To: curtis@faster-light.net >To: "john smith" >CC: curtis@faster-light.net, idr@ietf.org >Subject: Re: [Idr] A question on longest match Date: Fri, 04 Jun 2004 >11:44:43 -0400 > >In message , "john smith" writes: > > > > > > >Back then this idea was known as "FIB compression" and if you like you > > >can search the archives for a lot of discussion on the issue and quite > > >a bit of measurement done at that time. > > > > > > > It certainly is better than entring a "split brain" with NO_EXPORT :) > > >We're talking about two different things. Automatic aggregation of >the FIB is safe to do under all circumstances. Automatice aggregation >and reannouncement is not always safe. > > > > > > Or we are saying BGP is specifically meant only for vendors and > > >operators > > > > who can cater to such hardware? > > > > > > > > >Providers can aggregate better but it requires better coordination > > >among providers. > > > > > > > How has this got *anything* to do with coordination among providers? > > >If provider A has a aggregate and some customers are dual homed to >provider B, then provider B or downstream can't safely aggregate those >routes. If any of those dual homed customers loosed connection to A >and most providers rightfully send traffic for the A aggregate to A, >then those customers don't have backup through B. > >See 10 year old discussion on "hostile aggregation". > >The modern twist on this is that the "provider coordination" these >days can be as simple as adding a BGP community. We now have a BGP >communitity that can work across any number of AS crossings, the >NOPEER. The classic example where this is a problem is the >non-aggregation of Australian routes in the US and Europe. >Unfortunately the NOPEER isn't being used enough so you need to use >the "clue club" (as someone who has contributed a lot to operations >has called it, or was it the "clue bat") with the provider origination >the route. That too is a form of interprovider coordination, but not >one easily standardized. > >That's what PTOMANE and GROW are all about. Or a big part of it. > >In the case of 4/8, there were a very small number of more specific. >In all likelyhood these are only the ones that really needed to be >there (or at least most of them) so you shouldn't touch them. > > > > It is upto the IETF to make the providers cordinate. Eitherways if the >IETF > > thinks the idea makes *any sense* then they should take a step in that > > direction rather than say "too late". > > > > If people can build terabit routers which can switch millions of packets >and > > have a huge FIB, they can figure out ways to reduce the FIB size too. It >is > > a matter of what the "specs" say. > > > > Are specs *not* made for scalaibilty? To quote someone from another >list, is > > it not the job of the *specs* to say what is *techincally correct*? > > >Not to be rude but I chopped off the rest of your response. I >responded the first time off list because I didn't want to get into an >extended thread on this. > >You are not telling the IETF something that the IETF is not aware of >or hasn't thought about. If you want to see what the IETF WGs have >had to say about this topic, look in the archives. In particular you >want to look at the PTOMAINE and GROW WG, more PTOMAINE. _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jun 4 18:56:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25578 for ; Fri, 4 Jun 2004 18:56:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWNc6-0006hB-W2 for idr-archive@ietf.org; Fri, 04 Jun 2004 18:56:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWNb6-0006L9-00 for idr-archive@ietf.org; Fri, 04 Jun 2004 18:55:36 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BWNaK-0005gQ-00; Fri, 04 Jun 2004 18:54:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWNWz-0000YG-Hy; Fri, 04 Jun 2004 18:51:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWNIb-0004bu-U2 for idr@megatron.ietf.org; Fri, 04 Jun 2004 18:36:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24339 for ; Fri, 4 Jun 2004 18:36:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWNIa-00079a-Cj for idr@ietf.org; Fri, 04 Jun 2004 18:36:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWNHa-0006pg-00 for idr@ietf.org; Fri, 04 Jun 2004 18:35:27 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BWNGa-0006Cy-00 for idr@ietf.org; Fri, 04 Jun 2004 18:34:24 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i54MXmPC030403; Fri, 4 Jun 2004 15:33:48 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i54MXmCB030400; Fri, 4 Jun 2004 15:33:48 -0700 (PDT) From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16576.63692.283575.875164@roque-bsd.juniper.net> Date: Fri, 4 Jun 2004 15:33:48 -0700 To: qning@chiaro.com Subject: [Idr] Question about RFC 3107 Carrying label in bgp-4 In-Reply-To: <34B6386F843340459B22F59DFF7B12FF31917B@192-168-240-22.chiaro.com> References: <34B6386F843340459B22F59DFF7B12FF31917B@192-168-240-22.chiaro.com> X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid Content-Transfer-Encoding: 7bit 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit qning writes: > Hi, I will use 192.168.0.0/16 as an ip prefix, and 0x102031 as an > mpls label in the following questions. > RFC 3107 (Carrying Label Information in BGP-4) Section 3 states > 0x102031:192.168.0.0/16 can be advertised in a MP_REACH_NLRI. It > can be withdrawn by either a) a new route with a new label: > 0xB1B2B3:192.168.0.0/16 in MP_REACG_NLRI or b) > 0x800000:192.168.0.0/16 in a MP_UNREACH_NLRI. Not commenting on the spec... The implementations i'm aware of treat the IP prefix as the NLRI key for safi-4 and the label as a per nlri attribute. As such an update for a given IP prefix implicitly withdrawn the previously advertised label. Another area to be concerned in terms of interoperability is the fact that some implementations seem to consider a SAFI=1 update/withdrawl for the same prefix to update the safi=4 information... Not JunOS implementation, however... JunOS considers a safi=4 update and a safi=1 update to refer to different routing databases... You may want to verify some of these details if you are concerned w/ interoperability... Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jun 7 18:01:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26843 for ; Mon, 7 Jun 2004 18:01:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXSBR-0001X2-6I for idr-archive@ietf.org; Mon, 07 Jun 2004 18:01:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXS92-0000aF-00 for idr-archive@ietf.org; Mon, 07 Jun 2004 17:59:05 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXS7m-0007jz-01; Mon, 07 Jun 2004 17:57:47 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXS3k-0006xV-UL; Mon, 07 Jun 2004 17:53:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXRPt-0001Am-7Z; Mon, 07 Jun 2004 17:12:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXQY2-00040x-Qv for idr@megatron.ietf.org; Mon, 07 Jun 2004 16:16:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14439 for ; Mon, 7 Jun 2004 16:16:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXQY1-0005gQ-FN for idr@ietf.org; Mon, 07 Jun 2004 16:16:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXQVK-0004kl-00 for idr@ietf.org; Mon, 07 Jun 2004 16:13:58 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BXQRq-0002wl-00 for idr@ietf.org; Mon, 07 Jun 2004 16:10:23 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i57K9rBm034709 for ; Mon, 7 Jun 2004 13:09:53 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i57K9rJ29272 for ; Mon, 7 Jun 2004 13:09:53 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406072009.i57K9rJ29272@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <44815.1086638993.1@juniper.net> Date: Mon, 07 Jun 2004 13:09:53 -0700 From: Yakov Rekhter Subject: [Idr] revised draft 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, Please check if the attached reflects the comments received during the IDR WG Last Call. In the absence of any objections we'll submit it to the IESG Jun 14, 2004. Yakov. ------- Forwarded Message Date: Mon, 07 Jun 2004 15:42:12 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-idr-rfc1863-historic-00.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Reclassification of RFC 1863 to Historic Author(s) : P. Savola Filename : draft-ietf-idr-rfc1863-historic-00.txt Pages : 4 Date : 2004-6-7 This memo reclassifies RFC 1863, A BGP/IDRP Route Server alternative to a full mesh routing, to Historic status. This memo also Obsoletes RFC 1863. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc1863-historic-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 mess age. 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-rfc1863-historic-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-rfc1863-historic-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-7154337.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc1863-historic-00.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc1863-historic-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-7154337.I-D@ietf.org> - --OtherAccess-- - --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce - --NextPart-- ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 8 07:13:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18518 for ; Tue, 8 Jun 2004 07:13:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXeXp-0005ZO-I8 for idr-archive@ietf.org; Tue, 08 Jun 2004 07:13:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXeWe-0004oK-00 for idr-archive@ietf.org; Tue, 08 Jun 2004 07:12:17 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXeVU-0003RG-00; Tue, 08 Jun 2004 07:11:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXeO0-0007A4-7k; Tue, 08 Jun 2004 07:03:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXeK7-000683-Qe for idr@megatron.ietf.org; Tue, 08 Jun 2004 06:59:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17983 for ; Tue, 8 Jun 2004 06:59:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXeK5-0003Yp-7S for idr@ietf.org; Tue, 08 Jun 2004 06:59:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXeJ9-0002rx-00 for idr@ietf.org; Tue, 08 Jun 2004 06:58:20 -0400 Received: from web60705.mail.yahoo.com ([216.109.117.228]) by ietf-mx with smtp (Exim 4.12) id 1BXeIH-0001Xx-00 for idr@ietf.org; Tue, 08 Jun 2004 06:57:25 -0400 Message-ID: <20040608105657.20868.qmail@web60705.mail.yahoo.com> Received: from [202.144.106.188] by web60705.mail.yahoo.com via HTTP; Tue, 08 Jun 2004 06:56:57 EDT Date: Tue, 8 Jun 2004 06:56:57 -0400 (EDT) From: Tulip Rasputin To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Idr] Atomic Aggregate 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi, Section 5.1.6 (ATOMIC_AGGREGATE) of the draft-ietf-idr-bgp4-23.txt states that "If an aggregate excludes at least some of the AS numbers present in the AS_PATH of the routes that are aggregated as a result of dropping the AS_SET, the aggregated route, when advertised to the peer, SHOULD include the ATOMIC_AGGREGATE attribute." Now suppose a BGP speaker (in AS say XXX) has the following routes: [1] 128.1/16, AS Path Sequence 6000 6120 [2] 128.2/16, AS Path Seq 6000 This BGP speaker is configured to advertise an aggregate route of 128/8 to one of its EBGP Peer. If this BGP speaker advertises 128/8 with AS Path "XXX 6000", then IMO it should attach the ATOMIC_AGGREGATE path attribute, warning its peer that some of the AS numbers are not present in this AS Path. What would happen if it advertises 128/8 with AS Path Seq "XXX 6000" and AS Set "[6120]"? In this case its advertising all the AS Path information. Is it required to attach the ATOMIC_AGGREGATE path attribute in this case? I understand that it will attach the AGREGATOR path attribute in both the above cases to let others know who and where did the aggregation took place? Regards, Rasputin ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 8 08:45:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23193 for ; Tue, 8 Jun 2004 08:45:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXfzD-0001t4-MA for idr-archive@ietf.org; Tue, 08 Jun 2004 08:45:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXfyA-00016s-00 for idr-archive@ietf.org; Tue, 08 Jun 2004 08:44:46 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXfwz-0007aE-00; Tue, 08 Jun 2004 08:43:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXfng-0002dG-24; Tue, 08 Jun 2004 08:33:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXfiK-0000op-Hw for idr@megatron.ietf.org; Tue, 08 Jun 2004 08:28:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22527 for ; Tue, 8 Jun 2004 08:28:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXfiJ-00057P-OD for idr@ietf.org; Tue, 08 Jun 2004 08:28:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXfhS-0004PI-00 for idr@ietf.org; Tue, 08 Jun 2004 08:27:30 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BXfgA-00030l-00 for idr@ietf.org; Tue, 08 Jun 2004 08:26:10 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D31842D4848; Tue, 8 Jun 2004 08:25:39 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 41124-01-60; Tue, 8 Jun 2004 08:25:28 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 74A622D4814; Tue, 8 Jun 2004 08:25:28 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i58CPSr04258; Tue, 8 Jun 2004 08:25:28 -0400 (EDT) Date: Tue, 8 Jun 2004 08:25:28 -0400 From: Jeffrey Haas To: Tulip Rasputin Subject: Re: [Idr] Atomic Aggregate Message-ID: <20040608122528.GA4249@nexthop.com> References: <20040608105657.20868.qmail@web60705.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040608105657.20868.qmail@web60705.mail.yahoo.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, Jun 08, 2004 at 06:56:57AM -0400, Tulip Rasputin wrote: > What would happen if it advertises 128/8 with AS Path Seq "XXX 6000" and AS Set "[6120]"? In this > case its advertising all the AS Path information. Is it required to attach the ATOMIC_AGGREGATE > path attribute in this case? All of the AS's are present, even if not attached to their original sequences. Since BGP uses the presence of the AS, regardless of its type (sequence, set, etc) for loop detection, this is enough. ATOMIC_AGGREGATE doesn't need to be attached. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 8 10:03:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27566 for ; Tue, 8 Jun 2004 10:03:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXhCY-0005RF-U4 for idr-archive@ietf.org; Tue, 08 Jun 2004 10:03:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXhBV-0004cF-00 for idr-archive@ietf.org; Tue, 08 Jun 2004 10:02:37 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXhAN-000372-00; Tue, 08 Jun 2004 10:01:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXh4L-00005Y-Ck; Tue, 08 Jun 2004 09:55:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXgxm-0006yM-8n for idr@megatron.ietf.org; Tue, 08 Jun 2004 09:48:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26700 for ; Tue, 8 Jun 2004 09:48:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXgxl-0001hA-2c for idr@ietf.org; Tue, 08 Jun 2004 09:48:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXgwm-0000xQ-00 for idr@ietf.org; Tue, 08 Jun 2004 09:47:25 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BXgvb-0007H7-00 for idr@ietf.org; Tue, 08 Jun 2004 09:46:11 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id C99262D485D for ; Tue, 8 Jun 2004 09:45:41 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 43311-01-78 for ; Tue, 8 Jun 2004 09:45:30 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 653962D4814 for ; Tue, 8 Jun 2004 09:45:30 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i58DjUu04490 for idr@ietf.org; Tue, 8 Jun 2004 09:45:30 -0400 (EDT) Date: Tue, 8 Jun 2004 09:45:30 -0400 From: Jeffrey Haas To: idr@ietf.org Subject: Re: [Idr] revised draft Message-ID: <20040608134530.GE4415@nexthop.com> References: <200406072009.i57K9rJ29272@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406072009.i57K9rJ29272@merlot.juniper.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 All of my previous concerns were addressed. It looks good to me. On Mon, Jun 07, 2004 at 01:09:53PM -0700, Yakov Rekhter wrote: > Folks, > > Please check if the attached reflects the comments received during > the IDR WG Last Call. In the absence of any objections we'll submit it to > the IESG Jun 14, 2004. > > Yakov -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 8 13:17:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09602 for ; Tue, 8 Jun 2004 13:17:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXkEB-0005Sz-VH for idr-archive@ietf.org; Tue, 08 Jun 2004 13:17:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXkBe-0003di-00 for idr-archive@ietf.org; Tue, 08 Jun 2004 13:14:59 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXk85-00022F-00; Tue, 08 Jun 2004 13:11:17 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXk86-0003iI-Hf; Tue, 08 Jun 2004 13:11:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXjy6-0005zF-HQ; Tue, 08 Jun 2004 13:00:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXjkG-00009O-PF for idr@megatron.ietf.org; Tue, 08 Jun 2004 12:46:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07436 for ; Tue, 8 Jun 2004 12:46:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXjkF-0004yA-PD for idr@ietf.org; Tue, 08 Jun 2004 12:46:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXjjK-0004AW-00 for idr@ietf.org; Tue, 08 Jun 2004 12:45:43 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BXjiT-0002rL-00 for idr@ietf.org; Tue, 08 Jun 2004 12:44:49 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i58GiIBm043701 for ; Tue, 8 Jun 2004 09:44:18 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i58GiIJ81595 for ; Tue, 8 Jun 2004 09:44:18 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406081644.i58GiIJ81595@merlot.juniper.net> To: idr@ietf.org Subject: [Idr] extending deadline for pref-limit comments MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29098.1086713058.1@juniper.net> Date: Tue, 08 Jun 2004 09:44:18 -0700 From: Yakov Rekhter 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, The deadline for comments on the attached is over. The following summarizes the feedback received. Please check for correctness. In the summary I assume that (a) all the authors of a particular proposal are in favor of accepting this proposal as WG item (if this is incorrect, please let me know asap), and (b) all the authors of both of the proposals are in favor of accepting signalled prefix limit as an IDR WG item (if this is incorrect, please let me know asap). Accept Signalled Pref-limit as work item: Yes: Vincent Gillet Jeffrey Haas Enke Chen Eric Rosen Curtis Villamizar Sun Tao Gerald Ash Srikanth Chavali (author) Vasile Radoaca (author) Mo Miri (author) Luyuan Fan (author) Susan Hares (author) Keyur Patel (author) Chandra Appanna (author) John Scudder (author) No: Vivek Menezes Pekka Savola Parantap Lahiri Tony Li Enrico Salazar Pedro Roque Marques Accept draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document Yes: Vincent Gillet Gerald Ash Srikanth Chavali (author) Vasile Radoaca (author) Mo Miri (author) Luyuan Fan (author) Susan Hares (author) Accept draft-keyur-prefixlimit-orf-00.txt as an IDR WG document Yes: Enke Chen Eric Rosen Sun Tao Keyur Patel (author) Chandra Appanna (author) John Scudder (author) ------- Forwarded Message Date: Mon, 24 May 2004 08:07:04 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] extending deadline for pref-limit comments Folks, As requested by authors of both of the proposals on the table, we are going to extend the deadline for comments for another 2 weeks (until Jun 7). To remind, the questions on the table are the following: 1. whether to take signalled prefix limit as a WG item 2. whether to accept draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document 3. whether to accept draft-keyur-prefixlimit-orf-00.txt as an IDR WG document In your e-mails please *clearly* indicate your preferences. Providing rationale for your preferences would be extremely useful as well. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 8 13:45:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12166 for ; Tue, 8 Jun 2004 13:45:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXkfQ-0002eD-GV for idr-archive@ietf.org; Tue, 08 Jun 2004 13:45:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXkdT-0001NZ-00 for idr-archive@ietf.org; Tue, 08 Jun 2004 13:43:43 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXkbl-0007VY-00; Tue, 08 Jun 2004 13:41:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXkSQ-0007AR-WF; Tue, 08 Jun 2004 13:32:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXkJT-0004Up-Ee for idr@megatron.ietf.org; Tue, 08 Jun 2004 13:23:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10250 for ; Tue, 8 Jun 2004 13:23:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXkJS-00029W-FV for idr@ietf.org; Tue, 08 Jun 2004 13:23:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXkHu-0000ZR-00 for idr@ietf.org; Tue, 08 Jun 2004 13:21:26 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BXkGI-0006Vy-00 for idr@ietf.org; Tue, 08 Jun 2004 13:19:46 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i58HJGBm046475; Tue, 8 Jun 2004 10:19:16 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i58HJGJ94374; Tue, 8 Jun 2004 10:19:16 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406081719.i58HJGJ94374@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <35116.1086715156.1@juniper.net> Date: Tue, 08 Jun 2004 10:19:16 -0700 From: Yakov Rekhter Cc: skh@nexthop.com Subject: [Idr] IDR WG meeting agenda 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, If you'd like some time on the agenda in San Diego please let me and Sue know (the sooner the better). Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 8 19:08:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06598 for ; Tue, 8 Jun 2004 19:08:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXphc-0004X9-9k for idr-archive@ietf.org; Tue, 08 Jun 2004 19:08:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXpY6-0001Zb-00 for idr-archive@ietf.org; Tue, 08 Jun 2004 18:58:30 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXpLa-0006GY-00; Tue, 08 Jun 2004 18:45:34 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXpLb-0002eh-2x; Tue, 08 Jun 2004 18:45:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXpCH-0006hT-ED; Tue, 08 Jun 2004 18:35:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXoI6-0004MD-Fl for idr@megatron.ietf.org; Tue, 08 Jun 2004 17:37:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25459 for ; Tue, 8 Jun 2004 17:37:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXoI5-0001qh-0L for idr@ietf.org; Tue, 08 Jun 2004 17:37:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXoFh-0000fn-00 for idr@ietf.org; Tue, 08 Jun 2004 17:35:26 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BXoCs-0006eO-00 for idr@ietf.org; Tue, 08 Jun 2004 17:32:30 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i58LW0Bm047406 for ; Tue, 8 Jun 2004 14:32:00 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i58LW0J33204 for ; Tue, 8 Jun 2004 14:32:00 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406082132.i58LW0J33204@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <82701.1086730320.1@juniper.net> Date: Tue, 08 Jun 2004 14:32:00 -0700 From: Yakov Rekhter Subject: [Idr] pref-limit comments 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, In the list I sent earlier today I missed one person. Here is the updated list: Accept Signalled Pref-limit as work item: Yes: Vincent Gillet Jeffrey Haas Enke Chen Eric Rosen Curtis Villamizar Sun Tao Gerald Ash Robert Raszuk Srikanth Chavali (author) Vasile Radoaca (author) Mo Miri (author) Luyuan Fan (author) Susan Hares (author) Keyur Patel (author) Chandra Appanna (author) John Scudder (author) No: Vivek Menezes Pekka Savola Parantap Lahiri Tony Li Enrico Salazar Pedro Roque Marques Accept draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document Yes: Vincent Gillet Gerald Ash Srikanth Chavali (author) Vasile Radoaca (author) Mo Miri (author) Luyuan Fan (author) Susan Hares (author) Accept draft-keyur-prefixlimit-orf-00.txt as an IDR WG document Yes: Enke Chen Eric Rosen Sun Tao Robert Raszuk Keyur Patel (author) Chandra Appanna (author) John Scudder (author) _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 8 20:16:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12939 for ; Tue, 8 Jun 2004 20:16:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXqlF-0005sq-JX for idr-archive@ietf.org; Tue, 08 Jun 2004 20:16:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXqk3-0004zL-00 for idr-archive@ietf.org; Tue, 08 Jun 2004 20:14:56 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXqiy-0003Ih-00; Tue, 08 Jun 2004 20:13:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXqUd-0004G6-Nj; Tue, 08 Jun 2004 19:58:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXqI9-0006js-Rj for idr@megatron.ietf.org; Tue, 08 Jun 2004 19:46:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10076 for ; Tue, 8 Jun 2004 19:46:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXqI8-0006Nl-3l for idr@ietf.org; Tue, 08 Jun 2004 19:46:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXqGv-0005Tw-00 for idr@ietf.org; Tue, 08 Jun 2004 19:44:50 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BXqFe-0003mj-00 for idr@ietf.org; Tue, 08 Jun 2004 19:43:30 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i58Nh1Bm047783 for ; Tue, 8 Jun 2004 16:43:01 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i58Nh1J53611 for ; Tue, 8 Jun 2004 16:43:01 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406082343.i58Nh1J53611@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7093.1086738181.1@juniper.net> Date: Tue, 08 Jun 2004 16:43:01 -0700 From: Yakov Rekhter Subject: [Idr] pref-limit - one more update 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, One more correction - attached is the updated list. Yakov. ----------------------------------------------------------------- Accept Signalled Pref-limit as work item: Yes: Vincent Gillet Jeffrey Haas Enke Chen Eric Rosen Curtis Villamizar Sun Tao Gerald Ash Robert Raszuk Srikanth Chavali (author) Vasile Radoaca (author) Mo Miri (author) Luyuan Fan (author) Susan Hares (author) Keyur Patel (author) Chandra Appanna (author) John Scudder (author) No: Vivek Menezes Pekka Savola Parantap Lahiri Tony Li Enrico Salazar Pedro Roque Marques Kurt Erik Lindqvist Accept draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document Yes: Vincent Gillet Gerald Ash Srikanth Chavali (author) Vasile Radoaca (author) Mo Miri (author) Luyuan Fan (author) Susan Hares (author) Accept draft-keyur-prefixlimit-orf-00.txt as an IDR WG document Yes: Enke Chen Eric Rosen Sun Tao Robert Raszuk Keyur Patel (author) Chandra Appanna (author) John Scudder (author) _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 8 21:57:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18175 for ; Tue, 8 Jun 2004 21:57:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXsKu-0007So-Vn for idr-archive@ietf.org; Tue, 08 Jun 2004 21:57:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXsJq-0006ZV-00 for idr-archive@ietf.org; Tue, 08 Jun 2004 21:55:58 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXsIW-0004rn-00; Tue, 08 Jun 2004 21:54:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXsC0-0004Df-Ej; Tue, 08 Jun 2004 21:47:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXs5P-0001Bk-KN for idr@megatron.ietf.org; Tue, 08 Jun 2004 21:41:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17502 for ; Tue, 8 Jun 2004 21:41:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXs5N-0001jz-M0 for idr@ietf.org; Tue, 08 Jun 2004 21:41:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXs4I-0000sc-00 for idr@ietf.org; Tue, 08 Jun 2004 21:39:55 -0400 Received: from relay.pair.com ([209.68.1.20]) by ietf-mx with smtp (Exim 4.12) id 1BXs3O-0007jl-00 for idr@ietf.org; Tue, 08 Jun 2004 21:38:59 -0400 Received: (qmail 42117 invoked from network); 9 Jun 2004 01:38:54 -0000 Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay.pair.com with SMTP; 9 Jun 2004 01:38:54 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id i591aiGU057806; Tue, 8 Jun 2004 21:36:44 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200406090136.i591aiGU057806@workhorse.faster-light.net> To: Yakov Rekhter Subject: Re: [Idr] pref-limit - one more update In-reply-to: Your message of "Tue, 08 Jun 2004 16:43:01 PDT." <200406082343.i58Nh1J53611@merlot.juniper.net> Date: Tue, 08 Jun 2004 21:36:44 -0400 From: Curtis Villamizar Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <200406082343.i58Nh1J53611@merlot.juniper.net> Yakov Rekhter writes: > > Folks, > > One more correction - attached is the updated list. > > Yakov. Yakov, Consensus looks a bit too rough. In the old days we used to wait for running code in this situation and factor that in. Just a suggestion. Saves a lot of arguing. Curtis ----------------------------------------------------------------- Accept Signalled Pref-limit as work item: Yes: Vincent Gillet Jeffrey Haas Enke Chen Eric Rosen Curtis Villamizar Sun Tao Gerald Ash Robert Raszuk Srikanth Chavali (author) Vasile Radoaca (author) Mo Miri (author) Luyuan Fan (author) Susan Hares (author) Keyur Patel (author) Chandra Appanna (author) John Scudder (author) No: Vivek Menezes Pekka Savola Parantap Lahiri Tony Li Enrico Salazar Pedro Roque Marques Kurt Erik Lindqvist Accept draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document Yes: Vincent Gillet Gerald Ash Srikanth Chavali (author) Vasile Radoaca (author) Mo Miri (author) Luyuan Fan (author) Susan Hares (author) Accept draft-keyur-prefixlimit-orf-00.txt as an IDR WG document Yes: Enke Chen Eric Rosen Sun Tao Robert Raszuk Keyur Patel (author) Chandra Appanna (author) John Scudder (author) _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 8 23:45:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24108 for ; Tue, 8 Jun 2004 23:45:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXu21-0005zb-Vy for idr-archive@ietf.org; Tue, 08 Jun 2004 23:45:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXu0i-0004zx-00 for idr-archive@ietf.org; Tue, 08 Jun 2004 23:44:21 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXtyx-0003Cv-00; Tue, 08 Jun 2004 23:42:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXtmF-0003dO-HR; Tue, 08 Jun 2004 23:29:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXtSi-0006b1-G4 for idr@megatron.ietf.org; Tue, 08 Jun 2004 23:09:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22254 for ; Tue, 8 Jun 2004 23:08:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXtSQ-0004GC-QT for idr@ietf.org; Tue, 08 Jun 2004 23:08:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXtPw-00035y-00 for idr@ietf.org; Tue, 08 Jun 2004 23:06:22 -0400 Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1BXtNk-0000cE-00 for idr@ietf.org; Tue, 08 Jun 2004 23:04:04 -0400 Received: from [192.168.1.3] (c-24-5-4-40.client.comcast.net[24.5.4.40]) by comcast.net (sccrmhc13) with SMTP id <200406090303300160086197e> (Authid: li.tony); Wed, 9 Jun 2004 03:03:31 +0000 In-Reply-To: <200406090136.i591aiGU057806@workhorse.faster-light.net> References: <200406090136.i591aiGU057806@workhorse.faster-light.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <97CD7530-B9C1-11D8-ACAB-000A95D1475E@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] pref-limit - one more update Date: Tue, 8 Jun 2004 20:03:33 -0700 To: curtis@faster-light.net X-Mailer: Apple Mail (2.618) Content-Transfer-Encoding: 7bit Cc: Yakov Rekhter , 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I agree that it's very rough, especially when you factor out the authors. So, a couple of other suggestions: a) consult the "routing directorate" or b) consult the AD's "subject area expert". Tony On Jun 8, 2004, at 6:36 PM, Curtis Villamizar wrote: > > In message <200406082343.i58Nh1J53611@merlot.juniper.net> > Yakov Rekhter writes: >> >> Folks, >> >> One more correction - attached is the updated list. >> >> Yakov. > > > Yakov, > > Consensus looks a bit too rough. In the old days we used to wait for > running code in this situation and factor that in. Just a suggestion. > Saves a lot of arguing. > > Curtis > > > > ----------------------------------------------------------------- > Accept Signalled Pref-limit as work item: > > Yes: > Vincent Gillet > Jeffrey Haas > Enke Chen > Eric Rosen > Curtis Villamizar > Sun Tao > Gerald Ash > Robert Raszuk > Srikanth Chavali (author) > Vasile Radoaca (author) > Mo Miri (author) > Luyuan Fan (author) > Susan Hares (author) > Keyur Patel (author) > Chandra Appanna (author) > John Scudder (author) > > No: > Vivek Menezes > Pekka Savola > Parantap Lahiri > Tony Li > Enrico Salazar > Pedro Roque Marques > Kurt Erik Lindqvist > > Accept draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document Yes: > > Vincent Gillet > Gerald Ash > Srikanth Chavali (author) > Vasile Radoaca (author) > Mo Miri (author) > Luyuan Fan (author) > Susan Hares (author) > > Accept draft-keyur-prefixlimit-orf-00.txt as an IDR WG document Yes: > > Enke Chen > Eric Rosen > Sun Tao > Robert Raszuk > Keyur Patel (author) > Chandra Appanna (author) > John Scudder (author) > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jun 9 00:20:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25660 for ; Wed, 9 Jun 2004 00:20:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXuZX-00031a-Qx for idr-archive@ietf.org; Wed, 09 Jun 2004 00:20:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXuYM-0002BC-00 for idr-archive@ietf.org; Wed, 09 Jun 2004 00:19:06 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXuXF-0000WN-00; Wed, 09 Jun 2004 00:17:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXu4G-0003Qd-DB; Tue, 08 Jun 2004 23:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXtsx-0004rr-1p for idr@megatron.ietf.org; Tue, 08 Jun 2004 23:36:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23553 for ; Tue, 8 Jun 2004 23:36:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXtst-0005ut-Nh for idr@ietf.org; Tue, 08 Jun 2004 23:36:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXtro-00053u-00 for idr@ietf.org; Tue, 08 Jun 2004 23:35:09 -0400 Received: from relay.pair.com ([209.68.1.20]) by ietf-mx with smtp (Exim 4.12) id 1BXtpU-0003gO-00 for idr@ietf.org; Tue, 08 Jun 2004 23:32:44 -0400 Received: (qmail 77942 invoked from network); 9 Jun 2004 03:32:45 -0000 Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay.pair.com with SMTP; 9 Jun 2004 03:32:45 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id i593UYXp060258; Tue, 8 Jun 2004 23:30:34 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200406090330.i593UYXp060258@workhorse.faster-light.net> To: Tony Li Subject: Re: [Idr] pref-limit - one more update In-reply-to: Your message of "Tue, 08 Jun 2004 20:03:33 PDT." <97CD7530-B9C1-11D8-ACAB-000A95D1475E@tony.li> Date: Tue, 08 Jun 2004 23:30:33 -0400 From: Curtis Villamizar Cc: Yakov Rekhter , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <97CD7530-B9C1-11D8-ACAB-000A95D1475E@tony.li> Tony Li writes: > > > I agree that it's very rough, especially when you factor out the > authors. > > So, a couple of other suggestions: a) consult the "routing > directorate" or b) consult the AD's "subject area expert". > > Tony Tony, Think about how that statement would have sounded 10 years ago. The answer would have been an immediate "go write some code and come back here when/if someone deploys it". If this is provider driven even if driven by a subset of providers, it won't matter that the IETF has to say the implementations will happen. If this is a big yawn to most providers, it also won't matter what the IETF has to say because the implementations if they happen at all won't be deployed. Curtis > On Jun 8, 2004, at 6:36 PM, Curtis Villamizar wrote: > > > > > In message <200406082343.i58Nh1J53611@merlot.juniper.net> > > Yakov Rekhter writes: > >> > >> Folks, > >> > >> One more correction - attached is the updated list. > >> > >> Yakov. > > > > > > Yakov, > > > > Consensus looks a bit too rough. In the old days we used to wait for > > running code in this situation and factor that in. Just a suggestion. > > Saves a lot of arguing. > > > > Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jun 9 17:00:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21073 for ; Wed, 9 Jun 2004 17:00:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYABe-0001yP-Dw for idr-archive@ietf.org; Wed, 09 Jun 2004 17:00:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYA1H-0006Xl-00 for idr-archive@ietf.org; Wed, 09 Jun 2004 16:50:01 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BY9pt-0002xe-00; Wed, 09 Jun 2004 16:38:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY8xU-0000rH-FB; Wed, 09 Jun 2004 15:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY8qC-0006fr-6n; Wed, 09 Jun 2004 15:34:28 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13066; Wed, 9 Jun 2004 15:34:20 -0400 (EDT) Message-Id: <200406091934.PAA13066@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 09 Jun 2004 15:34:20 -0400 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-restart-10.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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Graceful Restart Mechanism for BGP Author(s) : S. Sangli, et al. Filename : draft-ietf-idr-restart-10.txt Pages : 11 Date : 2004-6-9 This document proposes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed 'Graceful Restart Capability', is defined which would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP transport reset. The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-10.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-restart-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-restart-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-9152911.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-restart-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-restart-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-9152911.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- From idr-bounces@ietf.org Mon Jun 14 12:35:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13596 for ; Mon, 14 Jun 2004 12:35:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZuQj-00068I-3H for idr-archive@ietf.org; Mon, 14 Jun 2004 12:35:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZuPi-0005n8-00 for idr-archive@ietf.org; Mon, 14 Jun 2004 12:34:26 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BZuOt-0005JL-00; Mon, 14 Jun 2004 12:33:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZtu2-0000ID-IP; Mon, 14 Jun 2004 12:01:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZYvq-00020Q-SF for idr@megatron.ietf.org; Sun, 13 Jun 2004 13:38:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24399 for ; Sun, 13 Jun 2004 13:38:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZYvp-0002Lg-Rk for idr@ietf.org; Sun, 13 Jun 2004 13:38:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZYux-00028S-00 for idr@ietf.org; Sun, 13 Jun 2004 13:37:16 -0400 Received: from av7-2-sn4.m-sp.skanova.net ([81.228.10.109]) by ietf-mx with esmtp (Exim 4.12) id 1BZYuG-0001nZ-00 for idr@ietf.org; Sun, 13 Jun 2004 13:36:32 -0400 Received: by av7-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 7DDD837EDA; Sun, 13 Jun 2004 19:36:01 +0200 (CEST) Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av7-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 6EA6337E4F for ; Sun, 13 Jun 2004 19:36:01 +0200 (CEST) Received: from pi.se (h178n2fls307o1033.telia.com [81.226.61.178]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 56CD837E46 for ; Sun, 13 Jun 2004 19:36:01 +0200 (CEST) Message-ID: <40CC9072.5090107@pi.se> Date: Sun, 13 Jun 2004 19:35:46 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 14 Jun 2004 12:01:41 -0400 Subject: [Idr] MPLS2004 Conference Call for Presentations 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit The MPLS2004 Conference will be held in Washington DC, from October 17 to October 19, 2004. This year's conference will include, but will not be limited, to the following topics: - Network Consolidation and Service Convergence - Traffic engineering and QoS - MPLS network operation, administration, and maintenance - OSS Systems for MPLS-based networks - MPLS Multicast - Service Provisioning - MPLS in multi-AS networks - L2VPNs (pseudo-wire emulation, VPWS, VPLS, and others) - L3VPNs (BGP/MPLS, IPSec interworking, virtual routers, and others) - Voice, video, and real-time services over MPLS networks - Scalability and performance of MPLS protocols and networks - Network processor architectures for next generation MPLS networks - MPLS certification, verification, and conformance testing - MPLS network security - MPLS reliability and survivability (fast reroute, graceful restart, and restoration techniques) - IP Optical Integration - Multilayer control, management, and optimization - MPLS deployment case studies: Service Provider operational experience The Program Committee for MPLS2004 is soliciting presentation proposals for this conference. If you wish to propose a particular topic for consideration, please send a one page summary, including speaker's name, affiliation, and contact information to the Technical Program Committee at: MPLS2004-CFP@isocore.com All proposals must be received by June 18, 2004. See http://www.mpls2004.com for more details. The program committee is looking for original and unpublished work to continue the tradition of addressing cutting-edge topics that was initiated by this conference in 1998. Presentations from the vendor, service provider, research, and user communities covering technology evolution and operational experience are solicited. -- Loa Andersson mobile +46 739 81 21 64 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jun 16 12:57:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20561 for ; Wed, 16 Jun 2004 12:57:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BadjE-00012I-Nv for idr-archive@ietf.org; Wed, 16 Jun 2004 12:57:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BadNp-00059f-00 for idr-archive@ietf.org; Wed, 16 Jun 2004 12:35:30 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bad1w-0001Lw-00; Wed, 16 Jun 2004 12:12:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BacWB-0000pJ-Uh; Wed, 16 Jun 2004 11:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BacLX-00046G-TA for idr@megatron.ietf.org; Wed, 16 Jun 2004 11:29:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08763 for ; Wed, 16 Jun 2004 11:29:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BacLT-0001s0-UU for idr@ietf.org; Wed, 16 Jun 2004 11:29:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BabaS-00025m-00 for idr@ietf.org; Wed, 16 Jun 2004 10:40:25 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BaahC-0001Xl-00; Wed, 16 Jun 2004 09:43:18 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BaZoh-0001Jp-38; Wed, 16 Jun 2004 08:46:59 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i5GCjA957401; Wed, 16 Jun 2004 05:45:10 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i5GCj4J76396; Wed, 16 Jun 2004 05:45:04 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406161245.i5GCj4J76396@merlot.juniper.net> To: zinin@psg.com, fenner@research.att.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12695.1087389904.1@juniper.net> Date: Wed, 16 Jun 2004 05:45:04 -0700 From: Yakov Rekhter Cc: skh@nexthop.com, idr@ietf.org, iesg-secretary@ietf.org, yakov@juniper.net Subject: [Idr] rfc1863 to historic 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Alex and Bill, The IDR WG would like to ask the IESG to publish draft-ietf-idr-rfc1863-historic-00.txt as an Informational RFC. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 17 12:35:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17169 for ; Thu, 17 Jun 2004 12:35:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BazrZ-0002MA-Pk for idr-archive@ietf.org; Thu, 17 Jun 2004 12:35:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BazjH-0000TZ-00 for idr-archive@ietf.org; Thu, 17 Jun 2004 12:27:08 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bazf3-0006q6-00; Thu, 17 Jun 2004 12:22:45 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BazY9-00041s-3f; Thu, 17 Jun 2004 12:15:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Baymz-0005p0-Qp; Thu, 17 Jun 2004 11:26:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BayfA-0003CU-SP; Thu, 17 Jun 2004 11:18:48 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09293; Thu, 17 Jun 2004 11:18:46 -0400 (EDT) Message-Id: <200406171518.LAA09293@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 17 Jun 2004 11:18:46 -0400 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-24.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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : A Border Gateway Protocol 4 (BGP-4) Author(s) : Y. Rekhter, S. Hares Filename : draft-ietf-idr-bgp4-24.txt Pages : 99 Date : 2004-6-17 The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASs) that reachability information traverses. This information is sufficient to construct a graph of AS connectivity for this reachability from which routing loops may be pruned and some policy decisions at the AS level may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network 'class' within BGP. BGP-4 also introduces mechanisms which allow aggregation of routes, including aggregation of AS paths. Routing information exchanged via BGP supports only the destination- based forwarding paradigm, which assumes that a router forwards a packet based solely on the destination address carried in the IP header of the packet. This, in turn, reflects the set of policy decisions that can (and can not) be enforced using BGP. BGP can support only the policies conforming to the destination-based forwarding paradigm. This specification covers only the exchange of IP version 4 network reachability information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-24.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-bgp4-24.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-bgp4-24.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-17113646.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-24.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-24.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-17113646.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- From idr-bounces@ietf.org Thu Jun 17 15:09:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05666 for ; Thu, 17 Jun 2004 15:09:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb2G6-0004Yn-JV for idr-archive@ietf.org; Thu, 17 Jun 2004 15:09:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb2Ex-0004CJ-00 for idr-archive@ietf.org; Thu, 17 Jun 2004 15:08:00 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bb2EA-0003oY-00; Thu, 17 Jun 2004 15:07:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb1uI-0003aC-1E; Thu, 17 Jun 2004 14:46:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb1oC-000089-TA for idr@megatron.ietf.org; Thu, 17 Jun 2004 14:40:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03477 for ; Thu, 17 Jun 2004 14:40:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb1oB-00032V-D4 for idr@ietf.org; Thu, 17 Jun 2004 14:40:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb1mf-0002MD-00 for idr@ietf.org; Thu, 17 Jun 2004 14:38:46 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1Bb1ki-0001f3-00 for idr@ietf.org; Thu, 17 Jun 2004 14:36:44 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i5HIaEBm092031 for ; Thu, 17 Jun 2004 11:36:14 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i5HIaEJ68379 for ; Thu, 17 Jun 2004 11:36:14 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406171836.i5HIaEJ68379@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <90385.1087497374.1@juniper.net> Date: Thu, 17 Jun 2004 11:36:14 -0700 From: Yakov Rekhter Subject: [Idr] WG Last Call on BGP Graceful Restart 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, This is to start the WG Last Call on advancing draft-ietf-idr-restart-10.txt to a Proposed Standard. Since the the previous version of this document already went through the WG Last Call, the main focus of this Last Call is the new text on Finite State Machine. The Last Call ends July 1, 2004. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jun 18 05:48:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09983 for ; Fri, 18 Jun 2004 05:48:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbFzC-00070i-2k for idr-archive@ietf.org; Fri, 18 Jun 2004 05:48:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbFyD-0006cf-00 for idr-archive@ietf.org; Fri, 18 Jun 2004 05:47:38 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BbFxF-0005ut-00; Fri, 18 Jun 2004 05:46:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbFrE-0000Wt-6L; Fri, 18 Jun 2004 05:40:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbFjm-0007IB-ES for idr@megatron.ietf.org; Fri, 18 Jun 2004 05:32:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09186 for ; Fri, 18 Jun 2004 05:32:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbFjg-000147-97 for idr@ietf.org; Fri, 18 Jun 2004 05:32:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbFig-0000iJ-00 for idr@ietf.org; Fri, 18 Jun 2004 05:31:35 -0400 Received: from web25306.mail.ukl.yahoo.com ([217.12.10.78]) by ietf-mx with smtp (Exim 4.12) id 1BbFhc-00002B-00 for idr@ietf.org; Fri, 18 Jun 2004 05:30:28 -0400 Message-ID: <20040618092959.60294.qmail@web25306.mail.ukl.yahoo.com> Received: from [202.144.106.188] by web25306.mail.ukl.yahoo.com via HTTP; Fri, 18 Jun 2004 10:29:59 BST Date: Fri, 18 Jun 2004 10:29:59 +0100 (BST) From: =?iso-8859-1?q?John=20Smith?= To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Idr] Loc-Rib and Adj-Rib-In 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Hi, Consider an instance where BGP is redistributing OSPF routes in it. BGP runs its decision process and finds that these are the best routes and that it needs to announce them to its peers. From a purist's language, will these routes now be placed in the "Loc-Rib" ? The routes that we receive from our peers are placed in the "Adj-Rib-In". What about the routes that are redistributed (static/RIP/ISIS/OSPF/etc) in BGP? Thanks, Smith ___________________________________________________________ALL-NEW Yahoo! Messenger - sooooo many all-new ways to express yourself http://uk.messenger.yahoo.com _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jun 18 11:24:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29987 for ; Fri, 18 Jun 2004 11:24:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbLEi-0001m6-1i for idr-archive@ietf.org; Fri, 18 Jun 2004 11:25:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbLDl-0001PM-00 for idr-archive@ietf.org; Fri, 18 Jun 2004 11:24:03 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BbLDQ-00012v-00; Fri, 18 Jun 2004 11:23:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbL62-0007jY-PZ; Fri, 18 Jun 2004 11:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbL24-0006Tg-7h for idr@megatron.ietf.org; Fri, 18 Jun 2004 11:11:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29500 for ; Fri, 18 Jun 2004 11:11:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbL23-0004gY-Bd for idr@ietf.org; Fri, 18 Jun 2004 11:11:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbL15-0004Ja-00 for idr@ietf.org; Fri, 18 Jun 2004 11:10:56 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BbL08-0003bN-00 for idr@ietf.org; Fri, 18 Jun 2004 11:09:56 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i5IF9Q970437 for ; Fri, 18 Jun 2004 08:09:26 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i5IF9LJ25180 for ; Fri, 18 Jun 2004 08:09:21 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406181509.i5IF9LJ25180@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <63475.1087571361.1@juniper.net> Date: Fri, 18 Jun 2004 08:09:21 -0700 From: Yakov Rekhter Subject: [Idr] draft-ietf-idr-bgp4-24.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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, In response to the comments received during the IESG Last Call here is the list of changes: 1. Added missing text to 5.1.2 (see my e-mail on Thu, 03 Jun 2004 06:50:19 PDT). 2. Added new text to the Security Consideration section (see my e-mail on Mon, 24 May 2004 07:32:55 PDT) 3. Fix text in 9.1.4 (see e-mail from Andrew Lange on Mon, 23 Feb 2004 09:22:37 PST) 4. Replace normative text with non-normative text in Appendix F (see my e-mail on Sun, 22 Feb 2004 11:56:49 PST) 5. Make all references to events as "Event NN" (in the -23 version some events have been referenced as "Event NN" while others as "EventNN"). Care was taken to avoid splitting "Event NN" across multiple lines. Yakov. ------- Forwarded Message Date: Thu, 17 Jun 2004 11:18:46 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-24.txt - --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 : A Border Gateway Protocol 4 (BGP-4) Author(s) : Y. Rekhter, S. Hares Filename : draft-ietf-idr-bgp4-24.txt Pages : 99 Date : 2004-6-17 The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protoco l. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASs) that reachability information traverses. This information is sufficient to construct a graph of AS connectivity for this reachability from which routing loops may be pruned and some policy decisions at the AS level may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network 'class' within BGP. BGP-4 also introduces mechanisms which allow aggregation of routes, including aggregation of AS paths. Routing information exchanged via BGP supports only the destination- based forwarding paradigm, which assumes that a router forwards a packet based solely on the destination address carried in the IP header of the packet. This, in turn, reflects the set of policy decisions that can (and can not) be enforced using BGP. BGP can support only the policies conforming to the destination-based forwarding paradigm. This specification covers only the exchange of IP version 4 network reachability information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-24.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 mess age. 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-bgp4-24.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-bgp4-24.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-17113646.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-24.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-24.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-17113646.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-- ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jun 21 15:36:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20538 for ; Mon, 21 Jun 2004 15:36:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcUaU-0006nZ-1M for idr-archive@ietf.org; Mon, 21 Jun 2004 15:36:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcUZV-0006S4-00 for idr-archive@ietf.org; Mon, 21 Jun 2004 15:35:14 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BcUYG-0005qu-00; Mon, 21 Jun 2004 15:33:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcUMS-0007lB-L5; Mon, 21 Jun 2004 15:21:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcSQH-0003L0-4f for idr@megatron.ietf.org; Mon, 21 Jun 2004 13:17:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07015 for ; Mon, 21 Jun 2004 13:17:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcSQG-0006n8-38 for idr@ietf.org; Mon, 21 Jun 2004 13:17:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcSBl-00040g-00 for idr@ietf.org; Mon, 21 Jun 2004 13:02:34 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BcRky-00004m-00 for idr@ietf.org; Mon, 21 Jun 2004 12:34:52 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9A6FE2D4849; Mon, 21 Jun 2004 12:34:17 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 59334-03-55; Mon, 21 Jun 2004 12:34:15 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D3B952D4923; Mon, 21 Jun 2004 12:32:17 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i5LGWH614550; Mon, 21 Jun 2004 12:32:17 -0400 (EDT) Date: Mon, 21 Jun 2004 12:32:17 -0400 From: Jeffrey Haas To: John Smith Subject: Re: [Idr] Loc-Rib and Adj-Rib-In Message-ID: <20040621163217.GC12532@nexthop.com> References: <20040618092959.60294.qmail@web25306.mail.ukl.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040618092959.60294.qmail@web25306.mail.ukl.yahoo.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, Jun 18, 2004 at 10:29:59AM +0100, John Smith wrote: > Consider an instance where BGP is redistributing OSPF routes in it. BGP runs its decision > process and finds that these are the best routes and that it needs to announce them to > its peers. From a purist's language, will these routes now be placed in the "Loc-Rib" ? > > The routes that we receive from our peers are placed in the "Adj-Rib-In". What about the > routes that are redistributed (static/RIP/ISIS/OSPF/etc) in BGP? It is intentionally hand-waved in the specification. The closest reference you will find to such a thing (from draft -23): All routes in the Loc-RIB are processed into Adj-RIBs-Out according to configured policy. This policy MAY exclude a route in the Loc-RIB from being installed in a particular Adj-RIB-Out. A route SHALL NOT be installed in the Adj-Rib-Out unless the destination and NEXT_HOP described by this route may be forwarded appropriately by the Routing Table. If a route in Loc-RIB is excluded from a particular Adj-RIB- Out the previously advertised route in that Adj-RIB-Out MUST be with- drawn from service by means of an UPDATE message (see 9.2). IMO, this would imply that a redistributed route enters directly into the Adj-Rib-Out of a peer potentially in preference to the best selected bgp route. >From the BGP MIB standpoint, just because a route is the best bgp route doesn't mean we expect to see it in the adj-rib-out. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 22 13:24:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01065 for ; Tue, 22 Jun 2004 13:24:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcp0w-0006A4-Sz for idr-archive@ietf.org; Tue, 22 Jun 2004 13:24:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcnSS-0007jN-00 for idr-archive@ietf.org; Tue, 22 Jun 2004 11:45:14 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BclUa-0001c6-00; Tue, 22 Jun 2004 09:39:17 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BclMk-0000YA-Lo; Tue, 22 Jun 2004 09:31:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bckol-0002Uw-O9; Tue, 22 Jun 2004 08:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bch3w-0002Wz-Oy for idr@megatron.ietf.org; Tue, 22 Jun 2004 04:55:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18829 for ; Tue, 22 Jun 2004 04:55:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bch3u-0004UD-FT for idr@ietf.org; Tue, 22 Jun 2004 04:55:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bch2x-0004Ah-00 for idr@ietf.org; Tue, 22 Jun 2004 04:54:28 -0400 Received: from ganesh.hcltech.com ([202.54.64.2] helo=ganesh.ctd.hcltech.com) by ietf-mx with esmtp (Exim 4.12) id 1Bch2U-0003qb-00 for idr@ietf.org; Tue, 22 Jun 2004 04:53:58 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jun 2004 14:23:07 +0530 Message-ID: <68C9DA8F50019B4E8622C53811BEE1D60113B0FC@kavithai.ctd.hcltech.com> From: "Kaliraj V - CTD, Chennai." To: Jeffrey Haas , John Smith Subject: RE: [Idr] Loc-Rib and Adj-Rib-In Date: Tue, 22 Jun 2004 14:23:16 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 >IMO, this would imply that a redistributed route enters directly into >the Adj-Rib-Out of a peer potentially in preference to the best selected >bgp route. I feel for all practical-puposes a redistributed-route is Best-BGP route, so it should be seen in the Loc-RIB too. For eg. from the BGP MIB view-point, we'd like to see the redistributed-BGP route as the Best-BGP route for the corresponding prefix, even if it has not been advertised to any peers i.e. not present in Adj-RIB-Out of any peer. Please correct me if wrong. > The routes that we receive from our peers are placed in the "Adj-Rib-In". What about the > routes that are redistributed (static/RIP/ISIS/OSPF/etc) in BGP? May be we can imagine a pseudo-RIB-In for these routes, which will not take part in the BGP-path-selection-process but any competitor available in this pseudo-RIB-In will override the best-bgp-route selected by the selection-process. Kaliraj. -----Original Message----- From: Jeffrey Haas [mailto:jhaas@nexthop.com] Sent: Monday, June 21, 2004 10:02 PM To: John Smith Cc: idr@ietf.org Subject: Re: [Idr] Loc-Rib and Adj-Rib-In On Fri, Jun 18, 2004 at 10:29:59AM +0100, John Smith wrote: > Consider an instance where BGP is redistributing OSPF routes in it. BGP runs its decision > process and finds that these are the best routes and that it needs to announce them to > its peers. From a purist's language, will these routes now be placed in the "Loc-Rib" ? > > The routes that we receive from our peers are placed in the "Adj-Rib-In". What about the > routes that are redistributed (static/RIP/ISIS/OSPF/etc) in BGP? It is intentionally hand-waved in the specification. The closest reference you will find to such a thing (from draft -23): All routes in the Loc-RIB are processed into Adj-RIBs-Out according to configured policy. This policy MAY exclude a route in the Loc-RIB from being installed in a particular Adj-RIB-Out. A route SHALL NOT be installed in the Adj-Rib-Out unless the destination and NEXT_HOP described by this route may be forwarded appropriately by the Routing Table. If a route in Loc-RIB is excluded from a particular Adj-RIB- Out the previously advertised route in that Adj-RIB-Out MUST be with- drawn from service by means of an UPDATE message (see 9.2). IMO, this would imply that a redistributed route enters directly into the Adj-Rib-Out of a peer potentially in preference to the best selected bgp route. >From the BGP MIB standpoint, just because a route is the best bgp route doesn't mean we expect to see it in the adj-rib-out. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 22 13:30:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02383 for ; Tue, 22 Jun 2004 13:30:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcp6U-00079X-Ff for idr-archive@ietf.org; Tue, 22 Jun 2004 13:30:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcndM-0000wd-00 for idr-archive@ietf.org; Tue, 22 Jun 2004 11:56:31 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BclVQ-0001c6-00; Tue, 22 Jun 2004 09:40:09 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BclH8-0007aD-AJ; Tue, 22 Jun 2004 09:25:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BckoH-0002LP-Cz; Tue, 22 Jun 2004 08:55:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcfqK-0008C6-K6 for idr@megatron.ietf.org; Tue, 22 Jun 2004 03:37:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14243 for ; Tue, 22 Jun 2004 03:37:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcfqI-0003P2-DD for idr@ietf.org; Tue, 22 Jun 2004 03:37:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcfpP-00036q-00 for idr@ietf.org; Tue, 22 Jun 2004 03:36:24 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1Bcfon-0002oB-00 for idr@ietf.org; Tue, 22 Jun 2004 03:35:46 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5M7ZkPA002391 for ; Tue, 22 Jun 2004 09:35:46 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 22 Jun 2004 09:35:46 +0200 Received: from lt.eth.ericsson.se (aristotel.eth.ericsson.se [159.107.193.10]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MATN7Q22; Tue, 22 Jun 2004 09:35:45 +0200 Received: from voyager by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA09922; Tue, 22 Jun 2004 09:35:44 +0200 (MET DST) Message-Id: <200406220735.JAA09922@lt.eth.ericsson.se> X-Sybari-Trust: 8ea29947 2335e436 0db66a51 00000139 From: "=?us-ascii?Q?Andras_Csaszar_\=28ETH/RL\=29?=" To: Subject: RE: [Idr] Loc-Rib and Adj-Rib-In Date: Tue, 22 Jun 2004 09:36:17 +0200 Organization: TrafficLab, Ericsson R&D Division MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcRXxqb9GDJWUC8QQGaf3J4DSfVqkAAYzUnA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040621163217.GC12532@nexthop.com> X-OriginalArrivalTime: 22 Jun 2004 07:35:46.0351 (UTC) FILETIME=[881AC3F0:01C4582B] Content-Transfer-Encoding: 7bit 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi! I would like to ask a related question. When do BGP routes get advertised into OSPF? - When received in an UPDATE message? That is, when it gets into Adj-RIB-In? Or, - when it gets selected as best-route? That is, when it is put into the Loc-RIB? In the first case, I think it's hard to ensure that OSPF uses the same routes as BGP thinks. Although it might be possible by setting the OSPF metrics appropriately. (?) In the second case there is an scenario where a multi-homed stub network prefers to use one outgoing link with BGP, therefore does not advertise the other route via OSPF's AS_External_LSA. Now consider that an interor node looses connectivity to the preferred egress router but otherwise would have connectivity to the other egress node, but it won't forward traffic to this egress node since it doesn't know that it accepts outgoing traffic. Anyway, in this case how will this interior node ever learn about this route? (I mean, the two egress nodes running BGP still prefer the first egress link, even though some interior nodes can't access it any longer.) Am I missing something, or which one is right? Thanks, Andras ----Original Message---- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: 2004. junius 21. 18:32 To: John Smith Cc: idr@ietf.org Subject: Re: [Idr] Loc-Rib and Adj-Rib-In > On Fri, Jun 18, 2004 at 10:29:59AM +0100, John Smith wrote: >> Consider an instance where BGP is redistributing OSPF routes in it. >> BGP runs its decision process and finds that these are the best >> routes and that it needs to announce them to its peers. From a >> purist's language, will these routes now be placed in the "Loc-Rib" >> ? >> >> The routes that we receive from our peers are placed in the >> "Adj-Rib-In". What about the routes that are redistributed >> (static/RIP/ISIS/OSPF/etc) in BGP? > > It is intentionally hand-waved in the specification. The closest > reference you will find to such a thing (from draft -23): > > All routes in the Loc-RIB are processed into Adj-RIBs-Out according > to configured policy. This policy MAY exclude a route in the > Loc-RIB from being installed in a particular Adj-RIB-Out. A route > SHALL NOT be installed in the Adj-Rib-Out unless the destination > and NEXT_HOP described by this route may be forwarded > appropriately by the Routing Table. If a route in Loc-RIB is > excluded from a particular Adj-RIB- Out the previously advertised > route in that Adj-RIB-Out MUST be with- drawn from service by > means of an UPDATE message (see 9.2). > > IMO, this would imply that a redistributed route enters directly into > the Adj-Rib-Out of a peer potentially in preference to the best > selected > bgp route. > >> From the BGP MIB standpoint, just because a route is the best bgp >> route > doesn't mean we expect to see it in the adj-rib-out. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 22 18:49:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05682 for ; Tue, 22 Jun 2004 18:49:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcu5L-0001kZ-Gj for idr-archive@ietf.org; Tue, 22 Jun 2004 18:49:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcu43-0001IW-00 for idr-archive@ietf.org; Tue, 22 Jun 2004 18:48:28 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bcu3N-0000sX-00; Tue, 22 Jun 2004 18:47:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bctks-00069r-2m; Tue, 22 Jun 2004 18:28:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcori-0001wo-Lg for idr@megatron.ietf.org; Tue, 22 Jun 2004 13:15:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28352 for ; Tue, 22 Jun 2004 13:15:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcorh-0004SU-K8 for idr@ietf.org; Tue, 22 Jun 2004 13:15:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcn7P-000509-00 for idr@ietf.org; Tue, 22 Jun 2004 11:23:28 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BclFD-00002u-00 for idr@ietf.org; Tue, 22 Jun 2004 09:23:23 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 424622D4826; Tue, 22 Jun 2004 09:22:53 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05240-04; Tue, 22 Jun 2004 09:22:52 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 1F0992D4841; Tue, 22 Jun 2004 09:18:08 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i5MDI5n23309; Tue, 22 Jun 2004 09:18:05 -0400 (EDT) Date: Tue, 22 Jun 2004 09:18:05 -0400 From: Jeffrey Haas To: "Kaliraj V - CTD, Chennai." Subject: Re: [Idr] Loc-Rib and Adj-Rib-In Message-ID: <20040622131805.GG12532@nexthop.com> References: <68C9DA8F50019B4E8622C53811BEE1D60113B0FC@kavithai.ctd.hcltech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68C9DA8F50019B4E8622C53811BEE1D60113B0FC@kavithai.ctd.hcltech.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, Jun 22, 2004 at 02:23:16PM +0530, Kaliraj V - CTD, Chennai. wrote: > I feel for all practical-puposes a redistributed-route is Best-BGP route, so > it should be seen in the Loc-RIB too. There are two issues with this, IMO: 1. A route that is redistributed into BGP, potentially in preference to a route that is the "best BGP route", is not a BGP route until it is sent to the neighboring BGP peer. The local system will simply treat it as a route from whatever protocol (OSPF, IS-IS, etc.) it came from. 2. While the clarity of getting non-BGP information injected into BGP is a little vague, the processing of BGP routes into the Loc-Rib is quite clear: [draft -24, 9.1.2] : The local speaker SHALL then install that route in the Loc-RIB, : replacing any route to the same destination that is currently being : held in the Loc-RIB. See also draft -24 3.2.2.b > For eg. from the BGP MIB view-point, > we'd like to see the redistributed-BGP route as the Best-BGP route for the > corresponding prefix, even if it has not been advertised to any peers i.e. > not present in Adj-RIB-Out of any peer. Please correct me if wrong. >From the MIB view point, the best route is the one in the Loc-Rib. This probably should have been clarified in the v1 MIB but it can go into the v2 MIB. I don't think we need to backout of last call on the MIB for this clarification. > May be we can imagine a pseudo-RIB-In for these routes, which will not take > part in the BGP-path-selection-process but any competitor available in this > pseudo-RIB-In will override the best-bgp-route selected by the > selection-process. The general problem is that the RIB model is reasonably well suited for BGP-only information with some vagaries as to how information from other protocols is redistributed into BGP. To clarify this, we would need to discuss the details of the Policy Information Base and the Routing Table and that would take us into implementation details we really don't want to have done by IDR. The problem with your suggestion of "any competitor available [...] will overide" is that this is a matter of policy, which is dealt with in the section from my original paste. > Kaliraj. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 22 19:37:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11285 for ; Tue, 22 Jun 2004 19:37:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcupI-0001Xq-Tw for idr-archive@ietf.org; Tue, 22 Jun 2004 19:37:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcufH-0006x6-00 for idr-archive@ietf.org; Tue, 22 Jun 2004 19:26:55 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BcuYN-0004tq-02; Tue, 22 Jun 2004 19:19:47 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BcuQJ-0005zf-0S; Tue, 22 Jun 2004 19:11:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BctnE-0007y6-Lu; Tue, 22 Jun 2004 18:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcqHo-0002dN-MQ for idr@megatron.ietf.org; Tue, 22 Jun 2004 14:46:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16608 for ; Tue, 22 Jun 2004 14:46:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcqHm-0004mR-6L for idr@ietf.org; Tue, 22 Jun 2004 14:46:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcq17-0001U0-00 for idr@ietf.org; Tue, 22 Jun 2004 14:29:10 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BcpX9-0003zI-00 for idr@ietf.org; Tue, 22 Jun 2004 13:58:11 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i5MHveBm024543 for ; Tue, 22 Jun 2004 10:57:41 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i5MHveJ67370 for ; Tue, 22 Jun 2004 10:57:40 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406221757.i5MHveJ67370@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14329.1087927060.1@juniper.net> Date: Tue, 22 Jun 2004 10:57:40 -0700 From: Yakov Rekhter Subject: [Idr] Re: WG Last Call on BGP Graceful Restart 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, Just to add to the attached, the implementation report is in draft-ietf-idr-bgp-gr-survey-01.txt. Yakov. ------- Forwarded Message Date: Thu, 17 Jun 2004 11:36:14 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] WG Last Call on BGP Graceful Restart Folks, This is to start the WG Last Call on advancing draft-ietf-idr-restart-10.txt to a Proposed Standard. Since the the previous version of this document already went through the WG Last Call, the main focus of this Last Call is the new text on Finite State Machine. The Last Call ends July 1, 2004. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 22 19:39:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11852 for ; Tue, 22 Jun 2004 19:39:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcuru-00022X-0k for idr-archive@ietf.org; Tue, 22 Jun 2004 19:39:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcuhz-0007RN-00 for idr-archive@ietf.org; Tue, 22 Jun 2004 19:29:45 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BcuYk-0005IC-01; Tue, 22 Jun 2004 19:20:10 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BcuKX-0004Vz-Cw; Tue, 22 Jun 2004 19:05:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BctmV-0007ng-48; Tue, 22 Jun 2004 18:30:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcpq1-0006DO-04 for idr@megatron.ietf.org; Tue, 22 Jun 2004 14:17:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11415 for ; Tue, 22 Jun 2004 14:17:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcppz-0007Q9-Pa for idr@ietf.org; Tue, 22 Jun 2004 14:17:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcpEE-0000ph-00 for idr@ietf.org; Tue, 22 Jun 2004 13:38:40 -0400 Received: from ganesh.hcltech.com ([202.54.64.2] helo=ganesh.ctd.hcltech.com) by ietf-mx with esmtp (Exim 4.12) id 1BcnuU-0002q9-00 for idr@ietf.org; Tue, 22 Jun 2004 12:14:10 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jun 2004 21:43:12 +0530 Message-ID: <68C9DA8F50019B4E8622C53811BEE1D601151364@kavithai.ctd.hcltech.com> From: "Kaliraj V - CTD, Chennai." To: Jeffrey Haas , "Kaliraj V - CTD, Chennai." Subject: RE: [Idr] Loc-Rib and Adj-Rib-In Date: Tue, 22 Jun 2004 21:40:55 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Jeff, from your expln I understand LocRIB is viewed as comprising of only BGP-learnt routes. >From the MIB view point, the best route is the one in the Loc-Rib. But this should be really confusing. Assuming a BGP speaker has, for a prefix P: a BGP-best route R1(LocRIB) and a redistributed non-BGP route R2(result-of-Policy); R2 by policy overrides R1. So the speaker is using R2 and not R1 as reachablity-information for P. Now, if the MIB shows as best-route the route in the Loc-RIB i.e. R1, then this seems misleading to me as the speaker is not using this route. I suggest either R2 be considered part of Loc-RIB or the MIB view-point be altered so that it is not confined to Loc-RIB. Thanks, Kaliraj. -----Original Message----- From: Jeffrey Haas [mailto:jhaas@nexthop.com] Sent: Tuesday, June 22, 2004 6:48 PM To: Kaliraj V - CTD, Chennai. Cc: idr@ietf.org Subject: Re: [Idr] Loc-Rib and Adj-Rib-In On Tue, Jun 22, 2004 at 02:23:16PM +0530, Kaliraj V - CTD, Chennai. wrote: > I feel for all practical-puposes a redistributed-route is Best-BGP route, so > it should be seen in the Loc-RIB too. There are two issues with this, IMO: 1. A route that is redistributed into BGP, potentially in preference to a route that is the "best BGP route", is not a BGP route until it is sent to the neighboring BGP peer. The local system will simply treat it as a route from whatever protocol (OSPF, IS-IS, etc.) it came from. 2. While the clarity of getting non-BGP information injected into BGP is a little vague, the processing of BGP routes into the Loc-Rib is quite clear: [draft -24, 9.1.2] : The local speaker SHALL then install that route in the Loc-RIB, : replacing any route to the same destination that is currently being : held in the Loc-RIB. See also draft -24 3.2.2.b > For eg. from the BGP MIB view-point, > we'd like to see the redistributed-BGP route as the Best-BGP route for the > corresponding prefix, even if it has not been advertised to any peers i.e. > not present in Adj-RIB-Out of any peer. Please correct me if wrong. >From the MIB view point, the best route is the one in the Loc-Rib. This probably should have been clarified in the v1 MIB but it can go into the v2 MIB. I don't think we need to backout of last call on the MIB for this clarification. > May be we can imagine a pseudo-RIB-In for these routes, which will not take > part in the BGP-path-selection-process but any competitor available in this > pseudo-RIB-In will override the best-bgp-route selected by the > selection-process. The general problem is that the RIB model is reasonably well suited for BGP-only information with some vagaries as to how information from other protocols is redistributed into BGP. To clarify this, we would need to discuss the details of the Policy Information Base and the Routing Table and that would take us into implementation details we really don't want to have done by IDR. The problem with your suggestion of "any competitor available [...] will overide" is that this is a matter of policy, which is dealt with in the section from my original paste. > Kaliraj. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 22 20:40:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17837 for ; Tue, 22 Jun 2004 20:40:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcvoq-0005nR-Ma for idr-archive@ietf.org; Tue, 22 Jun 2004 20:40:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcvKW-0000Xf-00 for idr-archive@ietf.org; Tue, 22 Jun 2004 20:09:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bcv3h-0004kj-00; Tue, 22 Jun 2004 19:52:09 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BcuvH-0004kH-AM; Tue, 22 Jun 2004 19:43:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcto8-0008BN-Kr; Tue, 22 Jun 2004 18:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcrP6-0006dz-5T; Tue, 22 Jun 2004 15:58:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24487; Tue, 22 Jun 2004 15:57:57 -0400 (EDT) Message-Id: <200406221957.PAA24487@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Jun 2004 15:57:57 -0400 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-analysis-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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP-4 Protocol Analysis Author(s) : D. Meyer, K. Patel Filename : draft-ietf-idr-bgp-analysis-05.txt Pages : 20 Date : 2004-6-22 The purpose of this report is to document how the requirements for advancing a routing protocol from Draft Standard to full Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for'the second report', as described in Section 6.0 of RFC 1264 [RFC1264]. In order to fulfill the requirement, this report augments RFC 1774 [RFC1774] and summarizes the key features of BGP protocol, and analyzes the protocol with respect to scaling and performance. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-analysis-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-bgp-analysis-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-bgp-analysis-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: <2004-6-22152217.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-analysis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-analysis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-22152217.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- From idr-bounces@ietf.org Tue Jun 22 21:35:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22646 for ; Tue, 22 Jun 2004 21:35:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcwfN-0006gu-S0 for idr-archive@ietf.org; Tue, 22 Jun 2004 21:35:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcvtf-0006dK-00 for idr-archive@ietf.org; Tue, 22 Jun 2004 20:45:52 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BcvP9-0001GI-00; Tue, 22 Jun 2004 20:14:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bctoj-0008K0-69; Tue, 22 Jun 2004 18:32:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcrRX-0006zU-Gw for idr@megatron.ietf.org; Tue, 22 Jun 2004 16:00:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24690 for ; Tue, 22 Jun 2004 16:00:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcrRV-00000M-Sf for idr@ietf.org; Tue, 22 Jun 2004 16:00:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcrQc-0007Qx-00 for idr@ietf.org; Tue, 22 Jun 2004 15:59:34 -0400 Received: from relay.pair.com ([209.68.1.20]) by ietf-mx with smtp (Exim 4.12) id 1BcrPh-00072d-00 for idr@ietf.org; Tue, 22 Jun 2004 15:58:37 -0400 Received: (qmail 12351 invoked from network); 22 Jun 2004 19:58:31 -0000 Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay.pair.com with SMTP; 22 Jun 2004 19:58:31 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id i5MJvjbW020092; Tue, 22 Jun 2004 15:57:45 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200406221957.i5MJvjbW020092@workhorse.faster-light.net> To: "Andras Csaszar \(ETH/RL\)" Subject: Re: [Idr] Loc-Rib and Adj-Rib-In In-reply-to: Your message of "Tue, 22 Jun 2004 09:36:17 +0200." <200406220735.JAA09922@lt.eth.ericsson.se> Date: Tue, 22 Jun 2004 15:57:45 -0400 From: Curtis Villamizar Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <200406220735.JAA09922@lt.eth.ericsson.se> "Andras Csaszar \(ETH/RL\)" writes: > > I would like to ask a related question. When do BGP routes get advertised > into OSPF? When you want to bring down the network since that's what advertising anywhere close to full BGP routes into OSPF will do for you. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 22 21:37:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23132 for ; Tue, 22 Jun 2004 21:37:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcwhY-00075Q-U4 for idr-archive@ietf.org; Tue, 22 Jun 2004 21:37:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcvx7-0007Il-00 for idr-archive@ietf.org; Tue, 22 Jun 2004 20:49:25 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BcvT6-0002DQ-00; Tue, 22 Jun 2004 20:18:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bctoq-0008NY-1W; Tue, 22 Jun 2004 18:32:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcsBw-0005j5-H4 for idr@megatron.ietf.org; Tue, 22 Jun 2004 16:48:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27449 for ; Tue, 22 Jun 2004 16:48:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcsBv-0002P8-8t for idr@ietf.org; Tue, 22 Jun 2004 16:48:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcsAy-000227-00 for idr@ietf.org; Tue, 22 Jun 2004 16:47:28 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BcsA3-0001KO-00 for idr@ietf.org; Tue, 22 Jun 2004 16:46:31 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i5MKk1907760 for ; Tue, 22 Jun 2004 13:46:01 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i5MKjuJ07538 for ; Tue, 22 Jun 2004 13:45:56 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406222045.i5MKjuJ07538@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <51021.1087937156.1@juniper.net> Date: Tue, 22 Jun 2004 13:45:56 -0700 From: Yakov Rekhter Subject: [Idr] IDR WG meeting agenda. 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, Please forward any agenda item requests to Sue and myself. Thanks, Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jun 23 02:07:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12578 for ; Wed, 23 Jun 2004 02:07:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd0uS-00032b-DY for idr-archive@ietf.org; Wed, 23 Jun 2004 02:07:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcxiD-0006hn-00 for idr-archive@ietf.org; Tue, 22 Jun 2004 22:42:10 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bcw7f-0001jZ-00; Tue, 22 Jun 2004 21:00:19 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bcw7g-0008Ln-9m; Tue, 22 Jun 2004 21:00:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcvsM-0000wE-1Y; Tue, 22 Jun 2004 20:44:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcv2a-0002YZ-Sa for idr@megatron.ietf.org; Tue, 22 Jun 2004 19:51:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12972 for ; Tue, 22 Jun 2004 19:50:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcv2Z-0004XY-A4 for idr@ietf.org; Tue, 22 Jun 2004 19:50:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcuq0-0001gS-00 for idr@ietf.org; Tue, 22 Jun 2004 19:38:02 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1Bcug7-00073r-00 for idr@ietf.org; Tue, 22 Jun 2004 19:27:47 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 3921E2D48C9; Tue, 22 Jun 2004 19:27:18 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29547-01-25; Tue, 22 Jun 2004 19:27:16 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 413372D483D; Tue, 22 Jun 2004 19:27:16 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i5MNRGM02117; Tue, 22 Jun 2004 19:27:16 -0400 (EDT) Date: Tue, 22 Jun 2004 19:27:16 -0400 From: Jeffrey Haas To: "Kaliraj V - CTD, Chennai." Subject: Re: [Idr] Loc-Rib and Adj-Rib-In Message-ID: <20040622232716.GP12532@nexthop.com> References: <68C9DA8F50019B4E8622C53811BEE1D601151364@kavithai.ctd.hcltech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68C9DA8F50019B4E8622C53811BEE1D601151364@kavithai.ctd.hcltech.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, Jun 22, 2004 at 09:40:55PM +0530, Kaliraj V - CTD, Chennai. wrote: > Jeff, from your expln I understand LocRIB is viewed as comprising of only > BGP-learnt routes. > > From the MIB view point, the best route is the one in the Loc-Rib. > > But this should be really confusing. Assuming a BGP speaker has, for a > prefix P: a BGP-best route R1(LocRIB) and a redistributed non-BGP route > R2(result-of-Policy); R2 by policy overrides R1. So the speaker is using R2 > and not R1 as reachablity-information for P. Now, if the MIB shows as > best-route the route in the Loc-RIB i.e. R1, then this seems misleading to > me as the speaker is not using this route. This would only be misleading if the MIB stated in its Adj-Rib-Out that it was using a given BGP route. Note that the v2 MIB has added an Adj-Rib-Out table. The contents of this table was contentious when it was added and we have not received consensus as to the contents. > I suggest either R2 be considered part of Loc-RIB or the MIB view-point be > altered so that it is not confined to Loc-RIB. Loc-Rib will contain the BGP Best route. The MIB must reflect this since this is what the BGP specification indicates. This route is then installed in the Routing Table. It is at this point that implementation specific magic happens. As a for example, you could consider your Routing Table as having the ability to learn multiple routes from each protocol that is going to install routes there. Through an internal policy mechanism, the multiple candidate routes will become the Routing Table's active route and that route will presumably be installed in the FIB. This active Routing Table route, when not the same as the Loc-Rib route, is available to BGP for redistribution (and technically origination). The details of how this works and model by which the Routing Table is modeled, is outside the scope of the IDR working group. To do more than to reflect what was sent in BGP via the Adj-Rib-Out table as a BGP route is probably out of scope. However, I've recently become aware of a MIB TC that may let us reflect what protocol the route came from. This will like show up in the next draft of the MIB. It really seems that what you want is a Routing Table MIB. > Kaliraj. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jun 23 02:21:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27172 for ; Wed, 23 Jun 2004 02:21:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd18H-0005aU-CN for idr-archive@ietf.org; Wed, 23 Jun 2004 02:21:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcyLM-0002UM-00 for idr-archive@ietf.org; Tue, 22 Jun 2004 23:22:37 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BcwOt-0003x1-00; Tue, 22 Jun 2004 21:18:07 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BcwBR-0000Zg-4u; Tue, 22 Jun 2004 21:04:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcw3L-0006W6-T0; Tue, 22 Jun 2004 20:55:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcvpk-0007WV-O5 for idr@megatron.ietf.org; Tue, 22 Jun 2004 20:41:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17998 for ; Tue, 22 Jun 2004 20:41:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcvpj-0005xv-5h for idr@ietf.org; Tue, 22 Jun 2004 20:41:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcvLL-0000gG-00 for idr@ietf.org; Tue, 22 Jun 2004 20:10:24 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bcv3l-0004jO-01 for idr@ietf.org; Tue, 22 Jun 2004 19:52:13 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bcuqs-0003R2-C7 for idr@ietf.org; Tue, 22 Jun 2004 19:38:54 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 6B6C62D492B; Tue, 22 Jun 2004 19:38:23 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29331-05-60; Tue, 22 Jun 2004 19:38:22 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 4FE322D490A; Tue, 22 Jun 2004 19:38:22 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i5MNcMw02529; Tue, 22 Jun 2004 19:38:22 -0400 (EDT) Date: Tue, 22 Jun 2004 19:38:22 -0400 From: Jeffrey Haas To: "Andras Csaszar (ETH/RL)" Subject: Re: [Idr] Loc-Rib and Adj-Rib-In Message-ID: <20040622233822.GQ12532@nexthop.com> References: <20040621163217.GC12532@nexthop.com> <200406220735.JAA09922@lt.eth.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406220735.JAA09922@lt.eth.ericsson.se> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, Jun 22, 2004 at 09:36:17AM +0200, Andras Csaszar (ETH/RL) wrote: > I would like to ask a related question. When do BGP routes get advertised > into OSPF? > > - When received in an UPDATE message? That is, when it gets into Adj-RIB-In? > Or, > - when it gets selected as best-route? That is, when it is put into the > Loc-RIB? Answer number 3: When it becomes the active route in the Routing Table, or some implementation equivalent of this abstraction. > In the second case there is an scenario where a multi-homed stub network > prefers to use one outgoing link with BGP, therefore does not advertise the > other route via OSPF's AS_External_LSA. Now consider that an interor node > looses connectivity to the preferred egress router but otherwise would have > connectivity to the other egress node, but it won't forward traffic to this > egress node since it doesn't know that it accepts outgoing traffic. In a given BGP Autonomous System, each BGP speaker may have a distinct BGP route as the best BGP route. When this is the case, if each of these BGP speakers is an OSPF speaker and these routes are injected into OSPF, you will have multiple candidate AS External routes. There are multiple reasons why a given BGP route may be selected as the best BGP route on multiple BGP speakers. The BGP tie breaking process will show many of them. > Andras -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 24 13:34:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03256 for ; Thu, 24 Jun 2004 13:34:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdY7D-0005GA-Ls for idr-archive@ietf.org; Thu, 24 Jun 2004 13:34:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdY3c-00043v-00 for idr-archive@ietf.org; Thu, 24 Jun 2004 13:30:42 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BdXzu-0002kx-00; Thu, 24 Jun 2004 13:26:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXJ8-0001Yr-IX; Thu, 24 Jun 2004 12:42:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd2vD-0005tZ-RZ for idr@megatron.ietf.org; Wed, 23 Jun 2004 04:15:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03541 for ; Wed, 23 Jun 2004 04:15:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd2vB-0002bJ-Jg for idr@ietf.org; Wed, 23 Jun 2004 04:15:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd2em-0007ME-00 for idr@ietf.org; Wed, 23 Jun 2004 03:58:58 -0400 Received: from ganesh.hcltech.com ([202.54.64.2] helo=ganesh.ctd.hcltech.com) by ietf-mx with esmtp (Exim 4.12) id 1Bd2Ed-0002V0-00 for idr@ietf.org; Wed, 23 Jun 2004 03:31:55 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jun 2004 13:02:09 +0530 Message-ID: <68C9DA8F50019B4E8622C53811BEE1D6011518D9@kavithai.ctd.hcltech.com> From: "Kaliraj V - CTD, Chennai." To: Jeffrey Haas , "Kaliraj V - CTD, Chennai." Subject: RE: [Idr] Loc-Rib and Adj-Rib-In Date: Wed, 23 Jun 2004 13:01:21 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 >This would only be misleading if the MIB stated in its Adj-Rib-Out that it was using a given BGP route. I agree. I guess this is clear. LocRIB is the protocol's view of the best-route. Adj-RIB-out gives the results of policy too(redistribution but-not outbound-routemaps asper MIBv2). SO, in MIBv2 terms: a redistributed route will get into Adj-RIB-In (NLRItable) and will override the LocRIB(bestroute asper LocRIB) to directly enter Adj-RIB-Out (be pointed to by the Rowpointer-object bgpM2AdjRibsOutRoute) for that NLRI prefix. >However, I've recently become aware of a MIB TC that may let us reflect what protocol the route came from. This feels like Good to have information, though not really needed for BGP to know-about. >It really seems that what you want is a Routing Table MIB. Not really, I'm happy with presence of Adj-RIB-Out to tell me what BGP actually used.:) Thanks, Kaliraj. -----Original Message----- From: Jeffrey Haas [mailto:jhaas@nexthop.com] Sent: Wednesday, June 23, 2004 4:57 AM To: Kaliraj V - CTD, Chennai. Cc: idr@ietf.org Subject: Re: [Idr] Loc-Rib and Adj-Rib-In On Tue, Jun 22, 2004 at 09:40:55PM +0530, Kaliraj V - CTD, Chennai. wrote: > Jeff, from your expln I understand LocRIB is viewed as comprising of only > BGP-learnt routes. > > From the MIB view point, the best route is the one in the Loc-Rib. > > But this should be really confusing. Assuming a BGP speaker has, for a > prefix P: a BGP-best route R1(LocRIB) and a redistributed non-BGP route > R2(result-of-Policy); R2 by policy overrides R1. So the speaker is using R2 > and not R1 as reachablity-information for P. Now, if the MIB shows as > best-route the route in the Loc-RIB i.e. R1, then this seems misleading to > me as the speaker is not using this route. This would only be misleading if the MIB stated in its Adj-Rib-Out that it was using a given BGP route. Note that the v2 MIB has added an Adj-Rib-Out table. The contents of this table was contentious when it was added and we have not received consensus as to the contents. > I suggest either R2 be considered part of Loc-RIB or the MIB view-point be > altered so that it is not confined to Loc-RIB. Loc-Rib will contain the BGP Best route. The MIB must reflect this since this is what the BGP specification indicates. This route is then installed in the Routing Table. It is at this point that implementation specific magic happens. As a for example, you could consider your Routing Table as having the ability to learn multiple routes from each protocol that is going to install routes there. Through an internal policy mechanism, the multiple candidate routes will become the Routing Table's active route and that route will presumably be installed in the FIB. This active Routing Table route, when not the same as the Loc-Rib route, is available to BGP for redistribution (and technically origination). The details of how this works and model by which the Routing Table is modeled, is outside the scope of the IDR working group. To do more than to reflect what was sent in BGP via the Adj-Rib-Out table as a BGP route is probably out of scope. However, I've recently become aware of a MIB TC that may let us reflect what protocol the route came from. This will like show up in the next draft of the MIB. It really seems that what you want is a Routing Table MIB. > Kaliraj. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 24 13:35:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03486 for ; Thu, 24 Jun 2004 13:35:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdY8R-0005Tc-5K for idr-archive@ietf.org; Thu, 24 Jun 2004 13:35:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdY5T-0004QZ-00 for idr-archive@ietf.org; Thu, 24 Jun 2004 13:32:36 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BdY1z-00039C-00; Thu, 24 Jun 2004 13:28:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXJE-0001bT-DZ; Thu, 24 Jun 2004 12:42:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd2yt-0006ar-Ej for idr@megatron.ietf.org; Wed, 23 Jun 2004 04:19:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04185 for ; Wed, 23 Jun 2004 04:19:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd2yr-0003Ys-0L for idr@ietf.org; Wed, 23 Jun 2004 04:19:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd2kJ-0000zF-00 for idr@ietf.org; Wed, 23 Jun 2004 04:04:40 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1Bd2N3-0004bb-00 for idr@ietf.org; Wed, 23 Jun 2004 03:40:38 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5N7ecPA025965 for ; Wed, 23 Jun 2004 09:40:38 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Jun 2004 09:40:36 +0200 Received: from lt.eth.ericsson.se (aristotel.eth.ericsson.se [159.107.193.10]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4QXJPR; Wed, 23 Jun 2004 09:40:35 +0200 Received: from voyager by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA23242; Wed, 23 Jun 2004 09:40:35 +0200 (MET DST) Message-Id: <200406230740.JAA23242@lt.eth.ericsson.se> X-Sybari-Trust: 83da6460 100f6658 44e5f47c 00000138 From: "=?iso-8859-2?Q?Andr=E1s_Cs=E1sz=E1r_\=28ETH/RL\=29?=" To: Subject: Re: [Idr] Loc-Rib and Adj-Rib-In Date: Wed, 23 Jun 2004 09:41:11 +0200 Organization: TrafficLab, Ericsson R&D Division MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcRYk0vl4XRhOtoETc2yeeHVVF9YAAAYAbhw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-reply-to: <200406221957.i5MJvjbW020092@workhorse.faster-light.net> X-OriginalArrivalTime: 23 Jun 2004 07:40:36.0113 (UTC) FILETIME=[5F3AB010:01C458F5] Content-Transfer-Encoding: quoted-printable 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sure, yes, I maybe was not precise enough when asking my question. I did = not mean full BGP routes, but only the available destination prefixes (maybe after route aggregation) reachable through a given BGP egress router. (I mean interior routers (running IGP only) have to be able to forward = traffic to external prefixes as well, and I'm considering here either a = mult-homed stub or any AS with multiple providers or peering relations.) I think reachable prefixes are given to the IGP after they are installed into Loc-RIB (or even to Adj-RIB-Out?), and only if the given BGP = speaker received the reachable destination prefix UPDATE message through eBGP. Am I right? Andr=E1s ----Original Message---- From: Curtis Villamizar [mailto:curtis@faster-light.net] Sent: 2004. j=FAnius 22. 21:58 To: Andras Csaszar (ETH/RL) Cc: idr@ietf.org Subject: Re: [Idr] Loc-Rib and Adj-Rib-In > In message <200406220735.JAA09922@lt.eth.ericsson.se> > "Andras Csaszar \(ETH/RL\)" writes: >>=20 >> I would like to ask a related question. When do BGP routes get >> advertised into OSPF? >=20 >=20 > When you want to bring down the network since that's what advertising > anywhere close to full BGP routes into OSPF will do for you. >=20 > Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 24 14:08:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06989 for ; Thu, 24 Jun 2004 14:08:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdYe5-0004xD-9Q for idr-archive@ietf.org; Thu, 24 Jun 2004 14:08:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdYOv-0002KL-00 for idr-archive@ietf.org; Thu, 24 Jun 2004 13:52:42 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdYEt-0007ka-00; Thu, 24 Jun 2004 13:42:21 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BdY2l-0007Vn-7S; Thu, 24 Jun 2004 13:29:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXJK-0001dT-AI; Thu, 24 Jun 2004 12:42:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd32F-0007Kz-FS for idr@megatron.ietf.org; Wed, 23 Jun 2004 04:23:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05123 for ; Wed, 23 Jun 2004 04:23:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd32D-0004MG-8a for idr@ietf.org; Wed, 23 Jun 2004 04:23:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd2rT-00020W-00 for idr@ietf.org; Wed, 23 Jun 2004 04:12:04 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Bd2Yg-0006T4-00 for idr@ietf.org; Wed, 23 Jun 2004 03:52:38 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5N7qcWR023694 for ; Wed, 23 Jun 2004 09:52:39 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Jun 2004 09:52:38 +0200 Received: from lt.eth.ericsson.se (aristotel.eth.ericsson.se [159.107.193.10]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4QXNJ5; Wed, 23 Jun 2004 09:52:38 +0200 Received: from voyager by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA24603; Wed, 23 Jun 2004 09:52:37 +0200 (MET DST) Message-Id: <200406230752.JAA24603@lt.eth.ericsson.se> X-Sybari-Trust: d323d843 100f6658 44e5f47c 00000138 From: "=?iso-8859-2?Q?Andr=E1s_Cs=E1sz=E1r_\=28ETH/RL\=29?=" To: Date: Wed, 23 Jun 2004 09:53:15 +0200 Organization: TrafficLab, Ericsson R&D Division MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcRY9yOlbbMs1l23RTObws/4BxSUiA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 23 Jun 2004 07:52:38.0895 (UTC) FILETIME=[0E0A77F0:01C458F7] Content-Transfer-Encoding: quoted-printable Subject: [Idr] IGP upcall to BGP? 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable draft-ietf-idr-bgp4-24 writes: >> The local speaker MUST determine the immediate next-hop address from the NEXT_HOP attribute of the selected route (see Section 5.1.3). If either = the immediate next hop or the IGP cost to the NEXT_HOP (where the NEXT_HOP = is resolved through an IGP route) changes, Phase 2 Route Selection MUST be performed again. << Sure, yes, that makes sense since if you have multiple alternative inter-domain routes to a given destination, than it might be possible = that the router decided for one of them based on the lowest IGP cost tie = breaking rule. So far, so good. But, what happens if there is a fault inside the AS, = and the connectivity remains after IGP re-routing but the IGP cost changes. According to the above citation, BGP could then, of course, select a new route. My question: how (and how fast) does BGP learn about IGP cost change? = Sure, IGP link state advertisements at some point reach the given BGP speaker, = but how does this info get to the BGP module? Anyway, could you please suggest me good articles/papers about the = interface between IGP (IS-IS/OSPF) and BGP? What timers and processing delays are involved in both directions? I mean what happens if a BGP speaker = receives an UPDATE of a newly reachable destination prefix in an AS which has multiple providers. This info has to get into interior routers via IGP. = (For a moment, let's forget about default IGP routes...) Thanks, Andr=E1s _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 24 18:56:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25180 for ; Thu, 24 Jun 2004 18:56:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdd8F-0005dh-Et for idr-archive@ietf.org; Thu, 24 Jun 2004 18:55:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdcUe-0004Qh-00 for idr-archive@ietf.org; Thu, 24 Jun 2004 18:14:53 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bdbk0-000389-01; Thu, 24 Jun 2004 17:26:40 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bdbbd-0006xb-1z; Thu, 24 Jun 2004 17:18:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdbB2-0002sG-2X; Thu, 24 Jun 2004 16:50:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdYEd-0000gr-0a for idr@megatron.ietf.org; Thu, 24 Jun 2004 13:42:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04527 for ; Thu, 24 Jun 2004 13:42:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdYEb-0000GX-Qg for idr@ietf.org; Thu, 24 Jun 2004 13:42:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdYDA-0007Gw-00 for idr@ietf.org; Thu, 24 Jun 2004 13:40:33 -0400 Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BdYBM-0006UV-00 for idr@ietf.org; Thu, 24 Jun 2004 13:38:40 -0400 Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by mail-white.research.att.com (Postfix) with ESMTP id 64728664056; Thu, 24 Jun 2004 13:38:10 -0400 (EDT) Received: from chips.research.att.com (chips.research.att.com [135.207.27.139]) by mail-blue.research.att.com (Postfix) with ESMTP id 56613F3A8E; Thu, 24 Jun 2004 13:38:10 -0400 (EDT) Received: from chips.research.att.com (localhost [127.0.0.1]) by chips.research.att.com (SGI-8.12.5/8.12.5) with ESMTP id i5OHcAav37399577; Thu, 24 Jun 2004 13:38:10 -0400 (EDT) Received: (from jrex@localhost) by chips.research.att.com (SGI-8.12.5/8.12.5/Submit) id i5OHc97W44847887; Thu, 24 Jun 2004 13:38:09 -0400 (EDT) Date: Thu, 24 Jun 2004 13:38:09 -0400 (EDT) Message-Id: <200406241738.i5OHc97W44847887@chips.research.att.com> From: Jennifer Rexford To: Andras.Csaszar@ericsson.com In-reply-to: <200406230752.JAA24603@lt.eth.ericsson.se> (Andras.Csaszar@ericsson.com) Subject: Re: [Idr] IGP upcall to BGP? 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > y question: how (and how fast) does BGP learn about IGP cost change? Sure, > IGP link state advertisements at some point reach the given BGP speaker, but > how does this info get to the BGP module? > > Anyway, could you please suggest me good articles/papers about the interface > between IGP (IS-IS/OSPF) and BGP? What timers and processing delays are > involved in both directions? For a recent study of this issue, see Renata Teixeira, Aman Shaikh, Tim Griffin, and Jennifer Rexford, "Dynamics of hot-potato routing in IP networks," Proc. ACM SIGMETRICS, June 2004. http://www.research.att.com/~jrex/papers/sigmetrics04.pdf http://www.research.att.com/~jrex/talks/ima04.ppt http://www.nanog.org/mtg-0402/teixeira.html -- Jen _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 24 20:05:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04781 for ; Thu, 24 Jun 2004 20:05:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdeBc-0000xV-TQ for idr-archive@ietf.org; Thu, 24 Jun 2004 20:03:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bde9T-00005x-00 for idr-archive@ietf.org; Thu, 24 Jun 2004 20:01:07 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bde63-0006ko-00; Thu, 24 Jun 2004 19:57:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BddoG-0006oK-5k; Thu, 24 Jun 2004 19:39:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bddgp-0003Qf-8s for idr@megatron.ietf.org; Thu, 24 Jun 2004 19:31:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29879 for ; Thu, 24 Jun 2004 19:31:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BddfX-0006gQ-Eb for idr@ietf.org; Thu, 24 Jun 2004 19:30:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BddSy-0003dn-00 for idr@ietf.org; Thu, 24 Jun 2004 19:17:13 -0400 Received: from relay.pair.com ([209.68.1.20]) by ietf-mx with smtp (Exim 4.12) id 1Bdd5j-0005DI-00 for idr@ietf.org; Thu, 24 Jun 2004 18:53:11 -0400 Received: (qmail 59910 invoked from network); 24 Jun 2004 22:53:11 -0000 Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay.pair.com with SMTP; 24 Jun 2004 22:53:11 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id i5OMpx5x031063; Thu, 24 Jun 2004 18:51:59 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200406242251.i5OMpx5x031063@workhorse.faster-light.net> To: "Andr s Cs sz r \(ETH/RL\)" Subject: Re: [Idr] Loc-Rib and Adj-Rib-In In-reply-to: Your message of "Wed, 23 Jun 2004 09:41:11 +0200." <200406230740.JAA23242@lt.eth.ericsson.se> Date: Thu, 24 Jun 2004 18:51:59 -0400 From: Curtis Villamizar Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <200406230740.JAA23242@lt.eth.ericsson.se> "Andr s Cs sz r \(ETH/RL\)" writes: > > Sure, yes, I maybe was not precise enough when asking my question. I did not > mean full BGP routes, but only the available destination prefixes (maybe > after route aggregation) reachable through a given BGP egress router. (I > mean interior routers (running IGP only) have to be able to forward traffic > to external prefixes as well, and I'm considering here either a mult-homed > stub or any AS with multiple providers or peering relations.) > > I think reachable prefixes are given to the IGP after they are installed > into Loc-RIB (or even to Adj-RIB-Out?), and only if the given BGP speaker > received the reachable destination prefix UPDATE message through eBGP. > > Am I right? > > András BGP routes are not given to the IGP at all. IBGP is used to pass the routing information to thw interior of an AS and acrosss the AS. The next hop for all BGP routes are looked up in the IGP and the forwarding entry is created based on those two peices of information. Implementation details vary with some optimizations done to reduce the work when the IGP changes (trading off space for a time gain) but the above description is otherwise accurate. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jun 25 04:43:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17419 for ; Fri, 25 Jun 2004 04:43:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdmIa-0000wA-OX for idr-archive@ietf.org; Fri, 25 Jun 2004 04:43:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdmHZ-0000Za-00 for idr-archive@ietf.org; Fri, 25 Jun 2004 04:42:02 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BdmGc-0007l9-00; Fri, 25 Jun 2004 04:41:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdmBC-0007yB-Ii; Fri, 25 Jun 2004 04:35:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdm1E-0005L9-56 for idr@megatron.ietf.org; Fri, 25 Jun 2004 04:25:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16493 for ; Fri, 25 Jun 2004 04:25:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdm1B-0002nx-Sq for idr@ietf.org; Fri, 25 Jun 2004 04:25:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdm0C-0002VK-00 for idr@ietf.org; Fri, 25 Jun 2004 04:24:04 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Bdlzs-0002Cf-00 for idr@ietf.org; Fri, 25 Jun 2004 04:23:44 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5P8NiWR003517 for ; Fri, 25 Jun 2004 10:23:44 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jun 2004 10:23:44 +0200 Received: from lt.eth.ericsson.se (aristotel.eth.ericsson.se [159.107.193.10]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4RL0ZR; Fri, 25 Jun 2004 10:23:44 +0200 Received: from voyager by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id KAA27793; Fri, 25 Jun 2004 10:23:43 +0200 (MET DST) Message-Id: <200406250823.KAA27793@lt.eth.ericsson.se> X-Sybari-Trust: c3613cf5 100f6658 80bc4c27 00000138 From: "=?iso-8859-2?Q?Andr=E1s_Cs=E1sz=E1r_\=28ETH/RL\=29?=" To: Date: Fri, 25 Jun 2004 10:24:17 +0200 Organization: TrafficLab, Ericsson R&D Division MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcRaPgmsrBFY94DUQm2ljjjU6ArIRwASiWlg In-Reply-To: <200406242251.i5OMpx5x031063@workhorse.faster-light.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 25 Jun 2004 08:23:44.0579 (UTC) FILETIME=[BAE6C130:01C45A8D] Content-Transfer-Encoding: quoted-printable Subject: [Idr] IGP and BGP 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > BGP routes are not given to the IGP at all. IBGP is used to pass the > routing information to thw interior of an AS and acrosss the AS. Well, that's interesting. iBGP across AS, sure; that is, between edge = nodes (which nodes probably also use eBGP to communicate with neighbour AS router(s)). But iBGP to the interior... To every single router... Does = this mean that typically every router is a BGP speaker inside an AS? In = practice there are really no interior routers which only run IGP? iBGP requires full mesh interconnection between iBGP speakers, and if = every single router inside an AS runs BGP, then this full mesh would be pretty hard to maintain. So, route reflectors are then really used in practice = by operators in order to avoid this full mesh? Thanks, Andr=E1s _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jun 25 12:01:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17012 for ; Fri, 25 Jun 2004 12:01:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdt9K-0002Ly-Ix for idr-archive@ietf.org; Fri, 25 Jun 2004 12:01:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdt6y-0001Uc-00 for idr-archive@ietf.org; Fri, 25 Jun 2004 11:59:33 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bdt3U-0000Ua-00; Fri, 25 Jun 2004 11:55:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdszV-00086u-Ef; Fri, 25 Jun 2004 11:51:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdshb-0001w3-4b for idr@megatron.ietf.org; Fri, 25 Jun 2004 11:33:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11007 for ; Fri, 25 Jun 2004 11:33:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdsha-0003Fc-1K for idr@ietf.org; Fri, 25 Jun 2004 11:33:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdsUF-0000qp-00 for idr@ietf.org; Fri, 25 Jun 2004 11:19:32 -0400 Received: from relay.pair.com ([209.68.1.20]) by ietf-mx with smtp (Exim 4.12) id 1BdsIx-0006Se-00 for idr@ietf.org; Fri, 25 Jun 2004 11:07:51 -0400 Received: (qmail 47816 invoked from network); 25 Jun 2004 15:07:50 -0000 Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay.pair.com with SMTP; 25 Jun 2004 15:07:50 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id i5PF6SmH036845; Fri, 25 Jun 2004 11:06:28 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200406251506.i5PF6SmH036845@workhorse.faster-light.net> To: "Andr s Cs sz r \(ETH/RL\)" Subject: Re: [Idr] IGP and BGP In-reply-to: Your message of "Fri, 25 Jun 2004 10:24:17 +0200." <200406250823.KAA27793@lt.eth.ericsson.se> Date: Fri, 25 Jun 2004 11:06:28 -0400 From: Curtis Villamizar Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In message <200406250823.KAA27793@lt.eth.ericsson.se> "Andr s Cs sz r \(ETH/RL\)" writes: > > > BGP routes are not given to the IGP at all. IBGP is used to pass the > > routing information to thw interior of an AS and acrosss the AS. > > Well, that's interesting. iBGP across AS, sure; that is, between edge > nodes (which nodes probably also use eBGP to communicate with > neighbour AS router(s)). But iBGP to the interior... To every single > router... Does this mean that typically every router is a BGP speaker > inside an AS? In practice there are really no interior routers which > only run IGP? Yes that is exactly how it is used. Although route reflectors are typically used to avoid a full mesh of BGP speakers. > iBGP requires full mesh interconnection between iBGP speakers, and if > every single router inside an AS runs BGP, then this full mesh would > be pretty hard to maintain. So, route reflectors are then really used > in practice by operators in order to avoid this full mesh? Exactly. Quite a bit of efficiency consideration in the BGP implementation is required for this to work. This is why naive BGP implementations in the mid to late 90s failed so miserably in the ISP lab before even getting to the field (and occasionally new ones continue to do so if they even get that far). > Thanks, > András Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 29 14:25:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06665 for ; Tue, 29 Jun 2004 14:25:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfNIa-0004OO-7l for idr-archive@ietf.org; Tue, 29 Jun 2004 14:25:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfNHW-0003zs-00 for idr-archive@ietf.org; Tue, 29 Jun 2004 14:24:35 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfNGY-0003IT-00; Tue, 29 Jun 2004 14:23:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfN70-0001If-Rn; Tue, 29 Jun 2004 14:13:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfN1s-0000Ho-7W for idr@megatron.ietf.org; Tue, 29 Jun 2004 14:08:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05709 for ; Tue, 29 Jun 2004 14:08:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfN1r-0005uJ-7T for idr@ietf.org; Tue, 29 Jun 2004 14:08:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfN0s-0005Y9-00 for idr@ietf.org; Tue, 29 Jun 2004 14:07:22 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BfMzt-0005CB-00 for idr@ietf.org; Tue, 29 Jun 2004 14:06:21 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 573DBA8CBF4; Tue, 29 Jun 2004 11:06:17 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00339-06; Tue, 29 Jun 2004 11:06:17 -0700 (PDT) Received: from fall.redback.com (fall.redback.com [155.53.44.81]) by prattle.redback.com (Postfix) with ESMTP id F3336A8CBF0; Tue, 29 Jun 2004 11:06:16 -0700 (PDT) Received: from redback.com (localhost [127.0.0.1]) by fall.redback.com (8.11.0/8.8.8/null redback bsdclient) with ESMTP id i5TI6Gh08552; Tue, 29 Jun 2004 11:06:16 -0700 (PDT) Message-Id: <200406291806.i5TI6Gh08552@fall.redback.com> To: idr@ietf.org Date: Tue, 29 Jun 2004 11:06:16 -0700 From: Enke Chen X-Virus-Scanned: by amavisd-new at redback.com Cc: enke@redback.com, naiming@redback.com Subject: [Idr] draft-chen-bgp-group-path-update-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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, folks: Here is another attempt to tackle the issue of persistent IBGP route oscillation. Please let us know if you have any comments on the draft. Thanks. -- Enke ------- Forwarded Message To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 28 Jun 2004 15:27:53 -0400 Subject: I-D ACTION:draft-chen-bgp-group-path-update-00.txt Sender: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Advertisement of the Group Best Paths in BGP Author(s) : E. Chen Filename : draft-chen-bgp-group-path-update-00.txt Pages : 12 Date : 2004-6-28 In this document we first identify and qualify the Group Best Paths for an address prefix as in general the necessary and sufficient subset of paths that need to be advertised by a BGP route reflector or a BGP confederation ASBR in order to eliminate the MED-type route oscillations and to achieve consistent routing in a network. We then propose a mechanism for BGP that would allow a route reflector or a confederation ASBR to advertise the Group Best Paths. The proposed mechanism is designed such that the vast majority of the BGP speakers in a network need only minor software changes in order to deploy the mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-bgp-group-path-update-00.txt ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA11375 for ; Tue, 29 Jun 2004 14:23:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfN70-0001If-Pa; Tue, 29 Jun 2004 14:13:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfN1s-0000Ho-7W for idr@megatron.ietf.org; Tue, 29 Jun 2004 14:08:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05709 for ; Tue, 29 Jun 2004 14:08:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfN1r-0005uJ-7T for idr@ietf.org; Tue, 29 Jun 2004 14:08:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfN0s-0005Y9-00 for idr@ietf.org; Tue, 29 Jun 2004 14:07:22 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BfMzt-0005CB-00 for idr@ietf.org; Tue, 29 Jun 2004 14:06:21 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 573DBA8CBF4; Tue, 29 Jun 2004 11:06:17 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00339-06; Tue, 29 Jun 2004 11:06:17 -0700 (PDT) Received: from fall.redback.com (fall.redback.com [155.53.44.81]) by prattle.redback.com (Postfix) with ESMTP id F3336A8CBF0; Tue, 29 Jun 2004 11:06:16 -0700 (PDT) Received: from redback.com (localhost [127.0.0.1]) by fall.redback.com (8.11.0/8.8.8/null redback bsdclient) with ESMTP id i5TI6Gh08552; Tue, 29 Jun 2004 11:06:16 -0700 (PDT) Message-Id: <200406291806.i5TI6Gh08552@fall.redback.com> To: idr@ietf.org Date: Tue, 29 Jun 2004 11:06:16 -0700 From: Enke Chen X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: enke@redback.com, naiming@redback.com Subject: [Idr] draft-chen-bgp-group-path-update-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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hi, folks: Here is another attempt to tackle the issue of persistent IBGP route oscillation. Please let us know if you have any comments on the draft. Thanks. -- Enke ------- Forwarded Message To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 28 Jun 2004 15:27:53 -0400 Subject: I-D ACTION:draft-chen-bgp-group-path-update-00.txt Sender: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Advertisement of the Group Best Paths in BGP Author(s) : E. Chen Filename : draft-chen-bgp-group-path-update-00.txt Pages : 12 Date : 2004-6-28 In this document we first identify and qualify the Group Best Paths for an address prefix as in general the necessary and sufficient subset of paths that need to be advertised by a BGP route reflector or a BGP confederation ASBR in order to eliminate the MED-type route oscillations and to achieve consistent routing in a network. We then propose a mechanism for BGP that would allow a route reflector or a confederation ASBR to advertise the Group Best Paths. The proposed mechanism is designed such that the vast majority of the BGP speakers in a network need only minor software changes in order to deploy the mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-bgp-group-path-update-00.txt ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA14772 for ; Fri, 25 Jun 2004 11:55:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdszV-00086u-Ai; Fri, 25 Jun 2004 11:51:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdshb-0001w3-4b for idr@megatron.ietf.org; Fri, 25 Jun 2004 11:33:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11007 for ; Fri, 25 Jun 2004 11:33:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdsha-0003Fc-1K for idr@ietf.org; Fri, 25 Jun 2004 11:33:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdsUF-0000qp-00 for idr@ietf.org; Fri, 25 Jun 2004 11:19:32 -0400 Received: from relay.pair.com ([209.68.1.20]) by ietf-mx with smtp (Exim 4.12) id 1BdsIx-0006Se-00 for idr@ietf.org; Fri, 25 Jun 2004 11:07:51 -0400 Received: (qmail 47816 invoked from network); 25 Jun 2004 15:07:50 -0000 Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay.pair.com with SMTP; 25 Jun 2004 15:07:50 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id i5PF6SmH036845; Fri, 25 Jun 2004 11:06:28 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200406251506.i5PF6SmH036845@workhorse.faster-light.net> To: "Andr s Cs sz r \(ETH/RL\)" Subject: Re: [Idr] IGP and BGP In-reply-to: Your message of "Fri, 25 Jun 2004 10:24:17 +0200." <200406250823.KAA27793@lt.eth.ericsson.se> Date: Fri, 25 Jun 2004 11:06:28 -0400 From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org In message <200406250823.KAA27793@lt.eth.ericsson.se> "Andr s Cs sz r \(ETH/RL\)" writes: > > > BGP routes are not given to the IGP at all. IBGP is used to pass the > > routing information to thw interior of an AS and acrosss the AS. > > Well, that's interesting. iBGP across AS, sure; that is, between edge > nodes (which nodes probably also use eBGP to communicate with > neighbour AS router(s)). But iBGP to the interior... To every single > router... Does this mean that typically every router is a BGP speaker > inside an AS? In practice there are really no interior routers which > only run IGP? Yes that is exactly how it is used. Although route reflectors are typically used to avoid a full mesh of BGP speakers. > iBGP requires full mesh interconnection between iBGP speakers, and if > every single router inside an AS runs BGP, then this full mesh would > be pretty hard to maintain. So, route reflectors are then really used > in practice by operators in order to avoid this full mesh? Exactly. Quite a bit of efficiency consideration in the BGP implementation is required for this to work. This is why naive BGP implementations in the mid to late 90s failed so miserably in the ISP lab before even getting to the field (and occasionally new ones continue to do so if they even get that far). > Thanks, > András Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA09752 for ; Fri, 25 Jun 2004 04:40:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdmBC-0007yB-Fz; Fri, 25 Jun 2004 04:35:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdm1E-0005L9-56 for idr@megatron.ietf.org; Fri, 25 Jun 2004 04:25:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16493 for ; Fri, 25 Jun 2004 04:25:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdm1B-0002nx-Sq for idr@ietf.org; Fri, 25 Jun 2004 04:25:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdm0C-0002VK-00 for idr@ietf.org; Fri, 25 Jun 2004 04:24:04 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Bdlzs-0002Cf-00 for idr@ietf.org; Fri, 25 Jun 2004 04:23:44 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5P8NiWR003517 for ; Fri, 25 Jun 2004 10:23:44 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jun 2004 10:23:44 +0200 Received: from lt.eth.ericsson.se (aristotel.eth.ericsson.se [159.107.193.10]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4RL0ZR; Fri, 25 Jun 2004 10:23:44 +0200 Received: from voyager by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id KAA27793; Fri, 25 Jun 2004 10:23:43 +0200 (MET DST) Message-Id: <200406250823.KAA27793@lt.eth.ericsson.se> X-Sybari-Trust: c3613cf5 100f6658 80bc4c27 00000138 From: "=?iso-8859-2?Q?Andr=E1s_Cs=E1sz=E1r_\=28ETH/RL\=29?=" To: Date: Fri, 25 Jun 2004 10:24:17 +0200 Organization: TrafficLab, Ericsson R&D Division MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcRaPgmsrBFY94DUQm2ljjjU6ArIRwASiWlg In-Reply-To: <200406242251.i5OMpx5x031063@workhorse.faster-light.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 25 Jun 2004 08:23:44.0579 (UTC) FILETIME=[BAE6C130:01C45A8D] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=MISSING_OUTLOOK_NAME autolearn=no version=2.60 Subject: [Idr] IGP and BGP 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id EAA09752 > BGP routes are not given to the IGP at all. IBGP is used to pass the > routing information to thw interior of an AS and acrosss the AS. Well, that's interesting. iBGP across AS, sure; that is, between edge nodes (which nodes probably also use eBGP to communicate with neighbour AS router(s)). But iBGP to the interior... To every single router... Does this mean that typically every router is a BGP speaker inside an AS? In practice there are really no interior routers which only run IGP? iBGP requires full mesh interconnection between iBGP speakers, and if every single router inside an AS runs BGP, then this full mesh would be pretty hard to maintain. So, route reflectors are then really used in practice by operators in order to avoid this full mesh? Thanks, András _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA27503 for ; Thu, 24 Jun 2004 19:57:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BddoG-0006oK-1l; Thu, 24 Jun 2004 19:39:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bddgp-0003Qf-8s for idr@megatron.ietf.org; Thu, 24 Jun 2004 19:31:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29879 for ; Thu, 24 Jun 2004 19:31:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BddfX-0006gQ-Eb for idr@ietf.org; Thu, 24 Jun 2004 19:30:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BddSy-0003dn-00 for idr@ietf.org; Thu, 24 Jun 2004 19:17:13 -0400 Received: from relay.pair.com ([209.68.1.20]) by ietf-mx with smtp (Exim 4.12) id 1Bdd5j-0005DI-00 for idr@ietf.org; Thu, 24 Jun 2004 18:53:11 -0400 Received: (qmail 59910 invoked from network); 24 Jun 2004 22:53:11 -0000 Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay.pair.com with SMTP; 24 Jun 2004 22:53:11 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id i5OMpx5x031063; Thu, 24 Jun 2004 18:51:59 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200406242251.i5OMpx5x031063@workhorse.faster-light.net> To: "Andr s Cs sz r \(ETH/RL\)" Subject: Re: [Idr] Loc-Rib and Adj-Rib-In In-reply-to: Your message of "Wed, 23 Jun 2004 09:41:11 +0200." <200406230740.JAA23242@lt.eth.ericsson.se> Date: Thu, 24 Jun 2004 18:51:59 -0400 From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org In message <200406230740.JAA23242@lt.eth.ericsson.se> "Andr s Cs sz r \(ETH/RL\)" writes: > > Sure, yes, I maybe was not precise enough when asking my question. I did not > mean full BGP routes, but only the available destination prefixes (maybe > after route aggregation) reachable through a given BGP egress router. (I > mean interior routers (running IGP only) have to be able to forward traffic > to external prefixes as well, and I'm considering here either a mult-homed > stub or any AS with multiple providers or peering relations.) > > I think reachable prefixes are given to the IGP after they are installed > into Loc-RIB (or even to Adj-RIB-Out?), and only if the given BGP speaker > received the reachable destination prefix UPDATE message through eBGP. > > Am I right? > > András BGP routes are not given to the IGP at all. IBGP is used to pass the routing information to thw interior of an AS and acrosss the AS. The next hop for all BGP routes are looked up in the IGP and the forwarding entry is created based on those two peices of information. Implementation details vary with some optimizations done to reduce the work when the IGP changes (trading off space for a time gain) but the above description is otherwise accurate. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA03854 for ; Thu, 24 Jun 2004 17:18:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdbB1-0002sG-VG; Thu, 24 Jun 2004 16:50:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdYEd-0000gr-0a for idr@megatron.ietf.org; Thu, 24 Jun 2004 13:42:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04527 for ; Thu, 24 Jun 2004 13:42:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdYEb-0000GX-Qg for idr@ietf.org; Thu, 24 Jun 2004 13:42:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdYDA-0007Gw-00 for idr@ietf.org; Thu, 24 Jun 2004 13:40:33 -0400 Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BdYBM-0006UV-00 for idr@ietf.org; Thu, 24 Jun 2004 13:38:40 -0400 Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by mail-white.research.att.com (Postfix) with ESMTP id 64728664056; Thu, 24 Jun 2004 13:38:10 -0400 (EDT) Received: from chips.research.att.com (chips.research.att.com [135.207.27.139]) by mail-blue.research.att.com (Postfix) with ESMTP id 56613F3A8E; Thu, 24 Jun 2004 13:38:10 -0400 (EDT) Received: from chips.research.att.com (localhost [127.0.0.1]) by chips.research.att.com (SGI-8.12.5/8.12.5) with ESMTP id i5OHcAav37399577; Thu, 24 Jun 2004 13:38:10 -0400 (EDT) Received: (from jrex@localhost) by chips.research.att.com (SGI-8.12.5/8.12.5/Submit) id i5OHc97W44847887; Thu, 24 Jun 2004 13:38:09 -0400 (EDT) Date: Thu, 24 Jun 2004 13:38:09 -0400 (EDT) Message-Id: <200406241738.i5OHc97W44847887@chips.research.att.com> From: Jennifer Rexford To: Andras.Csaszar@ericsson.com In-reply-to: <200406230752.JAA24603@lt.eth.ericsson.se> (Andras.Csaszar@ericsson.com) Subject: Re: [Idr] IGP upcall to BGP? X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org > y question: how (and how fast) does BGP learn about IGP cost change? Sure, > IGP link state advertisements at some point reach the given BGP speaker, but > how does this info get to the BGP module? > > Anyway, could you please suggest me good articles/papers about the interface > between IGP (IS-IS/OSPF) and BGP? What timers and processing delays are > involved in both directions? For a recent study of this issue, see Renata Teixeira, Aman Shaikh, Tim Griffin, and Jennifer Rexford, "Dynamics of hot-potato routing in IP networks," Proc. ACM SIGMETRICS, June 2004. http://www.research.att.com/~jrex/papers/sigmetrics04.pdf http://www.research.att.com/~jrex/talks/ima04.ppt http://www.nanog.org/mtg-0402/teixeira.html -- Jen _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA28595 for ; Thu, 24 Jun 2004 13:30:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXJK-0001dT-7r; Thu, 24 Jun 2004 12:42:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd32F-0007Kz-FS for idr@megatron.ietf.org; Wed, 23 Jun 2004 04:23:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05123 for ; Wed, 23 Jun 2004 04:23:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd32D-0004MG-8a for idr@ietf.org; Wed, 23 Jun 2004 04:23:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd2rT-00020W-00 for idr@ietf.org; Wed, 23 Jun 2004 04:12:04 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Bd2Yg-0006T4-00 for idr@ietf.org; Wed, 23 Jun 2004 03:52:38 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5N7qcWR023694 for ; Wed, 23 Jun 2004 09:52:39 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Jun 2004 09:52:38 +0200 Received: from lt.eth.ericsson.se (aristotel.eth.ericsson.se [159.107.193.10]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4QXNJ5; Wed, 23 Jun 2004 09:52:38 +0200 Received: from voyager by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA24603; Wed, 23 Jun 2004 09:52:37 +0200 (MET DST) Message-Id: <200406230752.JAA24603@lt.eth.ericsson.se> X-Sybari-Trust: d323d843 100f6658 44e5f47c 00000138 From: "=?iso-8859-2?Q?Andr=E1s_Cs=E1sz=E1r_\=28ETH/RL\=29?=" To: Date: Wed, 23 Jun 2004 09:53:15 +0200 Organization: TrafficLab, Ericsson R&D Division MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcRY9yOlbbMs1l23RTObws/4BxSUiA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 23 Jun 2004 07:52:38.0895 (UTC) FILETIME=[0E0A77F0:01C458F7] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=MISSING_OUTLOOK_NAME autolearn=no version=2.60 Subject: [Idr] IGP upcall to BGP? 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id NAA28595 draft-ietf-idr-bgp4-24 writes: >> The local speaker MUST determine the immediate next-hop address from the NEXT_HOP attribute of the selected route (see Section 5.1.3). If either the immediate next hop or the IGP cost to the NEXT_HOP (where the NEXT_HOP is resolved through an IGP route) changes, Phase 2 Route Selection MUST be performed again. << Sure, yes, that makes sense since if you have multiple alternative inter-domain routes to a given destination, than it might be possible that the router decided for one of them based on the lowest IGP cost tie breaking rule. So far, so good. But, what happens if there is a fault inside the AS, and the connectivity remains after IGP re-routing but the IGP cost changes. According to the above citation, BGP could then, of course, select a new route. My question: how (and how fast) does BGP learn about IGP cost change? Sure, IGP link state advertisements at some point reach the given BGP speaker, but how does this info get to the BGP module? Anyway, could you please suggest me good articles/papers about the interface between IGP (IS-IS/OSPF) and BGP? What timers and processing delays are involved in both directions? I mean what happens if a BGP speaker receives an UPDATE of a newly reachable destination prefix in an AS which has multiple providers. This info has to get into interior routers via IGP. (For a moment, let's forget about default IGP routes...) Thanks, András _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA28364 for ; Thu, 24 Jun 2004 13:28:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXJE-0001bT-8n; Thu, 24 Jun 2004 12:42:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd2yt-0006ar-Ej for idr@megatron.ietf.org; Wed, 23 Jun 2004 04:19:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04185 for ; Wed, 23 Jun 2004 04:19:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd2yr-0003Ys-0L for idr@ietf.org; Wed, 23 Jun 2004 04:19:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd2kJ-0000zF-00 for idr@ietf.org; Wed, 23 Jun 2004 04:04:40 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1Bd2N3-0004bb-00 for idr@ietf.org; Wed, 23 Jun 2004 03:40:38 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5N7ecPA025965 for ; Wed, 23 Jun 2004 09:40:38 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Jun 2004 09:40:36 +0200 Received: from lt.eth.ericsson.se (aristotel.eth.ericsson.se [159.107.193.10]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA4QXJPR; Wed, 23 Jun 2004 09:40:35 +0200 Received: from voyager by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA23242; Wed, 23 Jun 2004 09:40:35 +0200 (MET DST) Message-Id: <200406230740.JAA23242@lt.eth.ericsson.se> X-Sybari-Trust: 83da6460 100f6658 44e5f47c 00000138 From: "=?iso-8859-2?Q?Andr=E1s_Cs=E1sz=E1r_\=28ETH/RL\=29?=" To: Subject: Re: [Idr] Loc-Rib and Adj-Rib-In Date: Wed, 23 Jun 2004 09:41:11 +0200 Organization: TrafficLab, Ericsson R&D Division MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcRYk0vl4XRhOtoETc2yeeHVVF9YAAAYAbhw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-reply-to: <200406221957.i5MJvjbW020092@workhorse.faster-light.net> X-OriginalArrivalTime: 23 Jun 2004 07:40:36.0113 (UTC) FILETIME=[5F3AB010:01C458F5] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id NAA28364 Sure, yes, I maybe was not precise enough when asking my question. I did not mean full BGP routes, but only the available destination prefixes (maybe after route aggregation) reachable through a given BGP egress router. (I mean interior routers (running IGP only) have to be able to forward traffic to external prefixes as well, and I'm considering here either a mult-homed stub or any AS with multiple providers or peering relations.) I think reachable prefixes are given to the IGP after they are installed into Loc-RIB (or even to Adj-RIB-Out?), and only if the given BGP speaker received the reachable destination prefix UPDATE message through eBGP. Am I right? András ----Original Message---- From: Curtis Villamizar [mailto:curtis@faster-light.net] Sent: 2004. június 22. 21:58 To: Andras Csaszar (ETH/RL) Cc: idr@ietf.org Subject: Re: [Idr] Loc-Rib and Adj-Rib-In > In message <200406220735.JAA09922@lt.eth.ericsson.se> > "Andras Csaszar \(ETH/RL\)" writes: >> >> I would like to ask a related question. When do BGP routes get >> advertised into OSPF? > > > When you want to bring down the network since that's what advertising > anywhere close to full BGP routes into OSPF will do for you. > > Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA27907 for ; Thu, 24 Jun 2004 13:25:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXJ8-0001Yr-FD; Thu, 24 Jun 2004 12:42:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd2vD-0005tZ-RZ for idr@megatron.ietf.org; Wed, 23 Jun 2004 04:15:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03541 for ; Wed, 23 Jun 2004 04:15:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd2vB-0002bJ-Jg for idr@ietf.org; Wed, 23 Jun 2004 04:15:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd2em-0007ME-00 for idr@ietf.org; Wed, 23 Jun 2004 03:58:58 -0400 Received: from ganesh.hcltech.com ([202.54.64.2] helo=ganesh.ctd.hcltech.com) by ietf-mx with esmtp (Exim 4.12) id 1Bd2Ed-0002V0-00 for idr@ietf.org; Wed, 23 Jun 2004 03:31:55 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jun 2004 13:02:09 +0530 Message-ID: <68C9DA8F50019B4E8622C53811BEE1D6011518D9@kavithai.ctd.hcltech.com> From: "Kaliraj V - CTD, Chennai." To: Jeffrey Haas , "Kaliraj V - CTD, Chennai." Subject: RE: [Idr] Loc-Rib and Adj-Rib-In Date: Wed, 23 Jun 2004 13:01:21 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org >This would only be misleading if the MIB stated in its Adj-Rib-Out that it was using a given BGP route. I agree. I guess this is clear. LocRIB is the protocol's view of the best-route. Adj-RIB-out gives the results of policy too(redistribution but-not outbound-routemaps asper MIBv2). SO, in MIBv2 terms: a redistributed route will get into Adj-RIB-In (NLRItable) and will override the LocRIB(bestroute asper LocRIB) to directly enter Adj-RIB-Out (be pointed to by the Rowpointer-object bgpM2AdjRibsOutRoute) for that NLRI prefix. >However, I've recently become aware of a MIB TC that may let us reflect what protocol the route came from. This feels like Good to have information, though not really needed for BGP to know-about. >It really seems that what you want is a Routing Table MIB. Not really, I'm happy with presence of Adj-RIB-Out to tell me what BGP actually used.:) Thanks, Kaliraj. -----Original Message----- From: Jeffrey Haas [mailto:jhaas@nexthop.com] Sent: Wednesday, June 23, 2004 4:57 AM To: Kaliraj V - CTD, Chennai. Cc: idr@ietf.org Subject: Re: [Idr] Loc-Rib and Adj-Rib-In On Tue, Jun 22, 2004 at 09:40:55PM +0530, Kaliraj V - CTD, Chennai. wrote: > Jeff, from your expln I understand LocRIB is viewed as comprising of only > BGP-learnt routes. > > From the MIB view point, the best route is the one in the Loc-Rib. > > But this should be really confusing. Assuming a BGP speaker has, for a > prefix P: a BGP-best route R1(LocRIB) and a redistributed non-BGP route > R2(result-of-Policy); R2 by policy overrides R1. So the speaker is using R2 > and not R1 as reachablity-information for P. Now, if the MIB shows as > best-route the route in the Loc-RIB i.e. R1, then this seems misleading to > me as the speaker is not using this route. This would only be misleading if the MIB stated in its Adj-Rib-Out that it was using a given BGP route. Note that the v2 MIB has added an Adj-Rib-Out table. The contents of this table was contentious when it was added and we have not received consensus as to the contents. > I suggest either R2 be considered part of Loc-RIB or the MIB view-point be > altered so that it is not confined to Loc-RIB. Loc-Rib will contain the BGP Best route. The MIB must reflect this since this is what the BGP specification indicates. This route is then installed in the Routing Table. It is at this point that implementation specific magic happens. As a for example, you could consider your Routing Table as having the ability to learn multiple routes from each protocol that is going to install routes there. Through an internal policy mechanism, the multiple candidate routes will become the Routing Table's active route and that route will presumably be installed in the FIB. This active Routing Table route, when not the same as the Loc-Rib route, is available to BGP for redistribution (and technically origination). The details of how this works and model by which the Routing Table is modeled, is outside the scope of the IDR working group. To do more than to reflect what was sent in BGP via the Adj-Rib-Out table as a BGP route is probably out of scope. However, I've recently become aware of a MIB TC that may let us reflect what protocol the route came from. This will like show up in the next draft of the MIB. It really seems that what you want is a Routing Table MIB. > Kaliraj. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA29801 for ; Tue, 22 Jun 2004 21:04:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcw3L-0006W6-QS; Tue, 22 Jun 2004 20:55:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcvpk-0007WV-O5 for idr@megatron.ietf.org; Tue, 22 Jun 2004 20:41:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17998 for ; Tue, 22 Jun 2004 20:41:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcvpj-0005xv-5h for idr@ietf.org; Tue, 22 Jun 2004 20:41:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcvLL-0000gG-00 for idr@ietf.org; Tue, 22 Jun 2004 20:10:24 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bcv3l-0004jO-01 for idr@ietf.org; Tue, 22 Jun 2004 19:52:13 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bcuqs-0003R2-C7 for idr@ietf.org; Tue, 22 Jun 2004 19:38:54 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 6B6C62D492B; Tue, 22 Jun 2004 19:38:23 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29331-05-60; Tue, 22 Jun 2004 19:38:22 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 4FE322D490A; Tue, 22 Jun 2004 19:38:22 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i5MNcMw02529; Tue, 22 Jun 2004 19:38:22 -0400 (EDT) Date: Tue, 22 Jun 2004 19:38:22 -0400 From: Jeffrey Haas To: "Andras Csaszar (ETH/RL)" Subject: Re: [Idr] Loc-Rib and Adj-Rib-In Message-ID: <20040622233822.GQ12532@nexthop.com> References: <20040621163217.GC12532@nexthop.com> <200406220735.JAA09922@lt.eth.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406220735.JAA09922@lt.eth.ericsson.se> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org On Tue, Jun 22, 2004 at 09:36:17AM +0200, Andras Csaszar (ETH/RL) wrote: > I would like to ask a related question. When do BGP routes get advertised > into OSPF? > > - When received in an UPDATE message? That is, when it gets into Adj-RIB-In? > Or, > - when it gets selected as best-route? That is, when it is put into the > Loc-RIB? Answer number 3: When it becomes the active route in the Routing Table, or some implementation equivalent of this abstraction. > In the second case there is an scenario where a multi-homed stub network > prefers to use one outgoing link with BGP, therefore does not advertise the > other route via OSPF's AS_External_LSA. Now consider that an interor node > looses connectivity to the preferred egress router but otherwise would have > connectivity to the other egress node, but it won't forward traffic to this > egress node since it doesn't know that it accepts outgoing traffic. In a given BGP Autonomous System, each BGP speaker may have a distinct BGP route as the best BGP route. When this is the case, if each of these BGP speakers is an OSPF speaker and these routes are injected into OSPF, you will have multiple candidate AS External routes. There are multiple reasons why a given BGP route may be selected as the best BGP route on multiple BGP speakers. The BGP tie breaking process will show many of them. > Andras -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA29300 for ; Tue, 22 Jun 2004 21:00:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcvsL-0000wE-TU; Tue, 22 Jun 2004 20:44:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcv2a-0002YZ-Sa for idr@megatron.ietf.org; Tue, 22 Jun 2004 19:51:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12972 for ; Tue, 22 Jun 2004 19:50:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcv2Z-0004XY-A4 for idr@ietf.org; Tue, 22 Jun 2004 19:50:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcuq0-0001gS-00 for idr@ietf.org; Tue, 22 Jun 2004 19:38:02 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1Bcug7-00073r-00 for idr@ietf.org; Tue, 22 Jun 2004 19:27:47 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 3921E2D48C9; Tue, 22 Jun 2004 19:27:18 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29547-01-25; Tue, 22 Jun 2004 19:27:16 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 413372D483D; Tue, 22 Jun 2004 19:27:16 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i5MNRGM02117; Tue, 22 Jun 2004 19:27:16 -0400 (EDT) Date: Tue, 22 Jun 2004 19:27:16 -0400 From: Jeffrey Haas To: "Kaliraj V - CTD, Chennai." Subject: Re: [Idr] Loc-Rib and Adj-Rib-In Message-ID: <20040622232716.GP12532@nexthop.com> References: <68C9DA8F50019B4E8622C53811BEE1D601151364@kavithai.ctd.hcltech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68C9DA8F50019B4E8622C53811BEE1D601151364@kavithai.ctd.hcltech.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org On Tue, Jun 22, 2004 at 09:40:55PM +0530, Kaliraj V - CTD, Chennai. wrote: > Jeff, from your expln I understand LocRIB is viewed as comprising of only > BGP-learnt routes. > > From the MIB view point, the best route is the one in the Loc-Rib. > > But this should be really confusing. Assuming a BGP speaker has, for a > prefix P: a BGP-best route R1(LocRIB) and a redistributed non-BGP route > R2(result-of-Policy); R2 by policy overrides R1. So the speaker is using R2 > and not R1 as reachablity-information for P. Now, if the MIB shows as > best-route the route in the Loc-RIB i.e. R1, then this seems misleading to > me as the speaker is not using this route. This would only be misleading if the MIB stated in its Adj-Rib-Out that it was using a given BGP route. Note that the v2 MIB has added an Adj-Rib-Out table. The contents of this table was contentious when it was added and we have not received consensus as to the contents. > I suggest either R2 be considered part of Loc-RIB or the MIB view-point be > altered so that it is not confined to Loc-RIB. Loc-Rib will contain the BGP Best route. The MIB must reflect this since this is what the BGP specification indicates. This route is then installed in the Routing Table. It is at this point that implementation specific magic happens. As a for example, you could consider your Routing Table as having the ability to learn multiple routes from each protocol that is going to install routes there. Through an internal policy mechanism, the multiple candidate routes will become the Routing Table's active route and that route will presumably be installed in the FIB. This active Routing Table route, when not the same as the Loc-Rib route, is available to BGP for redistribution (and technically origination). The details of how this works and model by which the Routing Table is modeled, is outside the scope of the IDR working group. To do more than to reflect what was sent in BGP via the Adj-Rib-Out table as a BGP route is probably out of scope. However, I've recently become aware of a MIB TC that may let us reflect what protocol the route came from. This will like show up in the next draft of the MIB. It really seems that what you want is a Routing Table MIB. > Kaliraj. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA23678 for ; Tue, 22 Jun 2004 20:18:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bctop-0008NY-Vd; Tue, 22 Jun 2004 18:32:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcsBw-0005j5-H4 for idr@megatron.ietf.org; Tue, 22 Jun 2004 16:48:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27449 for ; Tue, 22 Jun 2004 16:48:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcsBv-0002P8-8t for idr@ietf.org; Tue, 22 Jun 2004 16:48:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcsAy-000227-00 for idr@ietf.org; Tue, 22 Jun 2004 16:47:28 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BcsA3-0001KO-00 for idr@ietf.org; Tue, 22 Jun 2004 16:46:31 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i5MKk1907760 for ; Tue, 22 Jun 2004 13:46:01 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i5MKjuJ07538 for ; Tue, 22 Jun 2004 13:45:56 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406222045.i5MKjuJ07538@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <51021.1087937156.1@juniper.net> Date: Tue, 22 Jun 2004 13:45:56 -0700 From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] IDR WG meeting agenda. 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Folks, Please forward any agenda item requests to Sue and myself. Thanks, Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA23143 for ; Tue, 22 Jun 2004 20:14:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bctoj-0008K0-3j; Tue, 22 Jun 2004 18:32:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcrRX-0006zU-Gw for idr@megatron.ietf.org; Tue, 22 Jun 2004 16:00:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24690 for ; Tue, 22 Jun 2004 16:00:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcrRV-00000M-Sf for idr@ietf.org; Tue, 22 Jun 2004 16:00:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcrQc-0007Qx-00 for idr@ietf.org; Tue, 22 Jun 2004 15:59:34 -0400 Received: from relay.pair.com ([209.68.1.20]) by ietf-mx with smtp (Exim 4.12) id 1BcrPh-00072d-00 for idr@ietf.org; Tue, 22 Jun 2004 15:58:37 -0400 Received: (qmail 12351 invoked from network); 22 Jun 2004 19:58:31 -0000 Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay.pair.com with SMTP; 22 Jun 2004 19:58:31 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id i5MJvjbW020092; Tue, 22 Jun 2004 15:57:45 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200406221957.i5MJvjbW020092@workhorse.faster-light.net> To: "Andras Csaszar \(ETH/RL\)" Subject: Re: [Idr] Loc-Rib and Adj-Rib-In In-reply-to: Your message of "Tue, 22 Jun 2004 09:36:17 +0200." <200406220735.JAA09922@lt.eth.ericsson.se> Date: Tue, 22 Jun 2004 15:57:45 -0400 From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org In message <200406220735.JAA09922@lt.eth.ericsson.se> "Andras Csaszar \(ETH/RL\)" writes: > > I would like to ask a related question. When do BGP routes get advertised > into OSPF? When you want to bring down the network since that's what advertising anywhere close to full BGP routes into OSPF will do for you. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA19276 for ; Tue, 22 Jun 2004 19:43:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcto8-0008BN-IC; Tue, 22 Jun 2004 18:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcrP6-0006dz-5T; Tue, 22 Jun 2004 15:58:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24487; Tue, 22 Jun 2004 15:57:57 -0400 (EDT) Message-Id: <200406221957.PAA24487@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Jun 2004 15:57:57 -0400 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-analysis-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: , Sender: idr-bounces@ietf.org 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 : BGP-4 Protocol Analysis Author(s) : D. Meyer, K. Patel Filename : draft-ietf-idr-bgp-analysis-05.txt Pages : 20 Date : 2004-6-22 The purpose of this report is to document how the requirements for advancing a routing protocol from Draft Standard to full Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for'the second report', as described in Section 6.0 of RFC 1264 [RFC1264]. In order to fulfill the requirement, this report augments RFC 1774 [RFC1774] and summarizes the key features of BGP protocol, and analyzes the protocol with respect to scaling and performance. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-analysis-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-bgp-analysis-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-bgp-analysis-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: <2004-6-22152217.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-analysis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-analysis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-22152217.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-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA15750 for ; Tue, 22 Jun 2004 19:11:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BctnE-0007y6-Jn; Tue, 22 Jun 2004 18:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcqHo-0002dN-MQ for idr@megatron.ietf.org; Tue, 22 Jun 2004 14:46:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16608 for ; Tue, 22 Jun 2004 14:46:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcqHm-0004mR-6L for idr@ietf.org; Tue, 22 Jun 2004 14:46:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcq17-0001U0-00 for idr@ietf.org; Tue, 22 Jun 2004 14:29:10 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BcpX9-0003zI-00 for idr@ietf.org; Tue, 22 Jun 2004 13:58:11 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i5MHveBm024543 for ; Tue, 22 Jun 2004 10:57:41 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i5MHveJ67370 for ; Tue, 22 Jun 2004 10:57:40 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406221757.i5MHveJ67370@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14329.1087927060.1@juniper.net> Date: Tue, 22 Jun 2004 10:57:40 -0700 From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] Re: WG Last Call on BGP Graceful Restart 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Folks, Just to add to the attached, the implementation report is in draft-ietf-idr-bgp-gr-survey-01.txt. Yakov. ------- Forwarded Message Date: Thu, 17 Jun 2004 11:36:14 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] WG Last Call on BGP Graceful Restart Folks, This is to start the WG Last Call on advancing draft-ietf-idr-restart-10.txt to a Proposed Standard. Since the the previous version of this document already went through the WG Last Call, the main focus of this Last Call is the new text on Finite State Machine. The Last Call ends July 1, 2004. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA15147 for ; Tue, 22 Jun 2004 19:05:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BctmV-0007ng-15; Tue, 22 Jun 2004 18:30:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcpq1-0006DO-04 for idr@megatron.ietf.org; Tue, 22 Jun 2004 14:17:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11415 for ; Tue, 22 Jun 2004 14:17:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcppz-0007Q9-Pa for idr@ietf.org; Tue, 22 Jun 2004 14:17:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcpEE-0000ph-00 for idr@ietf.org; Tue, 22 Jun 2004 13:38:40 -0400 Received: from ganesh.hcltech.com ([202.54.64.2] helo=ganesh.ctd.hcltech.com) by ietf-mx with esmtp (Exim 4.12) id 1BcnuU-0002q9-00 for idr@ietf.org; Tue, 22 Jun 2004 12:14:10 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jun 2004 21:43:12 +0530 Message-ID: <68C9DA8F50019B4E8622C53811BEE1D601151364@kavithai.ctd.hcltech.com> From: "Kaliraj V - CTD, Chennai." To: Jeffrey Haas , "Kaliraj V - CTD, Chennai." Subject: RE: [Idr] Loc-Rib and Adj-Rib-In Date: Tue, 22 Jun 2004 21:40:55 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Jeff, from your expln I understand LocRIB is viewed as comprising of only BGP-learnt routes. >From the MIB view point, the best route is the one in the Loc-Rib. But this should be really confusing. Assuming a BGP speaker has, for a prefix P: a BGP-best route R1(LocRIB) and a redistributed non-BGP route R2(result-of-Policy); R2 by policy overrides R1. So the speaker is using R2 and not R1 as reachablity-information for P. Now, if the MIB shows as best-route the route in the Loc-RIB i.e. R1, then this seems misleading to me as the speaker is not using this route. I suggest either R2 be considered part of Loc-RIB or the MIB view-point be altered so that it is not confined to Loc-RIB. Thanks, Kaliraj. -----Original Message----- From: Jeffrey Haas [mailto:jhaas@nexthop.com] Sent: Tuesday, June 22, 2004 6:48 PM To: Kaliraj V - CTD, Chennai. Cc: idr@ietf.org Subject: Re: [Idr] Loc-Rib and Adj-Rib-In On Tue, Jun 22, 2004 at 02:23:16PM +0530, Kaliraj V - CTD, Chennai. wrote: > I feel for all practical-puposes a redistributed-route is Best-BGP route, so > it should be seen in the Loc-RIB too. There are two issues with this, IMO: 1. A route that is redistributed into BGP, potentially in preference to a route that is the "best BGP route", is not a BGP route until it is sent to the neighboring BGP peer. The local system will simply treat it as a route from whatever protocol (OSPF, IS-IS, etc.) it came from. 2. While the clarity of getting non-BGP information injected into BGP is a little vague, the processing of BGP routes into the Loc-Rib is quite clear: [draft -24, 9.1.2] : The local speaker SHALL then install that route in the Loc-RIB, : replacing any route to the same destination that is currently being : held in the Loc-RIB. See also draft -24 3.2.2.b > For eg. from the BGP MIB view-point, > we'd like to see the redistributed-BGP route as the Best-BGP route for the > corresponding prefix, even if it has not been advertised to any peers i.e. > not present in Adj-RIB-Out of any peer. Please correct me if wrong. >From the MIB view point, the best route is the one in the Loc-Rib. This probably should have been clarified in the v1 MIB but it can go into the v2 MIB. I don't think we need to backout of last call on the MIB for this clarification. > May be we can imagine a pseudo-RIB-In for these routes, which will not take > part in the BGP-path-selection-process but any competitor available in this > pseudo-RIB-In will override the best-bgp-route selected by the > selection-process. The general problem is that the RIB model is reasonably well suited for BGP-only information with some vagaries as to how information from other protocols is redistributed into BGP. To clarify this, we would need to discuss the details of the Policy Information Base and the Routing Table and that would take us into implementation details we really don't want to have done by IDR. The problem with your suggestion of "any competitor available [...] will overide" is that this is a matter of policy, which is dealt with in the section from my original paste. > Kaliraj. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA12926 for ; Tue, 22 Jun 2004 18:47:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bctkr-00069r-Vl; Tue, 22 Jun 2004 18:28:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcori-0001wo-Lg for idr@megatron.ietf.org; Tue, 22 Jun 2004 13:15:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28352 for ; Tue, 22 Jun 2004 13:15:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcorh-0004SU-K8 for idr@ietf.org; Tue, 22 Jun 2004 13:15:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcn7P-000509-00 for idr@ietf.org; Tue, 22 Jun 2004 11:23:28 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BclFD-00002u-00 for idr@ietf.org; Tue, 22 Jun 2004 09:23:23 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 424622D4826; Tue, 22 Jun 2004 09:22:53 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05240-04; Tue, 22 Jun 2004 09:22:52 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 1F0992D4841; Tue, 22 Jun 2004 09:18:08 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i5MDI5n23309; Tue, 22 Jun 2004 09:18:05 -0400 (EDT) Date: Tue, 22 Jun 2004 09:18:05 -0400 From: Jeffrey Haas To: "Kaliraj V - CTD, Chennai." Subject: Re: [Idr] Loc-Rib and Adj-Rib-In Message-ID: <20040622131805.GG12532@nexthop.com> References: <68C9DA8F50019B4E8622C53811BEE1D60113B0FC@kavithai.ctd.hcltech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68C9DA8F50019B4E8622C53811BEE1D60113B0FC@kavithai.ctd.hcltech.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org On Tue, Jun 22, 2004 at 02:23:16PM +0530, Kaliraj V - CTD, Chennai. wrote: > I feel for all practical-puposes a redistributed-route is Best-BGP route, so > it should be seen in the Loc-RIB too. There are two issues with this, IMO: 1. A route that is redistributed into BGP, potentially in preference to a route that is the "best BGP route", is not a BGP route until it is sent to the neighboring BGP peer. The local system will simply treat it as a route from whatever protocol (OSPF, IS-IS, etc.) it came from. 2. While the clarity of getting non-BGP information injected into BGP is a little vague, the processing of BGP routes into the Loc-Rib is quite clear: [draft -24, 9.1.2] : The local speaker SHALL then install that route in the Loc-RIB, : replacing any route to the same destination that is currently being : held in the Loc-RIB. See also draft -24 3.2.2.b > For eg. from the BGP MIB view-point, > we'd like to see the redistributed-BGP route as the Best-BGP route for the > corresponding prefix, even if it has not been advertised to any peers i.e. > not present in Adj-RIB-Out of any peer. Please correct me if wrong. >From the MIB view point, the best route is the one in the Loc-Rib. This probably should have been clarified in the v1 MIB but it can go into the v2 MIB. I don't think we need to backout of last call on the MIB for this clarification. > May be we can imagine a pseudo-RIB-In for these routes, which will not take > part in the BGP-path-selection-process but any competitor available in this > pseudo-RIB-In will override the best-bgp-route selected by the > selection-process. The general problem is that the RIB model is reasonably well suited for BGP-only information with some vagaries as to how information from other protocols is redistributed into BGP. To clarify this, we would need to discuss the details of the Policy Information Base and the Routing Table and that would take us into implementation details we really don't want to have done by IDR. The problem with your suggestion of "any competitor available [...] will overide" is that this is a matter of policy, which is dealt with in the section from my original paste. > Kaliraj. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA21249 for ; Tue, 22 Jun 2004 09:31:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bckol-0002Uw-LQ; Tue, 22 Jun 2004 08:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bch3w-0002Wz-Oy for idr@megatron.ietf.org; Tue, 22 Jun 2004 04:55:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18829 for ; Tue, 22 Jun 2004 04:55:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bch3u-0004UD-FT for idr@ietf.org; Tue, 22 Jun 2004 04:55:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bch2x-0004Ah-00 for idr@ietf.org; Tue, 22 Jun 2004 04:54:28 -0400 Received: from ganesh.hcltech.com ([202.54.64.2] helo=ganesh.ctd.hcltech.com) by ietf-mx with esmtp (Exim 4.12) id 1Bch2U-0003qb-00 for idr@ietf.org; Tue, 22 Jun 2004 04:53:58 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jun 2004 14:23:07 +0530 Message-ID: <68C9DA8F50019B4E8622C53811BEE1D60113B0FC@kavithai.ctd.hcltech.com> From: "Kaliraj V - CTD, Chennai." To: Jeffrey Haas , John Smith Subject: RE: [Idr] Loc-Rib and Adj-Rib-In Date: Tue, 22 Jun 2004 14:23:16 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org >IMO, this would imply that a redistributed route enters directly into >the Adj-Rib-Out of a peer potentially in preference to the best selected >bgp route. I feel for all practical-puposes a redistributed-route is Best-BGP route, so it should be seen in the Loc-RIB too. For eg. from the BGP MIB view-point, we'd like to see the redistributed-BGP route as the Best-BGP route for the corresponding prefix, even if it has not been advertised to any peers i.e. not present in Adj-RIB-Out of any peer. Please correct me if wrong. > The routes that we receive from our peers are placed in the "Adj-Rib-In". What about the > routes that are redistributed (static/RIP/ISIS/OSPF/etc) in BGP? May be we can imagine a pseudo-RIB-In for these routes, which will not take part in the BGP-path-selection-process but any competitor available in this pseudo-RIB-In will override the best-bgp-route selected by the selection-process. Kaliraj. -----Original Message----- From: Jeffrey Haas [mailto:jhaas@nexthop.com] Sent: Monday, June 21, 2004 10:02 PM To: John Smith Cc: idr@ietf.org Subject: Re: [Idr] Loc-Rib and Adj-Rib-In On Fri, Jun 18, 2004 at 10:29:59AM +0100, John Smith wrote: > Consider an instance where BGP is redistributing OSPF routes in it. BGP runs its decision > process and finds that these are the best routes and that it needs to announce them to > its peers. From a purist's language, will these routes now be placed in the "Loc-Rib" ? > > The routes that we receive from our peers are placed in the "Adj-Rib-In". What about the > routes that are redistributed (static/RIP/ISIS/OSPF/etc) in BGP? It is intentionally hand-waved in the specification. The closest reference you will find to such a thing (from draft -23): All routes in the Loc-RIB are processed into Adj-RIBs-Out according to configured policy. This policy MAY exclude a route in the Loc-RIB from being installed in a particular Adj-RIB-Out. A route SHALL NOT be installed in the Adj-Rib-Out unless the destination and NEXT_HOP described by this route may be forwarded appropriately by the Routing Table. If a route in Loc-RIB is excluded from a particular Adj-RIB- Out the previously advertised route in that Adj-RIB-Out MUST be with- drawn from service by means of an UPDATE message (see 9.2). IMO, this would imply that a redistributed route enters directly into the Adj-Rib-Out of a peer potentially in preference to the best selected bgp route. >From the BGP MIB standpoint, just because a route is the best bgp route doesn't mean we expect to see it in the adj-rib-out. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA20630 for ; Tue, 22 Jun 2004 09:25:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BckoH-0002LP-8q; Tue, 22 Jun 2004 08:55:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcfqK-0008C6-K6 for idr@megatron.ietf.org; Tue, 22 Jun 2004 03:37:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14243 for ; Tue, 22 Jun 2004 03:37:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcfqI-0003P2-DD for idr@ietf.org; Tue, 22 Jun 2004 03:37:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcfpP-00036q-00 for idr@ietf.org; Tue, 22 Jun 2004 03:36:24 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1Bcfon-0002oB-00 for idr@ietf.org; Tue, 22 Jun 2004 03:35:46 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5M7ZkPA002391 for ; Tue, 22 Jun 2004 09:35:46 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 22 Jun 2004 09:35:46 +0200 Received: from lt.eth.ericsson.se (aristotel.eth.ericsson.se [159.107.193.10]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MATN7Q22; Tue, 22 Jun 2004 09:35:45 +0200 Received: from voyager by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA09922; Tue, 22 Jun 2004 09:35:44 +0200 (MET DST) Message-Id: <200406220735.JAA09922@lt.eth.ericsson.se> X-Sybari-Trust: 8ea29947 2335e436 0db66a51 00000139 From: "=?us-ascii?Q?Andras_Csaszar_\=28ETH/RL\=29?=" To: Subject: RE: [Idr] Loc-Rib and Adj-Rib-In Date: Tue, 22 Jun 2004 09:36:17 +0200 Organization: TrafficLab, Ericsson R&D Division MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcRXxqb9GDJWUC8QQGaf3J4DSfVqkAAYzUnA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040621163217.GC12532@nexthop.com> X-OriginalArrivalTime: 22 Jun 2004 07:35:46.0351 (UTC) FILETIME=[881AC3F0:01C4582B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hi! I would like to ask a related question. When do BGP routes get advertised into OSPF? - When received in an UPDATE message? That is, when it gets into Adj-RIB-In? Or, - when it gets selected as best-route? That is, when it is put into the Loc-RIB? In the first case, I think it's hard to ensure that OSPF uses the same routes as BGP thinks. Although it might be possible by setting the OSPF metrics appropriately. (?) In the second case there is an scenario where a multi-homed stub network prefers to use one outgoing link with BGP, therefore does not advertise the other route via OSPF's AS_External_LSA. Now consider that an interor node looses connectivity to the preferred egress router but otherwise would have connectivity to the other egress node, but it won't forward traffic to this egress node since it doesn't know that it accepts outgoing traffic. Anyway, in this case how will this interior node ever learn about this route? (I mean, the two egress nodes running BGP still prefer the first egress link, even though some interior nodes can't access it any longer.) Am I missing something, or which one is right? Thanks, Andras ----Original Message---- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: 2004. junius 21. 18:32 To: John Smith Cc: idr@ietf.org Subject: Re: [Idr] Loc-Rib and Adj-Rib-In > On Fri, Jun 18, 2004 at 10:29:59AM +0100, John Smith wrote: >> Consider an instance where BGP is redistributing OSPF routes in it. >> BGP runs its decision process and finds that these are the best >> routes and that it needs to announce them to its peers. From a >> purist's language, will these routes now be placed in the "Loc-Rib" >> ? >> >> The routes that we receive from our peers are placed in the >> "Adj-Rib-In". What about the routes that are redistributed >> (static/RIP/ISIS/OSPF/etc) in BGP? > > It is intentionally hand-waved in the specification. The closest > reference you will find to such a thing (from draft -23): > > All routes in the Loc-RIB are processed into Adj-RIBs-Out according > to configured policy. This policy MAY exclude a route in the > Loc-RIB from being installed in a particular Adj-RIB-Out. A route > SHALL NOT be installed in the Adj-Rib-Out unless the destination > and NEXT_HOP described by this route may be forwarded > appropriately by the Routing Table. If a route in Loc-RIB is > excluded from a particular Adj-RIB- Out the previously advertised > route in that Adj-RIB-Out MUST be with- drawn from service by > means of an UPDATE message (see 9.2). > > IMO, this would imply that a redistributed route enters directly into > the Adj-Rib-Out of a peer potentially in preference to the best > selected > bgp route. > >> From the BGP MIB standpoint, just because a route is the best bgp >> route > doesn't mean we expect to see it in the adj-rib-out. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA25073 for ; Mon, 21 Jun 2004 15:33:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcUMS-0007lB-Hr; Mon, 21 Jun 2004 15:21:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcSQH-0003L0-4f for idr@megatron.ietf.org; Mon, 21 Jun 2004 13:17:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07015 for ; Mon, 21 Jun 2004 13:17:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcSQG-0006n8-38 for idr@ietf.org; Mon, 21 Jun 2004 13:17:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcSBl-00040g-00 for idr@ietf.org; Mon, 21 Jun 2004 13:02:34 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BcRky-00004m-00 for idr@ietf.org; Mon, 21 Jun 2004 12:34:52 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9A6FE2D4849; Mon, 21 Jun 2004 12:34:17 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 59334-03-55; Mon, 21 Jun 2004 12:34:15 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D3B952D4923; Mon, 21 Jun 2004 12:32:17 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i5LGWH614550; Mon, 21 Jun 2004 12:32:17 -0400 (EDT) Date: Mon, 21 Jun 2004 12:32:17 -0400 From: Jeffrey Haas To: John Smith Subject: Re: [Idr] Loc-Rib and Adj-Rib-In Message-ID: <20040621163217.GC12532@nexthop.com> References: <20040618092959.60294.qmail@web25306.mail.ukl.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040618092959.60294.qmail@web25306.mail.ukl.yahoo.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org On Fri, Jun 18, 2004 at 10:29:59AM +0100, John Smith wrote: > Consider an instance where BGP is redistributing OSPF routes in it. BGP runs its decision > process and finds that these are the best routes and that it needs to announce them to > its peers. From a purist's language, will these routes now be placed in the "Loc-Rib" ? > > The routes that we receive from our peers are placed in the "Adj-Rib-In". What about the > routes that are redistributed (static/RIP/ISIS/OSPF/etc) in BGP? It is intentionally hand-waved in the specification. The closest reference you will find to such a thing (from draft -23): All routes in the Loc-RIB are processed into Adj-RIBs-Out according to configured policy. This policy MAY exclude a route in the Loc-RIB from being installed in a particular Adj-RIB-Out. A route SHALL NOT be installed in the Adj-Rib-Out unless the destination and NEXT_HOP described by this route may be forwarded appropriately by the Routing Table. If a route in Loc-RIB is excluded from a particular Adj-RIB- Out the previously advertised route in that Adj-RIB-Out MUST be with- drawn from service by means of an UPDATE message (see 9.2). IMO, this would imply that a redistributed route enters directly into the Adj-Rib-Out of a peer potentially in preference to the best selected bgp route. >From the BGP MIB standpoint, just because a route is the best bgp route doesn't mean we expect to see it in the adj-rib-out. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA00392 for ; Fri, 18 Jun 2004 11:23:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbL62-0007jY-MS; Fri, 18 Jun 2004 11:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbL24-0006Tg-7h for idr@megatron.ietf.org; Fri, 18 Jun 2004 11:11:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29500 for ; Fri, 18 Jun 2004 11:11:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbL23-0004gY-Bd for idr@ietf.org; Fri, 18 Jun 2004 11:11:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbL15-0004Ja-00 for idr@ietf.org; Fri, 18 Jun 2004 11:10:56 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BbL08-0003bN-00 for idr@ietf.org; Fri, 18 Jun 2004 11:09:56 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i5IF9Q970437 for ; Fri, 18 Jun 2004 08:09:26 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i5IF9LJ25180 for ; Fri, 18 Jun 2004 08:09:21 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406181509.i5IF9LJ25180@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <63475.1087571361.1@juniper.net> Date: Fri, 18 Jun 2004 08:09:21 -0700 From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] draft-ietf-idr-bgp4-24.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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Folks, In response to the comments received during the IESG Last Call here is the list of changes: 1. Added missing text to 5.1.2 (see my e-mail on Thu, 03 Jun 2004 06:50:19 PDT). 2. Added new text to the Security Consideration section (see my e-mail on Mon, 24 May 2004 07:32:55 PDT) 3. Fix text in 9.1.4 (see e-mail from Andrew Lange on Mon, 23 Feb 2004 09:22:37 PST) 4. Replace normative text with non-normative text in Appendix F (see my e-mail on Sun, 22 Feb 2004 11:56:49 PST) 5. Make all references to events as "Event NN" (in the -23 version some events have been referenced as "Event NN" while others as "EventNN"). Care was taken to avoid splitting "Event NN" across multiple lines. Yakov. ------- Forwarded Message Date: Thu, 17 Jun 2004 11:18:46 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-24.txt - --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 : A Border Gateway Protocol 4 (BGP-4) Author(s) : Y. Rekhter, S. Hares Filename : draft-ietf-idr-bgp4-24.txt Pages : 99 Date : 2004-6-17 The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protoco l. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASs) that reachability information traverses. This information is sufficient to construct a graph of AS connectivity for this reachability from which routing loops may be pruned and some policy decisions at the AS level may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network 'class' within BGP. BGP-4 also introduces mechanisms which allow aggregation of routes, including aggregation of AS paths. Routing information exchanged via BGP supports only the destination- based forwarding paradigm, which assumes that a router forwards a packet based solely on the destination address carried in the IP header of the packet. This, in turn, reflects the set of policy decisions that can (and can not) be enforced using BGP. BGP can support only the policies conforming to the destination-based forwarding paradigm. This specification covers only the exchange of IP version 4 network reachability information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-24.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 mess age. 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-bgp4-24.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-bgp4-24.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-17113646.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-24.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-24.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-17113646.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-- ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA00188 for ; Fri, 18 Jun 2004 05:46:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbFrE-0000Wt-4I; Fri, 18 Jun 2004 05:40:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbFjm-0007IB-ES for idr@megatron.ietf.org; Fri, 18 Jun 2004 05:32:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09186 for ; Fri, 18 Jun 2004 05:32:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbFjg-000147-97 for idr@ietf.org; Fri, 18 Jun 2004 05:32:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbFig-0000iJ-00 for idr@ietf.org; Fri, 18 Jun 2004 05:31:35 -0400 Received: from web25306.mail.ukl.yahoo.com ([217.12.10.78]) by ietf-mx with smtp (Exim 4.12) id 1BbFhc-00002B-00 for idr@ietf.org; Fri, 18 Jun 2004 05:30:28 -0400 Message-ID: <20040618092959.60294.qmail@web25306.mail.ukl.yahoo.com> Received: from [202.144.106.188] by web25306.mail.ukl.yahoo.com via HTTP; Fri, 18 Jun 2004 10:29:59 BST Date: Fri, 18 Jun 2004 10:29:59 +0100 (BST) From: =?iso-8859-1?q?John=20Smith?= To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Subject: [Idr] Loc-Rib and Adj-Rib-In 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hi, Consider an instance where BGP is redistributing OSPF routes in it. BGP runs its decision process and finds that these are the best routes and that it needs to announce them to its peers. From a purist's language, will these routes now be placed in the "Loc-Rib" ? The routes that we receive from our peers are placed in the "Adj-Rib-In". What about the routes that are redistributed (static/RIP/ISIS/OSPF/etc) in BGP? Thanks, Smith ___________________________________________________________ALL-NEW Yahoo! Messenger - sooooo many all-new ways to express yourself http://uk.messenger.yahoo.com _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA01814 for ; Thu, 17 Jun 2004 15:06:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb1uH-0003aC-Uv; Thu, 17 Jun 2004 14:46:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb1oC-000089-TA for idr@megatron.ietf.org; Thu, 17 Jun 2004 14:40:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03477 for ; Thu, 17 Jun 2004 14:40:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb1oB-00032V-D4 for idr@ietf.org; Thu, 17 Jun 2004 14:40:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb1mf-0002MD-00 for idr@ietf.org; Thu, 17 Jun 2004 14:38:46 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1Bb1ki-0001f3-00 for idr@ietf.org; Thu, 17 Jun 2004 14:36:44 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i5HIaEBm092031 for ; Thu, 17 Jun 2004 11:36:14 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i5HIaEJ68379 for ; Thu, 17 Jun 2004 11:36:14 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406171836.i5HIaEJ68379@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <90385.1087497374.1@juniper.net> Date: Thu, 17 Jun 2004 11:36:14 -0700 From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] WG Last Call on BGP Graceful Restart 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Folks, This is to start the WG Last Call on advancing draft-ietf-idr-restart-10.txt to a Proposed Standard. Since the the previous version of this document already went through the WG Last Call, the main focus of this Last Call is the new text on Finite State Machine. The Last Call ends July 1, 2004. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA14863 for ; Thu, 17 Jun 2004 12:14:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Baymz-0005p0-NF; Thu, 17 Jun 2004 11:26:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BayfA-0003CU-SP; Thu, 17 Jun 2004 11:18:48 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09293; Thu, 17 Jun 2004 11:18:46 -0400 (EDT) Message-Id: <200406171518.LAA09293@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 17 Jun 2004 11:18:46 -0400 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-24.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: , Sender: idr-bounces@ietf.org 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 : A Border Gateway Protocol 4 (BGP-4) Author(s) : Y. Rekhter, S. Hares Filename : draft-ietf-idr-bgp4-24.txt Pages : 99 Date : 2004-6-17 The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASs) that reachability information traverses. This information is sufficient to construct a graph of AS connectivity for this reachability from which routing loops may be pruned and some policy decisions at the AS level may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network 'class' within BGP. BGP-4 also introduces mechanisms which allow aggregation of routes, including aggregation of AS paths. Routing information exchanged via BGP supports only the destination- based forwarding paradigm, which assumes that a router forwards a packet based solely on the destination address carried in the IP header of the packet. This, in turn, reflects the set of policy decisions that can (and can not) be enforced using BGP. BGP can support only the policies conforming to the destination-based forwarding paradigm. This specification covers only the exchange of IP version 4 network reachability information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-24.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-bgp4-24.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-bgp4-24.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-17113646.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-24.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-24.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-17113646.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-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA06125 for ; Wed, 16 Jun 2004 12:12:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BacWB-0000pJ-Pe; Wed, 16 Jun 2004 11:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BacLX-00046G-TA for idr@megatron.ietf.org; Wed, 16 Jun 2004 11:29:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08763 for ; Wed, 16 Jun 2004 11:29:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BacLT-0001s0-UU for idr@ietf.org; Wed, 16 Jun 2004 11:29:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BabaS-00025m-00 for idr@ietf.org; Wed, 16 Jun 2004 10:40:25 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BaahC-0001Xl-00; Wed, 16 Jun 2004 09:43:18 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BaZoh-0001Jp-38; Wed, 16 Jun 2004 08:46:59 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i5GCjA957401; Wed, 16 Jun 2004 05:45:10 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i5GCj4J76396; Wed, 16 Jun 2004 05:45:04 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406161245.i5GCj4J76396@merlot.juniper.net> To: zinin@psg.com, fenner@research.att.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12695.1087389904.1@juniper.net> Date: Wed, 16 Jun 2004 05:45:04 -0700 From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: skh@nexthop.com, idr@ietf.org, iesg-secretary@ietf.org, yakov@juniper.net Subject: [Idr] rfc1863 to historic 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Alex and Bill, The IDR WG would like to ask the IESG to publish draft-ietf-idr-rfc1863-historic-00.txt as an Informational RFC. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA21911 for ; Mon, 14 Jun 2004 12:33:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZtu2-0000ID-Fy; Mon, 14 Jun 2004 12:01:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZYvq-00020Q-SF for idr@megatron.ietf.org; Sun, 13 Jun 2004 13:38:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24399 for ; Sun, 13 Jun 2004 13:38:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZYvp-0002Lg-Rk for idr@ietf.org; Sun, 13 Jun 2004 13:38:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZYux-00028S-00 for idr@ietf.org; Sun, 13 Jun 2004 13:37:16 -0400 Received: from av7-2-sn4.m-sp.skanova.net ([81.228.10.109]) by ietf-mx with esmtp (Exim 4.12) id 1BZYuG-0001nZ-00 for idr@ietf.org; Sun, 13 Jun 2004 13:36:32 -0400 Received: by av7-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 7DDD837EDA; Sun, 13 Jun 2004 19:36:01 +0200 (CEST) Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av7-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 6EA6337E4F for ; Sun, 13 Jun 2004 19:36:01 +0200 (CEST) Received: from pi.se (h178n2fls307o1033.telia.com [81.226.61.178]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 56CD837E46 for ; Sun, 13 Jun 2004 19:36:01 +0200 (CEST) Message-ID: <40CC9072.5090107@pi.se> Date: Sun, 13 Jun 2004 19:35:46 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 14 Jun 2004 12:01:41 -0400 Subject: [Idr] MPLS2004 Conference Call for Presentations 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org The MPLS2004 Conference will be held in Washington DC, from October 17 to October 19, 2004. This year's conference will include, but will not be limited, to the following topics: - Network Consolidation and Service Convergence - Traffic engineering and QoS - MPLS network operation, administration, and maintenance - OSS Systems for MPLS-based networks - MPLS Multicast - Service Provisioning - MPLS in multi-AS networks - L2VPNs (pseudo-wire emulation, VPWS, VPLS, and others) - L3VPNs (BGP/MPLS, IPSec interworking, virtual routers, and others) - Voice, video, and real-time services over MPLS networks - Scalability and performance of MPLS protocols and networks - Network processor architectures for next generation MPLS networks - MPLS certification, verification, and conformance testing - MPLS network security - MPLS reliability and survivability (fast reroute, graceful restart, and restoration techniques) - IP Optical Integration - Multilayer control, management, and optimization - MPLS deployment case studies: Service Provider operational experience The Program Committee for MPLS2004 is soliciting presentation proposals for this conference. If you wish to propose a particular topic for consideration, please send a one page summary, including speaker's name, affiliation, and contact information to the Technical Program Committee at: MPLS2004-CFP@isocore.com All proposals must be received by June 18, 2004. See http://www.mpls2004.com for more details. The program committee is looking for original and unpublished work to continue the tradition of addressing cutting-edge topics that was initiated by this conference in 1998. Presentations from the vendor, service provider, research, and user communities covering technology evolution and operational experience are solicited. -- Loa Andersson mobile +46 739 81 21 64 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA07646 for ; Wed, 9 Jun 2004 16:37:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY8xU-0000rH-CH; Wed, 09 Jun 2004 15:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY8qC-0006fr-6n; Wed, 09 Jun 2004 15:34:28 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13066; Wed, 9 Jun 2004 15:34:20 -0400 (EDT) Message-Id: <200406091934.PAA13066@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 09 Jun 2004 15:34:20 -0400 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-restart-10.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: , Sender: idr-bounces@ietf.org 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 : Graceful Restart Mechanism for BGP Author(s) : S. Sangli, et al. Filename : draft-ietf-idr-restart-10.txt Pages : 11 Date : 2004-6-9 This document proposes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed 'Graceful Restart Capability', is defined which would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP transport reset. The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-10.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-restart-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-restart-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-9152911.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-restart-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-restart-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-9152911.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-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA22526 for ; Wed, 9 Jun 2004 00:08:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXu4F-0003Qd-Em; Tue, 08 Jun 2004 23:47:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXtsx-0004rr-1p for idr@megatron.ietf.org; Tue, 08 Jun 2004 23:36:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23553 for ; Tue, 8 Jun 2004 23:36:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXtst-0005ut-Nh for idr@ietf.org; Tue, 08 Jun 2004 23:36:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXtro-00053u-00 for idr@ietf.org; Tue, 08 Jun 2004 23:35:09 -0400 Received: from relay.pair.com ([209.68.1.20]) by ietf-mx with smtp (Exim 4.12) id 1BXtpU-0003gO-00 for idr@ietf.org; Tue, 08 Jun 2004 23:32:44 -0400 Received: (qmail 77942 invoked from network); 9 Jun 2004 03:32:45 -0000 Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay.pair.com with SMTP; 9 Jun 2004 03:32:45 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id i593UYXp060258; Tue, 8 Jun 2004 23:30:34 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200406090330.i593UYXp060258@workhorse.faster-light.net> To: Tony Li Subject: Re: [Idr] pref-limit - one more update In-reply-to: Your message of "Tue, 08 Jun 2004 20:03:33 PDT." <97CD7530-B9C1-11D8-ACAB-000A95D1475E@tony.li> Date: Tue, 08 Jun 2004 23:30:33 -0400 From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: Yakov Rekhter , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org In message <97CD7530-B9C1-11D8-ACAB-000A95D1475E@tony.li> Tony Li writes: > > > I agree that it's very rough, especially when you factor out the > authors. > > So, a couple of other suggestions: a) consult the "routing > directorate" or b) consult the AD's "subject area expert". > > Tony Tony, Think about how that statement would have sounded 10 years ago. The answer would have been an immediate "go write some code and come back here when/if someone deploys it". If this is provider driven even if driven by a subset of providers, it won't matter that the IETF has to say the implementations will happen. If this is a big yawn to most providers, it also won't matter what the IETF has to say because the implementations if they happen at all won't be deployed. Curtis > On Jun 8, 2004, at 6:36 PM, Curtis Villamizar wrote: > > > > > In message <200406082343.i58Nh1J53611@merlot.juniper.net> > > Yakov Rekhter writes: > >> > >> Folks, > >> > >> One more correction - attached is the updated list. > >> > >> Yakov. > > > > > > Yakov, > > > > Consensus looks a bit too rough. In the old days we used to wait for > > running code in this situation and factor that in. Just a suggestion. > > Saves a lot of arguing. > > > > Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA20253 for ; Tue, 8 Jun 2004 23:42:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXtmF-0003dO-EG; Tue, 08 Jun 2004 23:29:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXtSi-0006b1-G4 for idr@megatron.ietf.org; Tue, 08 Jun 2004 23:09:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22254 for ; Tue, 8 Jun 2004 23:08:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXtSQ-0004GC-QT for idr@ietf.org; Tue, 08 Jun 2004 23:08:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXtPw-00035y-00 for idr@ietf.org; Tue, 08 Jun 2004 23:06:22 -0400 Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1BXtNk-0000cE-00 for idr@ietf.org; Tue, 08 Jun 2004 23:04:04 -0400 Received: from [192.168.1.3] (c-24-5-4-40.client.comcast.net[24.5.4.40]) by comcast.net (sccrmhc13) with SMTP id <200406090303300160086197e> (Authid: li.tony); Wed, 9 Jun 2004 03:03:31 +0000 In-Reply-To: <200406090136.i591aiGU057806@workhorse.faster-light.net> References: <200406090136.i591aiGU057806@workhorse.faster-light.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <97CD7530-B9C1-11D8-ACAB-000A95D1475E@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] pref-limit - one more update Date: Tue, 8 Jun 2004 20:03:33 -0700 To: curtis@faster-light.net X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: Yakov Rekhter , 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org I agree that it's very rough, especially when you factor out the authors. So, a couple of other suggestions: a) consult the "routing directorate" or b) consult the AD's "subject area expert". Tony On Jun 8, 2004, at 6:36 PM, Curtis Villamizar wrote: > > In message <200406082343.i58Nh1J53611@merlot.juniper.net> > Yakov Rekhter writes: >> >> Folks, >> >> One more correction - attached is the updated list. >> >> Yakov. > > > Yakov, > > Consensus looks a bit too rough. In the old days we used to wait for > running code in this situation and factor that in. Just a suggestion. > Saves a lot of arguing. > > Curtis > > > > ----------------------------------------------------------------- > Accept Signalled Pref-limit as work item: > > Yes: > Vincent Gillet > Jeffrey Haas > Enke Chen > Eric Rosen > Curtis Villamizar > Sun Tao > Gerald Ash > Robert Raszuk > Srikanth Chavali (author) > Vasile Radoaca (author) > Mo Miri (author) > Luyuan Fan (author) > Susan Hares (author) > Keyur Patel (author) > Chandra Appanna (author) > John Scudder (author) > > No: > Vivek Menezes > Pekka Savola > Parantap Lahiri > Tony Li > Enrico Salazar > Pedro Roque Marques > Kurt Erik Lindqvist > > Accept draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document Yes: > > Vincent Gillet > Gerald Ash > Srikanth Chavali (author) > Vasile Radoaca (author) > Mo Miri (author) > Luyuan Fan (author) > Susan Hares (author) > > Accept draft-keyur-prefixlimit-orf-00.txt as an IDR WG document Yes: > > Enke Chen > Eric Rosen > Sun Tao > Robert Raszuk > Keyur Patel (author) > Chandra Appanna (author) > John Scudder (author) > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA10939 for ; Tue, 8 Jun 2004 21:51:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXsC0-0004Df-8c; Tue, 08 Jun 2004 21:47:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXs5P-0001Bk-KN for idr@megatron.ietf.org; Tue, 08 Jun 2004 21:41:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17502 for ; Tue, 8 Jun 2004 21:41:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXs5N-0001jz-M0 for idr@ietf.org; Tue, 08 Jun 2004 21:41:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXs4I-0000sc-00 for idr@ietf.org; Tue, 08 Jun 2004 21:39:55 -0400 Received: from relay.pair.com ([209.68.1.20]) by ietf-mx with smtp (Exim 4.12) id 1BXs3O-0007jl-00 for idr@ietf.org; Tue, 08 Jun 2004 21:38:59 -0400 Received: (qmail 42117 invoked from network); 9 Jun 2004 01:38:54 -0000 Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay.pair.com with SMTP; 9 Jun 2004 01:38:54 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id i591aiGU057806; Tue, 8 Jun 2004 21:36:44 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200406090136.i591aiGU057806@workhorse.faster-light.net> To: Yakov Rekhter Subject: Re: [Idr] pref-limit - one more update In-reply-to: Your message of "Tue, 08 Jun 2004 16:43:01 PDT." <200406082343.i58Nh1J53611@merlot.juniper.net> Date: Tue, 08 Jun 2004 21:36:44 -0400 From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org In message <200406082343.i58Nh1J53611@merlot.juniper.net> Yakov Rekhter writes: > > Folks, > > One more correction - attached is the updated list. > > Yakov. Yakov, Consensus looks a bit too rough. In the old days we used to wait for running code in this situation and factor that in. Just a suggestion. Saves a lot of arguing. Curtis ----------------------------------------------------------------- Accept Signalled Pref-limit as work item: Yes: Vincent Gillet Jeffrey Haas Enke Chen Eric Rosen Curtis Villamizar Sun Tao Gerald Ash Robert Raszuk Srikanth Chavali (author) Vasile Radoaca (author) Mo Miri (author) Luyuan Fan (author) Susan Hares (author) Keyur Patel (author) Chandra Appanna (author) John Scudder (author) No: Vivek Menezes Pekka Savola Parantap Lahiri Tony Li Enrico Salazar Pedro Roque Marques Kurt Erik Lindqvist Accept draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document Yes: Vincent Gillet Gerald Ash Srikanth Chavali (author) Vasile Radoaca (author) Mo Miri (author) Luyuan Fan (author) Susan Hares (author) Accept draft-keyur-prefixlimit-orf-00.txt as an IDR WG document Yes: Enke Chen Eric Rosen Sun Tao Robert Raszuk Keyur Patel (author) Chandra Appanna (author) John Scudder (author) _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA02851 for ; Tue, 8 Jun 2004 20:13:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXqUd-0004G6-Bs; Tue, 08 Jun 2004 19:58:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXqI9-0006js-Rj for idr@megatron.ietf.org; Tue, 08 Jun 2004 19:46:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10076 for ; Tue, 8 Jun 2004 19:46:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXqI8-0006Nl-3l for idr@ietf.org; Tue, 08 Jun 2004 19:46:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXqGv-0005Tw-00 for idr@ietf.org; Tue, 08 Jun 2004 19:44:50 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BXqFe-0003mj-00 for idr@ietf.org; Tue, 08 Jun 2004 19:43:30 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i58Nh1Bm047783 for ; Tue, 8 Jun 2004 16:43:01 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i58Nh1J53611 for ; Tue, 8 Jun 2004 16:43:01 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406082343.i58Nh1J53611@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7093.1086738181.1@juniper.net> Date: Tue, 08 Jun 2004 16:43:01 -0700 From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] pref-limit - one more update 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Folks, One more correction - attached is the updated list. Yakov. ----------------------------------------------------------------- Accept Signalled Pref-limit as work item: Yes: Vincent Gillet Jeffrey Haas Enke Chen Eric Rosen Curtis Villamizar Sun Tao Gerald Ash Robert Raszuk Srikanth Chavali (author) Vasile Radoaca (author) Mo Miri (author) Luyuan Fan (author) Susan Hares (author) Keyur Patel (author) Chandra Appanna (author) John Scudder (author) No: Vivek Menezes Pekka Savola Parantap Lahiri Tony Li Enrico Salazar Pedro Roque Marques Kurt Erik Lindqvist Accept draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document Yes: Vincent Gillet Gerald Ash Srikanth Chavali (author) Vasile Radoaca (author) Mo Miri (author) Luyuan Fan (author) Susan Hares (author) Accept draft-keyur-prefixlimit-orf-00.txt as an IDR WG document Yes: Enke Chen Eric Rosen Sun Tao Robert Raszuk Keyur Patel (author) Chandra Appanna (author) John Scudder (author) _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA24106 for ; Tue, 8 Jun 2004 18:45:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXpCH-0006hT-BT; Tue, 08 Jun 2004 18:35:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXoI6-0004MD-Fl for idr@megatron.ietf.org; Tue, 08 Jun 2004 17:37:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25459 for ; Tue, 8 Jun 2004 17:37:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXoI5-0001qh-0L for idr@ietf.org; Tue, 08 Jun 2004 17:37:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXoFh-0000fn-00 for idr@ietf.org; Tue, 08 Jun 2004 17:35:26 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BXoCs-0006eO-00 for idr@ietf.org; Tue, 08 Jun 2004 17:32:30 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i58LW0Bm047406 for ; Tue, 8 Jun 2004 14:32:00 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i58LW0J33204 for ; Tue, 8 Jun 2004 14:32:00 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406082132.i58LW0J33204@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <82701.1086730320.1@juniper.net> Date: Tue, 08 Jun 2004 14:32:00 -0700 From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] pref-limit comments 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Folks, In the list I sent earlier today I missed one person. Here is the updated list: Accept Signalled Pref-limit as work item: Yes: Vincent Gillet Jeffrey Haas Enke Chen Eric Rosen Curtis Villamizar Sun Tao Gerald Ash Robert Raszuk Srikanth Chavali (author) Vasile Radoaca (author) Mo Miri (author) Luyuan Fan (author) Susan Hares (author) Keyur Patel (author) Chandra Appanna (author) John Scudder (author) No: Vivek Menezes Pekka Savola Parantap Lahiri Tony Li Enrico Salazar Pedro Roque Marques Accept draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document Yes: Vincent Gillet Gerald Ash Srikanth Chavali (author) Vasile Radoaca (author) Mo Miri (author) Luyuan Fan (author) Susan Hares (author) Accept draft-keyur-prefixlimit-orf-00.txt as an IDR WG document Yes: Enke Chen Eric Rosen Sun Tao Robert Raszuk Keyur Patel (author) Chandra Appanna (author) John Scudder (author) _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA18084 for ; Tue, 8 Jun 2004 13:41:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXkSQ-0007AR-60; Tue, 08 Jun 2004 13:32:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXkJT-0004Up-Ee for idr@megatron.ietf.org; Tue, 08 Jun 2004 13:23:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10250 for ; Tue, 8 Jun 2004 13:23:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXkJS-00029W-FV for idr@ietf.org; Tue, 08 Jun 2004 13:23:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXkHu-0000ZR-00 for idr@ietf.org; Tue, 08 Jun 2004 13:21:26 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BXkGI-0006Vy-00 for idr@ietf.org; Tue, 08 Jun 2004 13:19:46 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i58HJGBm046475; Tue, 8 Jun 2004 10:19:16 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i58HJGJ94374; Tue, 8 Jun 2004 10:19:16 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406081719.i58HJGJ94374@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <35116.1086715156.1@juniper.net> Date: Tue, 08 Jun 2004 10:19:16 -0700 From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: skh@nexthop.com Subject: [Idr] IDR WG meeting agenda 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Folks, If you'd like some time on the agenda in San Diego please let me and Sue know (the sooner the better). Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA14863 for ; Tue, 8 Jun 2004 13:11:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXjy6-0005zF-4W; Tue, 08 Jun 2004 13:00:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXjkG-00009O-PF for idr@megatron.ietf.org; Tue, 08 Jun 2004 12:46:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07436 for ; Tue, 8 Jun 2004 12:46:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXjkF-0004yA-PD for idr@ietf.org; Tue, 08 Jun 2004 12:46:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXjjK-0004AW-00 for idr@ietf.org; Tue, 08 Jun 2004 12:45:43 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BXjiT-0002rL-00 for idr@ietf.org; Tue, 08 Jun 2004 12:44:49 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i58GiIBm043701 for ; Tue, 8 Jun 2004 09:44:18 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i58GiIJ81595 for ; Tue, 8 Jun 2004 09:44:18 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406081644.i58GiIJ81595@merlot.juniper.net> To: idr@ietf.org Subject: [Idr] extending deadline for pref-limit comments MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29098.1086713058.1@juniper.net> Date: Tue, 08 Jun 2004 09:44:18 -0700 From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Folks, The deadline for comments on the attached is over. The following summarizes the feedback received. Please check for correctness. In the summary I assume that (a) all the authors of a particular proposal are in favor of accepting this proposal as WG item (if this is incorrect, please let me know asap), and (b) all the authors of both of the proposals are in favor of accepting signalled prefix limit as an IDR WG item (if this is incorrect, please let me know asap). Accept Signalled Pref-limit as work item: Yes: Vincent Gillet Jeffrey Haas Enke Chen Eric Rosen Curtis Villamizar Sun Tao Gerald Ash Srikanth Chavali (author) Vasile Radoaca (author) Mo Miri (author) Luyuan Fan (author) Susan Hares (author) Keyur Patel (author) Chandra Appanna (author) John Scudder (author) No: Vivek Menezes Pekka Savola Parantap Lahiri Tony Li Enrico Salazar Pedro Roque Marques Accept draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document Yes: Vincent Gillet Gerald Ash Srikanth Chavali (author) Vasile Radoaca (author) Mo Miri (author) Luyuan Fan (author) Susan Hares (author) Accept draft-keyur-prefixlimit-orf-00.txt as an IDR WG document Yes: Enke Chen Eric Rosen Sun Tao Keyur Patel (author) Chandra Appanna (author) John Scudder (author) ------- Forwarded Message Date: Mon, 24 May 2004 08:07:04 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] extending deadline for pref-limit comments Folks, As requested by authors of both of the proposals on the table, we are going to extend the deadline for comments for another 2 weeks (until Jun 7). To remind, the questions on the table are the following: 1. whether to take signalled prefix limit as a WG item 2. whether to accept draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document 3. whether to accept draft-keyur-prefixlimit-orf-00.txt as an IDR WG document In your e-mails please *clearly* indicate your preferences. Providing rationale for your preferences would be extremely useful as well. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA25208 for ; Tue, 8 Jun 2004 10:00:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXh4L-00005Y-4a; Tue, 08 Jun 2004 09:55:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXgxm-0006yM-8n for idr@megatron.ietf.org; Tue, 08 Jun 2004 09:48:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26700 for ; Tue, 8 Jun 2004 09:48:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXgxl-0001hA-2c for idr@ietf.org; Tue, 08 Jun 2004 09:48:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXgwm-0000xQ-00 for idr@ietf.org; Tue, 08 Jun 2004 09:47:25 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BXgvb-0007H7-00 for idr@ietf.org; Tue, 08 Jun 2004 09:46:11 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id C99262D485D for ; Tue, 8 Jun 2004 09:45:41 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 43311-01-78 for ; Tue, 8 Jun 2004 09:45:30 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 653962D4814 for ; Tue, 8 Jun 2004 09:45:30 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i58DjUu04490 for idr@ietf.org; Tue, 8 Jun 2004 09:45:30 -0400 (EDT) Date: Tue, 8 Jun 2004 09:45:30 -0400 From: Jeffrey Haas To: idr@ietf.org Subject: Re: [Idr] revised draft Message-ID: <20040608134530.GE4415@nexthop.com> References: <200406072009.i57K9rJ29272@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406072009.i57K9rJ29272@merlot.juniper.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org All of my previous concerns were addressed. It looks good to me. On Mon, Jun 07, 2004 at 01:09:53PM -0700, Yakov Rekhter wrote: > Folks, > > Please check if the attached reflects the comments received during > the IDR WG Last Call. In the absence of any objections we'll submit it to > the IESG Jun 14, 2004. > > Yakov -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA17967 for ; Tue, 8 Jun 2004 08:43:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXfnf-0002dG-Vq; Tue, 08 Jun 2004 08:33:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXfiK-0000op-Hw for idr@megatron.ietf.org; Tue, 08 Jun 2004 08:28:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22527 for ; Tue, 8 Jun 2004 08:28:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXfiJ-00057P-OD for idr@ietf.org; Tue, 08 Jun 2004 08:28:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXfhS-0004PI-00 for idr@ietf.org; Tue, 08 Jun 2004 08:27:30 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BXfgA-00030l-00 for idr@ietf.org; Tue, 08 Jun 2004 08:26:10 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D31842D4848; Tue, 8 Jun 2004 08:25:39 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 41124-01-60; Tue, 8 Jun 2004 08:25:28 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 74A622D4814; Tue, 8 Jun 2004 08:25:28 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i58CPSr04258; Tue, 8 Jun 2004 08:25:28 -0400 (EDT) Date: Tue, 8 Jun 2004 08:25:28 -0400 From: Jeffrey Haas To: Tulip Rasputin Subject: Re: [Idr] Atomic Aggregate Message-ID: <20040608122528.GA4249@nexthop.com> References: <20040608105657.20868.qmail@web60705.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040608105657.20868.qmail@web60705.mail.yahoo.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org On Tue, Jun 08, 2004 at 06:56:57AM -0400, Tulip Rasputin wrote: > What would happen if it advertises 128/8 with AS Path Seq "XXX 6000" and AS Set "[6120]"? In this > case its advertising all the AS Path information. Is it required to attach the ATOMIC_AGGREGATE > path attribute in this case? All of the AS's are present, even if not attached to their original sequences. Since BGP uses the presence of the AS, regardless of its type (sequence, set, etc) for loop detection, this is enough. ATOMIC_AGGREGATE doesn't need to be attached. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA08408 for ; Tue, 8 Jun 2004 07:10:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXeO0-0007A4-5M; Tue, 08 Jun 2004 07:03:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXeK7-000683-Qe for idr@megatron.ietf.org; Tue, 08 Jun 2004 06:59:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17983 for ; Tue, 8 Jun 2004 06:59:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXeK5-0003Yp-7S for idr@ietf.org; Tue, 08 Jun 2004 06:59:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXeJ9-0002rx-00 for idr@ietf.org; Tue, 08 Jun 2004 06:58:20 -0400 Received: from web60705.mail.yahoo.com ([216.109.117.228]) by ietf-mx with smtp (Exim 4.12) id 1BXeIH-0001Xx-00 for idr@ietf.org; Tue, 08 Jun 2004 06:57:25 -0400 Message-ID: <20040608105657.20868.qmail@web60705.mail.yahoo.com> Received: from [202.144.106.188] by web60705.mail.yahoo.com via HTTP; Tue, 08 Jun 2004 06:56:57 EDT Date: Tue, 8 Jun 2004 06:56:57 -0400 (EDT) From: Tulip Rasputin To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Idr] Atomic Aggregate 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hi, Section 5.1.6 (ATOMIC_AGGREGATE) of the draft-ietf-idr-bgp4-23.txt states that "If an aggregate excludes at least some of the AS numbers present in the AS_PATH of the routes that are aggregated as a result of dropping the AS_SET, the aggregated route, when advertised to the peer, SHOULD include the ATOMIC_AGGREGATE attribute." Now suppose a BGP speaker (in AS say XXX) has the following routes: [1] 128.1/16, AS Path Sequence 6000 6120 [2] 128.2/16, AS Path Seq 6000 This BGP speaker is configured to advertise an aggregate route of 128/8 to one of its EBGP Peer. If this BGP speaker advertises 128/8 with AS Path "XXX 6000", then IMO it should attach the ATOMIC_AGGREGATE path attribute, warning its peer that some of the AS numbers are not present in this AS Path. What would happen if it advertises 128/8 with AS Path Seq "XXX 6000" and AS Set "[6120]"? In this case its advertising all the AS Path information. Is it required to attach the ATOMIC_AGGREGATE path attribute in this case? I understand that it will attach the AGREGATOR path attribute in both the above cases to let others know who and where did the aggregation took place? Regards, Rasputin ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA16723 for ; Mon, 7 Jun 2004 17:53:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXRPt-0001Am-4b; Mon, 07 Jun 2004 17:12:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXQY2-00040x-Qv for idr@megatron.ietf.org; Mon, 07 Jun 2004 16:16:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14439 for ; Mon, 7 Jun 2004 16:16:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXQY1-0005gQ-FN for idr@ietf.org; Mon, 07 Jun 2004 16:16:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXQVK-0004kl-00 for idr@ietf.org; Mon, 07 Jun 2004 16:13:58 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BXQRq-0002wl-00 for idr@ietf.org; Mon, 07 Jun 2004 16:10:23 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i57K9rBm034709 for ; Mon, 7 Jun 2004 13:09:53 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i57K9rJ29272 for ; Mon, 7 Jun 2004 13:09:53 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406072009.i57K9rJ29272@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <44815.1086638993.1@juniper.net> Date: Mon, 07 Jun 2004 13:09:53 -0700 From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] revised draft 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Folks, Please check if the attached reflects the comments received during the IDR WG Last Call. In the absence of any objections we'll submit it to the IESG Jun 14, 2004. Yakov. ------- Forwarded Message Date: Mon, 07 Jun 2004 15:42:12 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-idr-rfc1863-historic-00.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Reclassification of RFC 1863 to Historic Author(s) : P. Savola Filename : draft-ietf-idr-rfc1863-historic-00.txt Pages : 4 Date : 2004-6-7 This memo reclassifies RFC 1863, A BGP/IDRP Route Server alternative to a full mesh routing, to Historic status. This memo also Obsoletes RFC 1863. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc1863-historic-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 mess age. 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-rfc1863-historic-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-rfc1863-historic-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-7154337.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc1863-historic-00.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc1863-historic-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-7154337.I-D@ietf.org> - --OtherAccess-- - --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce - --NextPart-- ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA00438 for ; Fri, 4 Jun 2004 18:54:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWNWy-0000YG-Si; Fri, 04 Jun 2004 18:51:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWNIb-0004bu-U2 for idr@megatron.ietf.org; Fri, 04 Jun 2004 18:36:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24339 for ; Fri, 4 Jun 2004 18:36:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWNIa-00079a-Cj for idr@ietf.org; Fri, 04 Jun 2004 18:36:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWNHa-0006pg-00 for idr@ietf.org; Fri, 04 Jun 2004 18:35:27 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BWNGa-0006Cy-00 for idr@ietf.org; Fri, 04 Jun 2004 18:34:24 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i54MXmPC030403; Fri, 4 Jun 2004 15:33:48 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i54MXmCB030400; Fri, 4 Jun 2004 15:33:48 -0700 (PDT) From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16576.63692.283575.875164@roque-bsd.juniper.net> Date: Fri, 4 Jun 2004 15:33:48 -0700 To: qning@chiaro.com Subject: [Idr] Question about RFC 3107 Carrying label in bgp-4 In-Reply-To: <34B6386F843340459B22F59DFF7B12FF31917B@192-168-240-22.chiaro.com> References: <34B6386F843340459B22F59DFF7B12FF31917B@192-168-240-22.chiaro.com> X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org qning writes: > Hi, I will use 192.168.0.0/16 as an ip prefix, and 0x102031 as an > mpls label in the following questions. > RFC 3107 (Carrying Label Information in BGP-4) Section 3 states > 0x102031:192.168.0.0/16 can be advertised in a MP_REACH_NLRI. It > can be withdrawn by either a) a new route with a new label: > 0xB1B2B3:192.168.0.0/16 in MP_REACG_NLRI or b) > 0x800000:192.168.0.0/16 in a MP_UNREACH_NLRI. Not commenting on the spec... The implementations i'm aware of treat the IP prefix as the NLRI key for safi-4 and the label as a per nlri attribute. As such an update for a given IP prefix implicitly withdrawn the previously advertised label. Another area to be concerned in terms of interoperability is the fact that some implementations seem to consider a SAFI=1 update/withdrawl for the same prefix to update the safi=4 information... Not JunOS implementation, however... JunOS considers a safi=4 update and a safi=1 update to refer to different routing databases... You may want to verify some of these details if you are concerned w/ interoperability... Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA21973 for ; Fri, 4 Jun 2004 12:27:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWHE0-0008Am-C9; Fri, 04 Jun 2004 12:07:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWGzZ-0005KR-WC for idr@megatron.ietf.org; Fri, 04 Jun 2004 11:52:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18925 for ; Fri, 4 Jun 2004 11:52:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWGzZ-0000fQ-0j for idr@ietf.org; Fri, 04 Jun 2004 11:52:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWGyh-0000K8-00 for idr@ietf.org; Fri, 04 Jun 2004 11:51:32 -0400 Received: from bay17-f38.bay17.hotmail.com ([64.4.43.88] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BWGy2-0007iT-00 for idr@ietf.org; Fri, 04 Jun 2004 11:50:50 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 4 Jun 2004 08:50:20 -0700 Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Fri, 04 Jun 2004 15:50:20 GMT X-Originating-IP: [61.16.170.194] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: curtis@faster-light.net Subject: Re: [Idr] A question on longest match Date: Fri, 04 Jun 2004 15:50:20 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Jun 2004 15:50:20.0378 (UTC) FILETIME=[A3C473A0:01C44A4B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Sorry for being rude Curtis, As I said it was an opinion, and I shared it, It is for the WG to decide. >From: Curtis Villamizar >Reply-To: curtis@faster-light.net >To: "john smith" >CC: curtis@faster-light.net, idr@ietf.org >Subject: Re: [Idr] A question on longest match Date: Fri, 04 Jun 2004 >11:44:43 -0400 > >In message , "john smith" writes: > > > > > > >Back then this idea was known as "FIB compression" and if you like you > > >can search the archives for a lot of discussion on the issue and quite > > >a bit of measurement done at that time. > > > > > > > It certainly is better than entring a "split brain" with NO_EXPORT :) > > >We're talking about two different things. Automatic aggregation of >the FIB is safe to do under all circumstances. Automatice aggregation >and reannouncement is not always safe. > > > > > > Or we are saying BGP is specifically meant only for vendors and > > >operators > > > > who can cater to such hardware? > > > > > > > > >Providers can aggregate better but it requires better coordination > > >among providers. > > > > > > > How has this got *anything* to do with coordination among providers? > > >If provider A has a aggregate and some customers are dual homed to >provider B, then provider B or downstream can't safely aggregate those >routes. If any of those dual homed customers loosed connection to A >and most providers rightfully send traffic for the A aggregate to A, >then those customers don't have backup through B. > >See 10 year old discussion on "hostile aggregation". > >The modern twist on this is that the "provider coordination" these >days can be as simple as adding a BGP community. We now have a BGP >communitity that can work across any number of AS crossings, the >NOPEER. The classic example where this is a problem is the >non-aggregation of Australian routes in the US and Europe. >Unfortunately the NOPEER isn't being used enough so you need to use >the "clue club" (as someone who has contributed a lot to operations >has called it, or was it the "clue bat") with the provider origination >the route. That too is a form of interprovider coordination, but not >one easily standardized. > >That's what PTOMANE and GROW are all about. Or a big part of it. > >In the case of 4/8, there were a very small number of more specific. >In all likelyhood these are only the ones that really needed to be >there (or at least most of them) so you shouldn't touch them. > > > > It is upto the IETF to make the providers cordinate. Eitherways if the >IETF > > thinks the idea makes *any sense* then they should take a step in that > > direction rather than say "too late". > > > > If people can build terabit routers which can switch millions of packets >and > > have a huge FIB, they can figure out ways to reduce the FIB size too. It >is > > a matter of what the "specs" say. > > > > Are specs *not* made for scalaibilty? To quote someone from another >list, is > > it not the job of the *specs* to say what is *techincally correct*? > > >Not to be rude but I chopped off the rest of your response. I >responded the first time off list because I didn't want to get into an >extended thread on this. > >You are not telling the IETF something that the IETF is not aware of >or hasn't thought about. If you want to see what the IETF WGs have >had to say about this topic, look in the archives. In particular you >want to look at the PTOMAINE and GROW WG, more PTOMAINE. _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA20349 for ; Fri, 4 Jun 2004 12:12:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWH5m-0006ap-Fa; Fri, 04 Jun 2004 11:58:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWGwV-0004la-VI for idr@megatron.ietf.org; Fri, 04 Jun 2004 11:49:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18644 for ; Fri, 4 Jun 2004 11:49:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWGwU-00079D-LK for idr@ietf.org; Fri, 04 Jun 2004 11:49:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWGv8-0006Yu-00 for idr@ietf.org; Fri, 04 Jun 2004 11:47:50 -0400 Received: from relay.pair.com ([209.68.1.20]) by ietf-mx with smtp (Exim 4.12) id 1BWGtY-0005mW-00 for idr@ietf.org; Fri, 04 Jun 2004 11:46:12 -0400 Received: (qmail 40021 invoked from network); 4 Jun 2004 15:46:06 -0000 Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay.pair.com with SMTP; 4 Jun 2004 15:46:06 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.fictitious.org [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id i54FihqX097023; Fri, 4 Jun 2004 11:44:43 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200406041544.i54FihqX097023@workhorse.faster-light.net> To: "john smith" Subject: Re: [Idr] A question on longest match In-reply-to: Your message of "Fri, 04 Jun 2004 06:22:29 -0000." Date: Fri, 04 Jun 2004 11:44:43 -0400 From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org In message , "john smith" writes: > > > >Back then this idea was known as "FIB compression" and if you like you > >can search the archives for a lot of discussion on the issue and quite > >a bit of measurement done at that time. > > > > It certainly is better than entring a "split brain" with NO_EXPORT :) We're talking about two different things. Automatic aggregation of the FIB is safe to do under all circumstances. Automatice aggregation and reannouncement is not always safe. > > > Or we are saying BGP is specifically meant only for vendors and > >operators > > > who can cater to such hardware? > > > > > >Providers can aggregate better but it requires better coordination > >among providers. > > > > How has this got *anything* to do with coordination among providers? If provider A has a aggregate and some customers are dual homed to provider B, then provider B or downstream can't safely aggregate those routes. If any of those dual homed customers loosed connection to A and most providers rightfully send traffic for the A aggregate to A, then those customers don't have backup through B. See 10 year old discussion on "hostile aggregation". The modern twist on this is that the "provider coordination" these days can be as simple as adding a BGP community. We now have a BGP communitity that can work across any number of AS crossings, the NOPEER. The classic example where this is a problem is the non-aggregation of Australian routes in the US and Europe. Unfortunately the NOPEER isn't being used enough so you need to use the "clue club" (as someone who has contributed a lot to operations has called it, or was it the "clue bat") with the provider origination the route. That too is a form of interprovider coordination, but not one easily standardized. That's what PTOMANE and GROW are all about. Or a big part of it. In the case of 4/8, there were a very small number of more specific. In all likelyhood these are only the ones that really needed to be there (or at least most of them) so you shouldn't touch them. > It is upto the IETF to make the providers cordinate. Eitherways if the IETF > thinks the idea makes *any sense* then they should take a step in that > direction rather than say "too late". > > If people can build terabit routers which can switch millions of packets and > have a huge FIB, they can figure out ways to reduce the FIB size too. It is > a matter of what the "specs" say. > > Are specs *not* made for scalaibilty? To quote someone from another list, is > it not the job of the *specs* to say what is *techincally correct*? Not to be rude but I chopped off the rest of your response. I responded the first time off list because I didn't want to get into an extended thread on this. You are not telling the IETF something that the IETF is not aware of or hasn't thought about. If you want to see what the IETF WGs have had to say about this topic, look in the archives. In particular you want to look at the PTOMAINE and GROW WG, more PTOMAINE. Thanks for the advice. :-) Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA23183 for ; Fri, 4 Jun 2004 02:35:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BW8Fd-0002Vm-5u; Fri, 04 Jun 2004 02:32:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BW88P-0001JS-Ba for idr@megatron.ietf.org; Fri, 04 Jun 2004 02:24:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14007 for ; Fri, 4 Jun 2004 02:24:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BW88N-0005oA-2C for idr@ietf.org; Fri, 04 Jun 2004 02:24:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BW87T-0005Qt-00 for idr@ietf.org; Fri, 04 Jun 2004 02:24:00 -0400 Received: from bay17-f7.bay17.hotmail.com ([64.4.43.57] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BW86V-0004gO-00 for idr@ietf.org; Fri, 04 Jun 2004 02:22:59 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 3 Jun 2004 23:22:29 -0700 Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Fri, 04 Jun 2004 06:22:29 GMT X-Originating-IP: [61.16.170.194] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: curtis@faster-light.net Subject: Re: [Idr] A question on longest match Date: Fri, 04 Jun 2004 06:22:29 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Jun 2004 06:22:29.0828 (UTC) FILETIME=[50231840:01C449FC] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hi Curtis, > > > > Please check the specific examples I emailed you offline. Or for that >matter > > please check any node on the internet. In most cases the reduction is >quite > > a bit. > > >Yes I did. You pointed to the 4/8 prefix and some more specific, none >of which were contiguous. You also pointed to a block that started at >x.x.211/24 and fell under a /16 but I pointed out that a block >starting at .211 doesn't compress well unless you fill the holes and >then you just need the /16. > exactly. > > > >At this point there is no problem in doing so but the cost of FIB > > >storage isn't that great and the slow down in route insertion/deletion > > >would be a bad thing for the space reduction. The time lookup is no > > >issue either with modern hardware. > > > > > > > So we are saying that we will not have more routes? > > >There will be more routes. I did the analysis when there were less >than 20,000 routes. There are now 300,000 routes or more depending on >who you talk to. > Agreed. The point is that other than BGP no other protocol has to rely so heavily on the paradigm of longest match. Mainly as BGP has to carry that information. It really is not a problem to find a route-server equivalent PC which can store a considerable amount of routes without adding an expense to it. The problem is that out of those 300,000 routes, a lot of them are very redundant and I certainly do not appreciate vendors coming out with "1 million routes in the forwarding table" models for no rhyme or reason. Even if we add up the existing deployment of routers, most of them are sufficient to handle the existing prefixes when aggregated for a considerable amount of time. >Back then this idea was known as "FIB compression" and if you like you >can search the archives for a lot of discussion on the issue and quite >a bit of measurement done at that time. > It certainly is better than entring a "split brain" with NO_EXPORT :) > > > Or we are saying BGP is specifically meant only for vendors and >operators > > who can cater to such hardware? > > >Providers can aggregate better but it requires better coordination >among providers. > How has this got *anything* to do with coordination among providers? It is upto the IETF to make the providers cordinate. Eitherways if the IETF thinks the idea makes *any sense* then they should take a step in that direction rather than say "too late". If people can build terabit routers which can switch millions of packets and have a huge FIB, they can figure out ways to reduce the FIB size too. It is a matter of what the "specs" say. Are specs *not* made for scalaibilty? To quote someone from another list, is it not the job of the *specs* to say what is *techincally correct*? >It is up to providers to decide how they configure their routers. >Having worked very closely with many router vendors over the last 12 >years, and working at one now, I can tell you that the RIB with lots >of peers is a much bigger problem than the size of the FIB. > Is that the reason why they want to prefix limit? For that matter, may I be bold enough to ask what *high speed FIB* the merit route servers were using? >There is nothing to stop a vendor from compressing the FIB if they >think that will make a better routers. It just happens that none do >it an IMHO it would not be a good idea to do so. > You contradict the statement below :) where you say you thought of it first. You could probably do a quick search on google and you will find lots of folks who have asked for summarization feature of BGP routes. > > > >When you do packet filtering (all core routers need to be able to do > > >this on all interface types because private peerings can be over > > >OC192c POS) you have to keep a FIB for the router and then you have to > > >apply the packet filtering rules per interface. That already > > >increases the work (the same card can have one processor but more than > > >one interface, even OC192c or 10GbE). > > > > > > I think most people tend to do: > > ip route null0 > > > > and if they want to use *some RFC 1918 address space* internally, they >put a > > route to pass that space as a more specific. That definately is not an >issue > > which hampers this. > > > > Eitherways this is definately *not* packet filtering. > > >At peer and most customer boundaries, most providers also do things >like block all traffic destined to port numbers for OSPF, BGP, SNMP, >and a few others except their EBGP peerings. Some put other packet >filters in place, many on source address to prevent spoofing. It to >some extent depends on what their routers can do. > agreed. The answer was specific to your question. >Filtering is often applied on a per interface basis. It is at least >different for outward facing interfaces (connected to peers or >customers) than inward facing (connected to the core). For a router >with lots of interfaces this is added work. It is not an important >point though but it does affect convergence a little if there is lot >of filtering that has to be applied after the RP sends the FIB. > ?? How has that got anything to do with the question? > > > >Anything which further multiplies the change to the FIB makes route > > >convergence slower and that is a big issue today. Its not the size of > > >the FIB that matters today its trying to process the amount of change > > >that can occur in the "well under 1 second" time frame that providers > > >are looking for. > > > > > > > So can we have something to the effect of: > > "if there is a terrible impact in performance such a feature should be > > turned off but if not, it makes sense" ? > > > > How it is done can be an implementation issue. > > >Its up to the providers to decide which trafeoff is more important. >No provider has been telling me that they want their routers to do >more computation and eat more memory in the RP to compress the FIB >such that the line cards can have less entries. If you are a >provider, talk to your router vendor if you think that's a good >tradeoff. If you are a vendor, talk to providers and see it they are >interested. AFAIK there is not interest in FIB compression. > As i said, please do a google on the same. The question is simple, does the WG intend to scale in a suitable manner or not? > >ps - but if FIB compression takes off I can claim to have thought of >the idea first. :-) But I honestly don't think it will. :-) how many providers did you speak to? Eitherways, I believe it can be specified in the draft, how it is handled can be an implementation issue. _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA18679 for ; Thu, 3 Jun 2004 18:58:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BW14A-0000G6-IH; Thu, 03 Jun 2004 18:52:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BW0uq-000543-IW for idr@megatron.ietf.org; Thu, 03 Jun 2004 18:42:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00018 for ; Thu, 3 Jun 2004 18:42:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BW0up-0005yJ-4K for idr@ietf.org; Thu, 03 Jun 2004 18:42:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BW0W2-0001Fr-00 for idr@ietf.org; Thu, 03 Jun 2004 18:16:52 -0400 Received: from relay.pair.com ([209.68.1.20]) by ietf-mx with smtp (Exim 4.12) id 1BW0Cp-00052R-00 for idr@ietf.org; Thu, 03 Jun 2004 17:56:59 -0400 Received: (qmail 20044 invoked from network); 3 Jun 2004 21:56:58 -0000 Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay.pair.com with SMTP; 3 Jun 2004 21:56:58 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.fictitious.org [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id i53Ltr72090334; Thu, 3 Jun 2004 17:55:53 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200406032155.i53Ltr72090334@workhorse.faster-light.net> To: "john smith" Subject: Re: [Idr] A question on longest match In-reply-to: Your message of "Thu, 03 Jun 2004 16:53:13 -0000." Date: Thu, 03 Jun 2004 17:55:53 -0400 From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org John, I dropped the IDR Cc but I see you added it back. Comments inline. Curtis In message , "john smith" writes: > Hello Curtis, > > > > > Hello Curtis, > > > > > > That is strange indeed. > > > > > > I have seen very different results when doing the same. > > > > > > I am not talking about aggregating over holes at all. > > > > > > I am simply saying, > > > > > > I receive 20 prefixes of say /19 from 1 link and 40 of say /20 from the > > > other. > > > > > > Most of these as far as I can see can be aggregated, but are still > > > advertised as they are due to the presence of longest match paradigm > > > > > > However, I guess this is specific to my view, > > > > > > Though, why is there a problem in doing so? > > > > > >The issue is really what gains can be made for the router with 300,000 > >prefixes in the FIB. I did the analysis when the number of global > >routes was well under 20,000 and the gains where not all that great > >unless you aggregated over the holes. > > > > Please check the specific examples I emailed you offline. Or for that matter > please check any node on the internet. In most cases the reduction is quite > a bit. Yes I did. You pointed to the 4/8 prefix and some more specific, none of which were contiguous. You also pointed to a block that started at x.x.211/24 and fell under a /16 but I pointed out that a block starting at .211 doesn't compress well unless you fill the holes and then you just need the /16. > >At this point there is no problem in doing so but the cost of FIB > >storage isn't that great and the slow down in route insertion/deletion > >would be a bad thing for the space reduction. The time lookup is no > >issue either with modern hardware. > > > > So we are saying that we will not have more routes? There will be more routes. I did the analysis when there were less than 20,000 routes. There are now 300,000 routes or more depending on who you talk to. Back then this idea was known as "FIB compression" and if you like you can search the archives for a lot of discussion on the issue and quite a bit of measurement done at that time. > Or we are saying BGP is specifically meant only for vendors and operators > who can cater to such hardware? Providers can aggregate better but it requires better coordination among providers. It is up to providers to decide how they configure their routers. Having worked very closely with many router vendors over the last 12 years, and working at one now, I can tell you that the RIB with lots of peers is a much bigger problem than the size of the FIB. There is nothing to stop a vendor from compressing the FIB if they think that will make a better routers. It just happens that none do it an IMHO it would not be a good idea to do so. > >When you do packet filtering (all core routers need to be able to do > >this on all interface types because private peerings can be over > >OC192c POS) you have to keep a FIB for the router and then you have to > >apply the packet filtering rules per interface. That already > >increases the work (the same card can have one processor but more than > >one interface, even OC192c or 10GbE). > > > I think most people tend to do: > ip route null0 > > and if they want to use *some RFC 1918 address space* internally, they put a > route to pass that space as a more specific. That definately is not an issue > which hampers this. > > Eitherways this is definately *not* packet filtering. At peer and most customer boundaries, most providers also do things like block all traffic destined to port numbers for OSPF, BGP, SNMP, and a few others except their EBGP peerings. Some put other packet filters in place, many on source address to prevent spoofing. It to some extent depends on what their routers can do. Filtering is often applied on a per interface basis. It is at least different for outward facing interfaces (connected to peers or customers) than inward facing (connected to the core). For a router with lots of interfaces this is added work. It is not an important point though but it does affect convergence a little if there is lot of filtering that has to be applied after the RP sends the FIB. > >Anything which further multiplies the change to the FIB makes route > >convergence slower and that is a big issue today. Its not the size of > >the FIB that matters today its trying to process the amount of change > >that can occur in the "well under 1 second" time frame that providers > >are looking for. > > > > So can we have something to the effect of: > "if there is a terrible impact in performance such a feature should be > turned off but if not, it makes sense" ? > > How it is done can be an implementation issue. Its up to the providers to decide which trafeoff is more important. No provider has been telling me that they want their routers to do more computation and eat more memory in the RP to compress the FIB such that the line cards can have less entries. If you are a provider, talk to your router vendor if you think that's a good tradeoff. If you are a vendor, talk to providers and see it they are interested. AFAIK there is not interest in FIB compression. ps - but if FIB compression takes off I can claim to have thought of the idea first. :-) But I honestly don't think it will. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA16060 for ; Thu, 3 Jun 2004 18:15:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BW0FK-0004OL-LB; Thu, 03 Jun 2004 17:59:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVyoK-0007qf-Ig for idr@megatron.ietf.org; Thu, 03 Jun 2004 16:27:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12580 for ; Thu, 3 Jun 2004 16:27:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVyoJ-000602-AV for idr@ietf.org; Thu, 03 Jun 2004 16:27:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVynE-0005Wa-00 for idr@ietf.org; Thu, 03 Jun 2004 16:26:29 -0400 Received: from bay17-f6.bay17.hotmail.com ([64.4.43.56] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BVym8-0004et-00 for idr@ietf.org; Thu, 03 Jun 2004 16:25:20 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 3 Jun 2004 13:24:50 -0700 Received: from 219.65.131.3 by by17fd.bay17.hotmail.msn.com with HTTP; Thu, 03 Jun 2004 20:24:50 GMT X-Originating-IP: [219.65.131.3] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: idr@ietf.org Subject: RE: [Idr] Question about RFC 3107 Carrying label in bgp-4 Date: Thu, 03 Jun 2004 20:24:50 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jun 2004 20:24:50.0328 (UTC) FILETIME=[D235A180:01C449A8] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org >In Section 4, it states that multiple routes to the >same destination, but different labels can be >maintained and advertised. As if one route was not enough :)........... _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA15594 for ; Thu, 3 Jun 2004 18:08:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVzsm-0002IU-5v; Thu, 03 Jun 2004 17:36:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVyX9-0002JS-QJ for idr@megatron.ietf.org; Thu, 03 Jun 2004 16:09:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10985 for ; Thu, 3 Jun 2004 16:09:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVyX8-00062I-Kt for idr@ietf.org; Thu, 03 Jun 2004 16:09:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVyWH-0005b1-00 for idr@ietf.org; Thu, 03 Jun 2004 16:08:58 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BVyUl-0004Wf-00 for idr@ietf.org; Thu, 03 Jun 2004 16:07:23 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 5E1492D483F for ; Thu, 3 Jun 2004 16:06:53 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 33325-01-49 for ; Thu, 3 Jun 2004 16:06:41 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 1A2102D4900 for ; Thu, 3 Jun 2004 16:06:41 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i53K6fO14498 for idr@ietf.org; Thu, 3 Jun 2004 16:06:41 -0400 (EDT) Date: Thu, 3 Jun 2004 16:06:41 -0400 From: Jeffrey Haas To: idr@ietf.org Subject: Re: [Idr] missing text Message-ID: <20040603200640.GD13006@nexthop.com> References: <200406031350.i53DoJJ25959@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406031350.i53DoJJ25959@merlot.juniper.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org On Thu, Jun 03, 2004 at 06:50:19AM -0700, Yakov Rekhter wrote: > So, to fix this I'd like to propose to add at the end of the above > text the following: > > 3) if the AS_PATH is empty, the local system creates > a path segment of type AS_SEQUENCE, places its own AS > into that segment, and places that segment into the AS_PATH. This looks fine to me. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA05444 for ; Thu, 3 Jun 2004 15:24:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVxDV-0004VO-78; Thu, 03 Jun 2004 14:45:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVwPN-00015s-Lt for idr@megatron.ietf.org; Thu, 03 Jun 2004 13:53:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24394 for ; Thu, 3 Jun 2004 12:57:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVvWx-00076l-4c for idr@ietf.org; Thu, 03 Jun 2004 12:57:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVvU5-00062W-00 for idr@ietf.org; Thu, 03 Jun 2004 12:54:30 -0400 Received: from bay17-f43.bay17.hotmail.com ([64.4.43.93] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BVvTM-0005Ee-00 for idr@ietf.org; Thu, 03 Jun 2004 12:53:44 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 3 Jun 2004 09:53:13 -0700 Received: from 219.65.134.175 by by17fd.bay17.hotmail.msn.com with HTTP; Thu, 03 Jun 2004 16:53:13 GMT X-Originating-IP: [219.65.134.175] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: curtis@faster-light.net Subject: Re: [Idr] A question on longest match Date: Thu, 03 Jun 2004 16:53:13 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jun 2004 16:53:13.0881 (UTC) FILETIME=[42899090:01C4498B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hello Curtis, > > Hello Curtis, > > > > That is strange indeed. > > > > I have seen very different results when doing the same. > > > > I am not talking about aggregating over holes at all. > > > > I am simply saying, > > > > I receive 20 prefixes of say /19 from 1 link and 40 of say /20 from the > > other. > > > > Most of these as far as I can see can be aggregated, but are still > > advertised as they are due to the presence of longest match paradigm > > > > However, I guess this is specific to my view, > > > > Though, why is there a problem in doing so? > > >The issue is really what gains can be made for the router with 300,000 >prefixes in the FIB. I did the analysis when the number of global >routes was well under 20,000 and the gains where not all that great >unless you aggregated over the holes. > Please check the specific examples I emailed you offline. Or for that matter please check any node on the internet. In most cases the reduction is quite a bit. >At this point there is no problem in doing so but the cost of FIB >storage isn't that great and the slow down in route insertion/deletion >would be a bad thing for the space reduction. The time lookup is no >issue either with modern hardware. > So we are saying that we will not have more routes? Or we are saying BGP is specifically meant only for vendors and operators who can cater to such hardware? >When you do packet filtering (all core routers need to be able to do >this on all interface types because private peerings can be over >OC192c POS) you have to keep a FIB for the router and then you have to >apply the packet filtering rules per interface. That already >increases the work (the same card can have one processor but more than >one interface, even OC192c or 10GbE). I think most people tend to do: ip route null0 and if they want to use *some RFC 1918 address space* internally, they put a route to pass that space as a more specific. That definately is not an issue which hampers this. Eitherways this is definately *not* packet filtering. > >Anything which further multiplies the change to the FIB makes route >convergence slower and that is a big issue today. Its not the size of >the FIB that matters today its trying to process the amount of change >that can occur in the "well under 1 second" time frame that providers >are looking for. > So can we have something to the effect of: "if there is a terrible impact in performance such a feature should be turned off but if not, it makes sense" ? How it is done can be an implementation issue. _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA05182 for ; Thu, 3 Jun 2004 15:20:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVxDR-0004Q2-M6; Thu, 03 Jun 2004 14:45:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVwPM-00015s-Gq for idr@megatron.ietf.org; Thu, 03 Jun 2004 13:53:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24544 for ; Thu, 3 Jun 2004 12:58:24 -0400 (EDT) From: qning@chiaro.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVvXu-0007Ac-Ig for idr@ietf.org; Thu, 03 Jun 2004 12:58:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVvOz-000357-00 for idr@ietf.org; Thu, 03 Jun 2004 12:49:14 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BVvMr-0002GW-00 for idr@ietf.org; Thu, 03 Jun 2004 12:47:01 -0400 Received: from [62.90.11.34] (helo=cisex001.cis.chiaro.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BVv8K-0002MA-G9 for idr@ietf.org; Thu, 03 Jun 2004 12:32:00 -0400 Received: from rchst007.cus.chiaro.com ([192.168.8.120]) by cisex001.cis.chiaro.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 3 Jun 2004 19:21:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 3 Jun 2004 11:21:03 -0500 Message-ID: <34B6386F843340459B22F59DFF7B12FF31917B@192-168-240-22.chiaro.com> Thread-Topic: [Idr] A question on longest match thread-index: AcRJEL5Ko4HwLBMDRRiwQGBJKpA09AAdanqg To: X-OriginalArrivalTime: 03 Jun 2004 16:21:02.0573 (UTC) FILETIME=[C36359D0:01C44986] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Subject: [Idr] Question about RFC 3107 Carrying label in bgp-4 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id PAA05182 Hi, I will use 192.168.0.0/16 as an ip prefix, and 0x102031 as an mpls label in the following questions. RFC 3107 (Carrying Label Information in BGP-4) Section 3 states 0x102031:192.168.0.0/16 can be advertised in a MP_REACH_NLRI. It can be withdrawn by either a) a new route with a new label: 0xB1B2B3:192.168.0.0/16 in MP_REACG_NLRI or b) 0x800000:192.168.0.0/16 in a MP_UNREACH_NLRI. In Section 4, it states that multiple routes to the same destination, but different labels can be maintained and advertised. This seams to contradict to Section 3 a). If Section 3 a) is used, both routes would have been kept by peer, instead of deleting 0x102031:192.168.0.0/16 and keeping 0xB1B2B3:192.168.0.0/16. Section 4 also states that a peer would keep both 192.168.0.0/16 and 0x102031:192.168.0.0/16 if 192.168.0.0/16 is advertised with (AFI=1, SAFI=1) and 0x102031:192.168.0.0/16 is advertised with (AFI=1, SAFI=4). Does this contradicts to BGP's general principle that only one route from a peer is kept? Does this also implicitly mean that 0x102031:192.168.0.0/16 cannot be used for regular ipv4 unicast routing? It looks to me that the entire Section 4 is contradictory. -- Qi Ning _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA23098 for ; Thu, 3 Jun 2004 12:30:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVtpK-0006Ws-KJ; Thu, 03 Jun 2004 11:08:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVsec-0002Ki-UE for idr@megatron.ietf.org; Thu, 03 Jun 2004 09:53:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11549 for ; Thu, 3 Jun 2004 09:52:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVseN-0003G3-4m for idr@ietf.org; Thu, 03 Jun 2004 09:52:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVsdP-0002sA-00 for idr@ietf.org; Thu, 03 Jun 2004 09:51:56 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BVscL-00025Y-00 for idr@ietf.org; Thu, 03 Jun 2004 09:50:50 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i53DoJBm007034 for ; Thu, 3 Jun 2004 06:50:19 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i53DoJJ25959 for ; Thu, 3 Jun 2004 06:50:19 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406031350.i53DoJJ25959@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <56931.1086270619.1@juniper.net> Date: Thu, 03 Jun 2004 06:50:19 -0700 From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] missing text 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Folks, As John Scudder pointed recently the following text in 5.1.2 is incomplete, as it does not cover the case when the route that is to be advertised was received with empty AS_PATH attribute (this could happen if the route was originated elsewhere in the AS and received via IBGP): b) When a given BGP speaker advertises the route to an external peer, then the advertising speaker updates the AS_PATH attribute as follows: 1) if the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS number as the last element of the sequence (put it in the leftmost position with respect to the position of octets in the protocol mes- sage). If the act of prepending will cause an overflow in the AS_PATH segment, i.e. more than 255 ASs, it SHOULD prepend a new segment of type AS_SEQUENCE and prepend its own AS number to this new segment. 2) if the first path segment of the AS_PATH is of type AS_SET, the local system prepends a new path segment of type AS_SEQUENCE to the AS_PATH, including its own AS number in that segment. So, to fix this I'd like to propose to add at the end of the above text the following: 3) if the AS_PATH is empty, the local system creates a path segment of type AS_SEQUENCE, places its own AS into that segment, and places that segment into the AS_PATH. Please comment on this. The deadline for comments is June 17, 2004. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA19487 for ; Thu, 3 Jun 2004 11:44:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVtfV-0004lP-4H; Thu, 03 Jun 2004 10:58:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVsHa-0007jp-OQ for idr@megatron.ietf.org; Thu, 03 Jun 2004 09:29:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09390 for ; Thu, 3 Jun 2004 09:29:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVsHW-0002QQ-2y for idr@ietf.org; Thu, 03 Jun 2004 09:29:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVsES-0001y0-00 for idr@ietf.org; Thu, 03 Jun 2004 09:26:09 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BVsDe-0001IT-00 for idr@ietf.org; Thu, 03 Jun 2004 09:25:19 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i53DOm959483 for ; Thu, 3 Jun 2004 06:24:48 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i53DOhJ23583 for ; Thu, 3 Jun 2004 06:24:43 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200406031324.i53DOhJ23583@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <53329.1086269083.1@juniper.net> Date: Thu, 03 Jun 2004 06:24:43 -0700 From: Yakov Rekhter X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Idr] proposed additional text in the Security Section 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Folks, Based on the feedback we received so far the text in the attached will be added "as is" to the Security Considerations section of the BGP spec (and the Reference section will be updated as appropriate). Yakov. ------- Forwarded Message Date: Mon, 24 May 2004 07:32:55 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] proposed additional text Folks, Steve Kent proposed the following replacement for the text he suggested earlier (the text I posted on 5/17/2004). BGP makes use of TCP for reliable transport of its traffic between peer routers. To provide connection-oriented integrity and data origin authentication, on a point-to-point basis, BGP specifies use of the mechanism defined in RFC 2385. These services are intended to detect and reject active wiretapping attacks against the inter-router TCP connections. Absent use of mechanisms that effect these security services, attackers can disrupt these TCP connections and/or masquerade as a legitimate peer router. Because the mechanism defined in the RFC does not provide peer-entity authentication, these connections may be subject to some forms of replay attacks that will not be detected at the TCP layer. Such attacks might result in delivery (from TCP) of "broken" or "spoofed" BGP messages. The mechanism defined in RFC 2385 augments the normal TCP checksum with a 16-byte message authentication code (MAC) that is computed over the same data as the TCP checksum. This MAC is based on a one-way hash function (MD5) and use of a secret key. The key is shared between peer routers and is used to generate MAC values that are not readily computed by an attacker who does not have access to the key. A compliant implementation must support this mechanism, and must allow a network administrator to activate it on a per-peer basis. RFC 2385 does not specify a means of managing (e.g., generating, distributing, and replacing) the keys used to compute the MAC. RFC 3562 (an informational document) provides some guidance in this area, and provides rationale to support this guidance. It notes that a distinct key should be used for communication with each protected peer. If the same key is used for multiple peers, the offered security services may be degraded, e.g., due to increased risk of compromise at one router adversely affecting other routers. The keys used for MAC computation should be changed periodically, to minimize the impact of a key compromise or successful cryptanalytic attack. RFC 3562 suggest a crypto period (the interval during which a key is employed) of at most 90 days. More frequent key changes reduce the likelihood that replay attacks (as described above) will be feasible. However, absent a standard mechanism for effecting such changes in a coordinated fashion between peers, one cannot assume that BGP-4 implementations complying with this RFC will support frequent key changes. Obviously, each key also should be chosen so as to be hard for an attacker to guess. The techniques specified in RFC 1750 for random number generation provide a guide for generation of values that could be used as keys. RFC 2385 calls for implementations to support keys "composed of a string of printable ASCII of 80 bytes or less." RFC 3562 suggests keys used in this context be 12 to 24 bytes of random (pseudo-random) bits. This is fairly consistent with suggestions for analogous MAC algorithms, which typically employ keys in the range of 16-20 bytes. RFC 3562 also observes that, to provide enough random bits at the low end of this range, a typical ACSII text string would have to be close to the upper bound for key length specified in RFC 2385. Please review and comment. The deadline for comments is 6/2/2004. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA27880 for ; Thu, 3 Jun 2004 07:56:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVqBq-00015B-2B; Thu, 03 Jun 2004 07:15:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVnR8-0002YO-Lw for idr@megatron.ietf.org; Thu, 03 Jun 2004 04:18:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18883 for ; Thu, 3 Jun 2004 04:18:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVnR6-0006cW-Ei for idr@ietf.org; Thu, 03 Jun 2004 04:18:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVnQI-0006Ey-00 for idr@ietf.org; Thu, 03 Jun 2004 04:18:03 -0400 Received: from bay17-f29.bay17.hotmail.com ([64.4.43.79] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BVnPW-0005ly-00 for idr@ietf.org; Thu, 03 Jun 2004 04:17:14 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 3 Jun 2004 01:16:45 -0700 Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Thu, 03 Jun 2004 08:16:44 GMT X-Originating-IP: [61.16.170.194] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: idr@ietf.org Subject: Re: [Idr] A question on longest match Date: Thu, 03 Jun 2004 08:16:44 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jun 2004 08:16:45.0015 (UTC) FILETIME=[1BBBDE70:01C44943] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org >Its not worth it to aggregate the FIB. There is very little gain if >you don't aggregate over holes. Curtis, the nodes where the holes occur are way down in the network. Infact the places where they do occur happen to be places where /24 networks may actually be connected. The offset for the same is the fact that the rest of the internet as seen from that point is "coniguous". So it offsets the same. This has been my observation. > >If you aggregate over holes you'd need to include more specific reject >routes. > I do not aggregate over holes. I suggest aggregate "what one can as long as the next-hop is the same" and populate the FIB. I agree it makes more sense to aggregate and propogate, but if not that, can we atleast aggregate what goes into the FIB? >If you aggregate the FIB and a withdraw occurs you need to add a >reject. You then need to be concerned about aggregating the rejects >that you are adding. > I could also break the aggregate at that point of time. I still have the specifics in the RIB rememeber? >Gain is small. There is an increase in completity. > It can be the same for *all protocols* Gain can be immense I think. >Disallowing longest to allow automatic aggregation was discussed on >BGP, BGPD, CIDR, or CIDRD more than 10 years ago. We didn't go that >way and its way too late to turn back. > :) >Curtis _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA23466 for ; Thu, 3 Jun 2004 07:08:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVpt0-0004dv-SA; Thu, 03 Jun 2004 06:55:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVlZ5-0006I6-Pf for idr@megatron.ietf.org; Thu, 03 Jun 2004 02:18:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11579 for ; Thu, 3 Jun 2004 02:18:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVlYo-0005lO-IJ for idr@ietf.org; Thu, 03 Jun 2004 02:18:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVlXy-0005OF-00 for idr@ietf.org; Thu, 03 Jun 2004 02:17:51 -0400 Received: from bay17-f44.bay17.hotmail.com ([64.4.43.94] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BVlX6-0004Zf-00 for idr@ietf.org; Thu, 03 Jun 2004 02:16:56 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 2 Jun 2004 23:16:26 -0700 Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Thu, 03 Jun 2004 06:16:26 GMT X-Originating-IP: [61.16.170.194] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: curtis@faster-light.net Subject: Re: [Idr] A question on longest match Date: Thu, 03 Jun 2004 06:16:26 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jun 2004 06:16:26.0908 (UTC) FILETIME=[4D6825C0:01C44932] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hello Curtis, That is strange indeed. I have seen very different results when doing the same. I am not talking about aggregating over holes at all. I am simply saying, I receive 20 prefixes of say /19 from 1 link and 40 of say /20 from the other. Most of these as far as I can see can be aggregated, but are still advertised as they are due to the presence of longest match paradigm However, I guess this is specific to my view, Though, why is there a problem in doing so? > >Its not worth it to aggregate the FIB. There is very little gain if >you don't aggregate over holes. > >If you aggregate over holes you'd need to include more specific reject >routes. > >If you aggregate the FIB and a withdraw occurs you need to add a >reject. You then need to be concerned about aggregating the rejects >that you are adding. > >Gain is small. There is an increase in completity. > >Disallowing longest to allow automatic aggregation was discussed on >BGP, BGPD, CIDR, or CIDRD more than 10 years ago. We didn't go that >way and its way too late to turn back. > >Curtis _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA07242 for ; Wed, 2 Jun 2004 22:15:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVhQo-0006WY-Uh; Wed, 02 Jun 2004 21:54:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVbZt-0006YV-IY for idr@megatron.ietf.org; Wed, 02 Jun 2004 15:39:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14321 for ; Wed, 2 Jun 2004 15:39:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVbZs-00027U-6z for idr@ietf.org; Wed, 02 Jun 2004 15:39:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVbYr-0001gM-00 for idr@ietf.org; Wed, 02 Jun 2004 15:38:06 -0400 Received: from 69.37.59.162.adsl.snet.net ([69.37.59.162] helo=workhorse.faster-light.net) by ietf-mx with esmtp (Exim 4.12) id 1BVbXo-00012s-00 for idr@ietf.org; Wed, 02 Jun 2004 15:37:00 -0400 Received: from workhorse.faster-light.net (localhost.fictitious.org [127.0.0.1]) by workhorse.faster-light.net (8.12.9p2/8.12.8) with ESMTP id i52JYL3W080016; Wed, 2 Jun 2004 15:34:21 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200406021934.i52JYL3W080016@workhorse.faster-light.net> To: "john smith" Subject: Re: [Idr] A question on longest match In-reply-to: Your message of "Wed, 02 Jun 2004 05:53:18 -0000." Date: Wed, 02 Jun 2004 15:34:21 -0400 From: Curtis Villamizar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: hcb@gettcomm.com, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org In message , "john smith" writes: > Thanks Howard, > > My question is more specific to the paradigm of longest match. > > In most cases, we have: > > (Routing protocols)-->Best > routes_based_on_metric/prefix_size/protocol_metric/foobar-->RIB-->FIB > > My question specifically is that do most vendors aggregate the entries when > they go from the RIB to the FIB? > > The problem specifically cropped up when I realised that some peers were > sending multiple /24s (even though they were contiguous) to a node I was > working on though the next-hop was the same. > > I was wondering if there is an "aggregation" performed based on next-hop > when putting routes into the FIB. > > Of course a more pragmatic approach is ofcourse to enforce aggregation > rather than have a prefix range propogation. > > However, I assume the biggest problem is the population of the FIB and hence > the need for prefix range filtering. > > Would it not be easier, for starters, to simply aggregate routes based on > next-hop when populating the FIB? > > this would not even break the longest match method used to balance links, > but would solve the FIB explosion problem. > > -John Its not worth it to aggregate the FIB. There is very little gain if you don't aggregate over holes. If you aggregate over holes you'd need to include more specific reject routes. If you aggregate the FIB and a withdraw occurs you need to add a reject. You then need to be concerned about aggregating the rejects that you are adding. Gain is small. There is an increase in completity. Disallowing longest to allow automatic aggregation was discussed on BGP, BGPD, CIDR, or CIDRD more than 10 years ago. We didn't go that way and its way too late to turn back. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA22840 for ; Wed, 2 Jun 2004 03:05:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVP9N-00011D-FJ; Wed, 02 Jun 2004 02:22:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVOjH-0006ti-1f for idr@megatron.ietf.org; Wed, 02 Jun 2004 01:56:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00726 for ; Wed, 2 Jun 2004 01:55:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVOjE-0002HP-Ru for idr@ietf.org; Wed, 02 Jun 2004 01:55:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVOiC-0001jE-00 for idr@ietf.org; Wed, 02 Jun 2004 01:54:53 -0400 Received: from bay17-f8.bay17.hotmail.com ([64.4.43.58] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BVOhA-0000nd-00 for idr@ietf.org; Wed, 02 Jun 2004 01:53:48 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 1 Jun 2004 22:53:19 -0700 Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Wed, 02 Jun 2004 05:53:18 GMT X-Originating-IP: [61.16.170.194] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: hcb@gettcomm.com, idr@ietf.org Subject: RE: [Idr] A question on longest match Date: Wed, 02 Jun 2004 05:53:18 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Jun 2004 05:53:19.0370 (UTC) FILETIME=[E7F4E6A0:01C44865] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.7 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Thanks Howard, My question is more specific to the paradigm of longest match. In most cases, we have: (Routing protocols)-->Best routes_based_on_metric/prefix_size/protocol_metric/foobar-->RIB-->FIB My question specifically is that do most vendors aggregate the entries when they go from the RIB to the FIB? The problem specifically cropped up when I realised that some peers were sending multiple /24s (even though they were contiguous) to a node I was working on though the next-hop was the same. I was wondering if there is an "aggregation" performed based on next-hop when putting routes into the FIB. Of course a more pragmatic approach is ofcourse to enforce aggregation rather than have a prefix range propogation. However, I assume the biggest problem is the population of the FIB and hence the need for prefix range filtering. Would it not be easier, for starters, to simply aggregate routes based on next-hop when populating the FIB? this would not even break the longest match method used to balance links, but would solve the FIB explosion problem. -John >From: "Howard C. Berkowitz" >To: idr@ietf.org >Subject: RE: [Idr] A question on longest match >Date: Tue, 1 Jun 2004 14:43:01 -0400 > >At 8:19 AM +0000 6/1/04, john smith wrote: >>Hello Big Brother, >> >>It is specifically releated to BGP. >> >>Aggregation in non DV protocols is not a possibility unless one goes >>across Area/Level boundarys. > >Maybe I'm missing something, but I wouldn't make that claim. Hierarchical >topology and multiple levels are not a requirement of routing protocols. >Many large ISPs run very big single ISIS areas. So, there very well may not >be Area/Level boundaries to cross. > >Hierarchical information hiding MAY be a useful deployment technique in LS >protocols to reduce the computational load of the Dijkstra algorithm, but >it's perfectly reasonable and plausible to build hierarchical networks in >protocols as simple as RIPv1 -- start with Class C (usually private space) >at the edge and work up, eventually going to Class B. > >> >>This is due to their inherent nature of sending advertisements of "all >>connected networks" to "all nodes in the same level or area". >> >>Now you do believe aggregation is good, do you not? I am sure you do! >> >>Now to further that assumption, if aggregation is good, and one was to >>make a forwarding device which would not do Layer 3 lookup based on the >>bit aligned boundaries, but on ranges, would it be considered bad or good? >> >>Also please let me know if this is not an item to dicuss on idr, or should >>the be specifically targetted to the routing-discussion mailing list? In >>that case I shall not cc the list further on these queries. >> >>-- >>(&) >>Little John. >> >>>From: "John Smith" >>>To: >>>Subject: RE: [Idr] A question on longest match >>>Date: Tue, 1 Jun 2004 13:43:25 +0530 >>> >>>Is your question related to BGP or is it related to general routing >>>(networking) principles? >>> >>>If its the latter then you need to start with a good book on basic >>>networking principles (unless ofcourse i am missing your point >>>altogether!) >>>and if its the latter, then it doesn't make much sense to me ! Care to >>>elaborate? >>> >>>-- >>>(&) >>>Big brother John >>> >>>----- Original Message ----- >>>From: "john smith" >>>To: >>>Sent: Tuesday, June 01, 2004 1:19 PM >>>Subject: [Idr] A question on longest match >>> >>> >>>> Hello, >>>> >>>> Is there any specific reason why the BGP algorithm relies on the >>>>longest >>>> match paradigm? >>>> >>>> Is there any reason why one cannot simply propogate the "range of >>>addresses" >>>> and use different metrics? >>>> For example one could say "address numbers 100000 - 212123 are here >>>>and >>>> 212124 - 312127 are there? >>>> >>>> Would this not lead to considerable reduction of the size of the >>>forwarding >>>> table? >>>> >>>> -- >>>> (&) >>>> Little John. >>>> >>>> _________________________________________________________________ >>>> Add photos to your messages with MSN 8. Get 2 months FREE*. >>>> http://join.msn.com/?page=features/featuredemail >>>> >>>> >>>> _______________________________________________ >>>> Idr mailing list >>>> Idr@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/idr >>>> >>> >> >>_________________________________________________________________ >>The new MSN 8: advanced junk mail protection and 2 months FREE* >>http://join.msn.com/?page=features/junkmail >> >> >>_______________________________________________ >>Idr mailing list >>Idr@ietf.org >>https://www1.ietf.org/mailman/listinfo/idr > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA22834 for ; Tue, 1 Jun 2004 22:04:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVKjg-0002yl-Lp; Tue, 01 Jun 2004 21:40:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVF3z-0003mm-0d for idr@megatron.ietf.org; Tue, 01 Jun 2004 15:36:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16077 for ; Tue, 1 Jun 2004 15:36:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVF3v-0006xE-20 for idr@ietf.org; Tue, 01 Jun 2004 15:36:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVEiA-0002Ru-00 for idr@ietf.org; Tue, 01 Jun 2004 15:14:11 -0400 Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx with esmtp (Exim 4.12) id 1BVEEX-0004i7-00 for idr@ietf.org; Tue, 01 Jun 2004 14:43:33 -0400 Received: from [192.168.0.2] (pcp09296126pcs.arlngt01.va.comcast.net[69.143.165.226]) by comcast.net (sccrmhc12) with ESMTP id <2004060118430301200e1rc9e> (Authid: hcb8); Tue, 1 Jun 2004 18:43:03 +0000 Mime-Version: 1.0 X-Sender: hcb8@smtp.comcast.net (Unverified) Message-Id: Date: Tue, 1 Jun 2004 14:43:01 -0400 To: idr@ietf.org From: "Howard C. Berkowitz" Subject: RE: [Idr] A question on longest match Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org At 8:19 AM +0000 6/1/04, john smith wrote: >Hello Big Brother, > >It is specifically releated to BGP. > >Aggregation in non DV protocols is not a possibility unless one goes >across Area/Level boundarys. Maybe I'm missing something, but I wouldn't make that claim. Hierarchical topology and multiple levels are not a requirement of routing protocols. Many large ISPs run very big single ISIS areas. So, there very well may not be Area/Level boundaries to cross. Hierarchical information hiding MAY be a useful deployment technique in LS protocols to reduce the computational load of the Dijkstra algorithm, but it's perfectly reasonable and plausible to build hierarchical networks in protocols as simple as RIPv1 -- start with Class C (usually private space) at the edge and work up, eventually going to Class B. > >This is due to their inherent nature of sending advertisements of >"all connected networks" to "all nodes in the same level or area". > >Now you do believe aggregation is good, do you not? I am sure you do! > >Now to further that assumption, if aggregation is good, and one was >to make a forwarding device which would not do Layer 3 lookup based >on the bit aligned boundaries, but on ranges, would it be considered >bad or good? > >Also please let me know if this is not an item to dicuss on idr, or >should the be specifically targetted to the routing-discussion >mailing list? In that case I shall not cc the list further on these >queries. > >-- >(&) >Little John. > >>From: "John Smith" >>To: >>Subject: RE: [Idr] A question on longest match >>Date: Tue, 1 Jun 2004 13:43:25 +0530 >> >>Is your question related to BGP or is it related to general routing >>(networking) principles? >> >>If its the latter then you need to start with a good book on basic >>networking principles (unless ofcourse i am missing your point altogether!) >>and if its the latter, then it doesn't make much sense to me ! Care to >>elaborate? >> >>-- >>(&) >>Big brother John >> >>----- Original Message ----- >>From: "john smith" >>To: >>Sent: Tuesday, June 01, 2004 1:19 PM >>Subject: [Idr] A question on longest match >> >> >>> Hello, >>> >>> Is there any specific reason why the BGP algorithm relies on the longest >>> match paradigm? >>> >>> Is there any reason why one cannot simply propogate the "range of >>addresses" >>> and use different metrics? >>> For example one could say "address numbers 100000 - 212123 are here and >>> 212124 - 312127 are there? >>> >>> Would this not lead to considerable reduction of the size of the >>forwarding >>> table? >>> >>> -- >>> (&) >>> Little John. >>> >>> _________________________________________________________________ >>> Add photos to your messages with MSN 8. Get 2 months FREE*. >>> http://join.msn.com/?page=features/featuredemail >>> >>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www1.ietf.org/mailman/listinfo/idr >>> >> > >_________________________________________________________________ >The new MSN 8: advanced junk mail protection and 2 months FREE* >http://join.msn.com/?page=features/junkmail > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA21334 for ; Tue, 1 Jun 2004 16:56:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVG42-0001TU-6p; Tue, 01 Jun 2004 16:40:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVCXV-0005bp-1y for idr@megatron.ietf.org; Tue, 01 Jun 2004 12:55:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25100 for ; Tue, 1 Jun 2004 12:54:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVCXT-0003TB-VX for idr@ietf.org; Tue, 01 Jun 2004 12:55:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVCSx-00020j-00 for idr@ietf.org; Tue, 01 Jun 2004 12:50:20 -0400 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1BVCNz-0000Mz-00 for idr@ietf.org; Tue, 01 Jun 2004 12:45:11 -0400 Received: from [192.168.0.2] (pcp09296126pcs.arlngt01.va.comcast.net[69.143.165.226]) by comcast.net (sccrmhc11) with ESMTP id <20040601164440011009lu73e> (Authid: hcb8); Tue, 1 Jun 2004 16:44:40 +0000 Mime-Version: 1.0 X-Sender: hcb8@smtp.comcast.net (Unverified) Message-Id: In-Reply-To: References: Date: Tue, 1 Jun 2004 12:44:38 -0400 To: idr@ietf.org From: "Howard C. Berkowitz" Subject: RE: [Idr] A question on longest match Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org At 8:19 AM +0000 6/1/04, john smith wrote: >Hello Big Brother, > >It is specifically releated to BGP. > >Aggregation in non DV protocols is not a possibility unless one goes >across Area/Level boundarys. Maybe I'm missing something, but I wouldn't make that claim. Hierarchical topology and multiple levels are not a requirement of routing protocols. Many large ISPs run very big single ISIS areas. So, there very well may not be Area/Level boundaries to cross. Hierarchical information hiding MAY be a useful deployment technique in LS protocols to reduce the computational load of the Dijkstra algorithm, but it's perfectly reasonable and plausible to build hierarchical networks in protocols as simple as RIPv1 -- start with Class C (usually private space) at the edge and work up, eventually going to Class B. > >This is due to their inherent nature of sending advertisements of >"all connected networks" to "all nodes in the same level or area". > >Now you do believe aggregation is good, do you not? I am sure you do! > >Now to further that assumption, if aggregation is good, and one was >to make a forwarding device which would not do Layer 3 lookup based >on the bit aligned boundaries, but on ranges, would it be considered >bad or good? > >Also please let me know if this is not an item to dicuss on idr, or >should the be specifically targetted to the routing-discussion >mailing list? In that case I shall not cc the list further on these >queries. > >-- >(&) >Little John. > >>From: "John Smith" >>To: >>Subject: RE: [Idr] A question on longest match >>Date: Tue, 1 Jun 2004 13:43:25 +0530 >> >>Is your question related to BGP or is it related to general routing >>(networking) principles? >> >>If its the latter then you need to start with a good book on basic >>networking principles (unless ofcourse i am missing your point altogether!) >>and if its the latter, then it doesn't make much sense to me ! Care to >>elaborate? >> >>-- >>(&) >>Big brother John >> >>----- Original Message ----- >>From: "john smith" >>To: >>Sent: Tuesday, June 01, 2004 1:19 PM >>Subject: [Idr] A question on longest match >> >> >>> Hello, >>> >>> Is there any specific reason why the BGP algorithm relies on the longest >>> match paradigm? >>> >>> Is there any reason why one cannot simply propogate the "range of >>addresses" >>> and use different metrics? >>> For example one could say "address numbers 100000 - 212123 are here and >>> 212124 - 312127 are there? >>> >>> Would this not lead to considerable reduction of the size of the >>forwarding >>> table? >>> >>> -- >>> (&) >>> Little John. >>> >>> _________________________________________________________________ >>> Add photos to your messages with MSN 8. Get 2 months FREE*. >>> http://join.msn.com/?page=features/featuredemail >>> >>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www1.ietf.org/mailman/listinfo/idr >>> >> > >_________________________________________________________________ >The new MSN 8: advanced junk mail protection and 2 months FREE* >http://join.msn.com/?page=features/junkmail > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA08672 for ; Tue, 1 Jun 2004 04:37:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV4bz-0002AE-8u; Tue, 01 Jun 2004 04:27:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV4Wu-00018E-1m for idr@megatron.ietf.org; Tue, 01 Jun 2004 04:21:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04968 for ; Tue, 1 Jun 2004 04:21:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BV4Wr-00050B-EY for idr@ietf.org; Tue, 01 Jun 2004 04:21:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BV4Vk-0004YW-00 for idr@ietf.org; Tue, 01 Jun 2004 04:20:41 -0400 Received: from bay17-f7.bay17.hotmail.com ([64.4.43.57] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BV4Ul-0003ff-00 for idr@ietf.org; Tue, 01 Jun 2004 04:19:39 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 1 Jun 2004 01:19:10 -0700 Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Tue, 01 Jun 2004 08:19:09 GMT X-Originating-IP: [61.16.170.194] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: jsmith4112003@yahoo.co.uk Subject: RE: [Idr] A question on longest match Date: Tue, 01 Jun 2004 08:19:09 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Jun 2004 08:19:10.0093 (UTC) FILETIME=[1D6183D0:01C447B1] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hello Big Brother, It is specifically releated to BGP. Aggregation in non DV protocols is not a possibility unless one goes across Area/Level boundarys. This is due to their inherent nature of sending advertisements of "all connected networks" to "all nodes in the same level or area". Now you do believe aggregation is good, do you not? I am sure you do! Now to further that assumption, if aggregation is good, and one was to make a forwarding device which would not do Layer 3 lookup based on the bit aligned boundaries, but on ranges, would it be considered bad or good? Also please let me know if this is not an item to dicuss on idr, or should the be specifically targetted to the routing-discussion mailing list? In that case I shall not cc the list further on these queries. -- (&) Little John. >From: "John Smith" >To: >Subject: RE: [Idr] A question on longest match >Date: Tue, 1 Jun 2004 13:43:25 +0530 > >Is your question related to BGP or is it related to general routing >(networking) principles? > >If its the latter then you need to start with a good book on basic >networking principles (unless ofcourse i am missing your point altogether!) >and if its the latter, then it doesn't make much sense to me ! Care to >elaborate? > >-- >(&) >Big brother John > >----- Original Message ----- >From: "john smith" >To: >Sent: Tuesday, June 01, 2004 1:19 PM >Subject: [Idr] A question on longest match > > > > Hello, > > > > Is there any specific reason why the BGP algorithm relies on the longest > > match paradigm? > > > > Is there any reason why one cannot simply propogate the "range of >addresses" > > and use different metrics? > > For example one could say "address numbers 100000 - 212123 are here and > > 212124 - 312127 are there? > > > > Would this not lead to considerable reduction of the size of the >forwarding > > table? > > > > -- > > (&) > > Little John. > > > > _________________________________________________________________ > > Add photos to your messages with MSN 8. Get 2 months FREE*. > > http://join.msn.com/?page=features/featuredemail > > > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www1.ietf.org/mailman/listinfo/idr > > > > _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA05605 for ; Tue, 1 Jun 2004 04:08:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV4A4-0005dA-EH; Tue, 01 Jun 2004 03:58:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV442-0004my-AM for idr@megatron.ietf.org; Tue, 01 Jun 2004 03:52:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03084 for ; Tue, 1 Jun 2004 03:52:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BV440-0007l7-2K for idr@ietf.org; Tue, 01 Jun 2004 03:52:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BV42y-0007HZ-00 for idr@ietf.org; Tue, 01 Jun 2004 03:50:57 -0400 Received: from bay17-f17.bay17.hotmail.com ([64.4.43.67] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BV42F-0006o9-00 for idr@ietf.org; Tue, 01 Jun 2004 03:50:11 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 1 Jun 2004 00:49:42 -0700 Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Tue, 01 Jun 2004 07:49:42 GMT X-Originating-IP: [61.16.170.194] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: idr@ietf.org Date: Tue, 01 Jun 2004 07:49:42 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Jun 2004 07:49:42.0391 (UTC) FILETIME=[FFBF9870:01C447AC] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Subject: [Idr] A question on longest match 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hello, Is there any specific reason why the BGP algorithm relies on the longest match paradigm? Is there any reason why one cannot simply propogate the "range of addresses" and use different metrics? For example one could say "address numbers 100000 - 212123 are here and 212124 - 312127 are there? Would this not lead to considerable reduction of the size of the forwarding table? -- (&) Little John. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr