Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA10476 for ; Thu, 28 Feb 2002 14:59:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4E0CF9135F; Thu, 28 Feb 2002 14:59:14 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F07F9135C; Thu, 28 Feb 2002 14:59:14 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 532BA9135F for ; Thu, 28 Feb 2002 14:59:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 36C475DDD6; Thu, 28 Feb 2002 14:59:09 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 058975DDE9 for ; Thu, 28 Feb 2002 14:59:09 -0500 (EST) Received: from paradigm.nexthop.com (mrichardson.nexthop.com [64.211.218.45]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g1SJwh340119; Thu, 28 Feb 2002 14:58:43 -0500 (EST) (envelope-from mrr@mrichardson.nexthop.com) Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g1SJwhe21291; Thu, 28 Feb 2002 14:58:43 -0500 (EST) Date: Thu, 28 Feb 2002 14:58:42 -0500 From: Mathew Richardson To: Kent Wong Cc: idr@merit.edu Subject: Re: Aggregate of Communities Attribute and AS Confed Message-ID: <20020228145842.A15125@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from wongkent@hotmail.com on Thu, Feb 28, 2002 at 06:52:21PM +0000 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk > Kent Wong [Thu, Feb 28, 2002 at 06:52:21PM +0000]: >Hi, > >Thanks Jeffrey for the previous answers. > >I have another questions about Aggregate > >1. In RFC 1997, it states that: > > If a range of routes is to be aggregated and the resultant aggregates > attribute section does not carry the ATOMIC_AGGREGATE attribute, then > the resulting aggregate should have a COMMUNITIES path attribute > which contains all communities from all of the aggregated routes. > >If I have three components falling into an aggregate. >With communities NO_EXPORT, NO_ADVERTISE, COMM X. Does it mean the >final aggregate will have all 3 communities? Yes, this is what it means. >But will this case >make sense since the community attributes are of different meanings? As to whether it makes sense or not, it would depend largely on your network configuration... certainly, there is nothing illegal about a route that has two different well-known communities, and some random other community. >2. I could not find in any place about how to aggregate the >AS PATH attribute if there are AS-CONFED-SEQ, AS-CONFED-SET, AS-SEQ, >AS-SET mixed in the AS PATH attributes of the component routes. >What should be the algorithm to calculate the final aggregate >AS Path in such case? The most obvious way to aggregate such an AS_PATH is to perform the base aggregation on both the confederation segments, and then on the non-confederation segments. There are certainly other algorithms that could also be used. This should probably be addressed in the Confederations specification, along with a minimum supported aggregation algorithm. It's worth noting that you should never receive confederation segments as anything other than the leading segments of an AS_PATH... mrr Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA07761 for ; Thu, 28 Feb 2002 13:52:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B6C5E91351; Thu, 28 Feb 2002 13:52:27 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 81C9391352; Thu, 28 Feb 2002 13:52:27 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6009191351 for ; Thu, 28 Feb 2002 13:52:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3D6AD5DDD6; Thu, 28 Feb 2002 13:52:26 -0500 (EST) Delivered-To: idr@merit.edu Received: from hotmail.com (f70.law7.hotmail.com [216.33.237.70]) by segue.merit.edu (Postfix) with ESMTP id F0CCB5DDA0 for ; Thu, 28 Feb 2002 13:52:25 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 28 Feb 2002 10:52:21 -0800 Received: from 63.104.212.252 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 28 Feb 2002 18:52:21 GMT X-Originating-IP: [63.104.212.252] From: "Kent Wong" To: idr@merit.edu Subject: Aggregate of Communities Attribute and AS Confed Date: Thu, 28 Feb 2002 18:52:21 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Feb 2002 18:52:21.0568 (UTC) FILETIME=[0DAE8C00:01C1C089] Sender: owner-idr@merit.edu Precedence: bulk Hi, Thanks Jeffrey for the previous answers. I have another questions about Aggregate 1. In RFC 1997, it states that: If a range of routes is to be aggregated and the resultant aggregates attribute section does not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate should have a COMMUNITIES path attribute which contains all communities from all of the aggregated routes. If I have three components falling into an aggregate. With communities NO_EXPORT, NO_ADVERTISE, COMM X. Does it mean the final aggregate will have all 3 communities? But will this case make sense since the community attributes are of different meanings? 2. I could not find in any place about how to aggregate the AS PATH attribute if there are AS-CONFED-SEQ, AS-CONFED-SET, AS-SEQ, AS-SET mixed in the AS PATH attributes of the component routes. What should be the algorithm to calculate the final aggregate AS Path in such case? Thanks. ---Kent Wong _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA07870 for ; Wed, 27 Feb 2002 16:39:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 67AD691332; Wed, 27 Feb 2002 16:38:09 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3AE32912DD; Wed, 27 Feb 2002 16:38:09 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 97DBC91233 for ; Wed, 27 Feb 2002 16:38:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 81AA65DF00; Wed, 27 Feb 2002 16:38:05 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 3B9935DE8C for ; Wed, 27 Feb 2002 16:38:05 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g1RLbg308321; Wed, 27 Feb 2002 16:37:42 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g1RLaea03715; Wed, 27 Feb 2002 16:36:40 -0500 (EST) Date: Wed, 27 Feb 2002 16:36:40 -0500 From: Jeffrey Haas To: Alex Zinin Cc: idr@merit.edu Subject: Re: counting AS-path length Message-ID: <20020227163640.A3697@nexthop.com> References: <20020215152935.A4906@nexthop.com> <2394755781.20020219141143@nexsi.com> <20020220122322.F22759@nexthop.com> <126168323846.20020220103753@nexsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <126168323846.20020220103753@nexsi.com>; from azinin@nexsi.com on Wed, Feb 20, 2002 at 10:37:53AM -0800 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Wed, Feb 20, 2002 at 10:37:53AM -0800, Alex Zinin wrote: > Hmmm... I was under impression that most widely deployed > implementations do max pack TLVs, and since it is a natural > thing to do, I think it makes sense to explicitly say so. > Unless of course this message triggers an avalanche of replies > saying "we don't do this and think it is better..." Actually, I had received a comment that said they had found the contrary in some implementations. > If I were to choose between two options: > > 1) state that TLVs should be max packed and do not require > "merger" of adjacent sets for calculation, and Based on our conversation offline, this seems to be the most reasonable thing to do. Additionally, a field has been added to the v2MIB that shows the calculated length for route selection purposes. Does anyone disagree that this recommendation should be added to the specification? > Alex. -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA25214 for ; Wed, 27 Feb 2002 10:06:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5292991316; Wed, 27 Feb 2002 10:00:55 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C6F1B91313; Wed, 27 Feb 2002 10:00:54 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9E86291314 for ; Wed, 27 Feb 2002 10:00:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7F5795DDCA; Wed, 27 Feb 2002 10:00:42 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 3868E5DD9D for ; Wed, 27 Feb 2002 10:00:42 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g1RF0S397210; Wed, 27 Feb 2002 10:00:28 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020227100019.03b99c80@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 27 Feb 2002 10:00:27 -0500 To: Randy Bush From: Susan Hares Subject: Re: Last Call on TCP MD5 Signature Option Cc: Andy Heffernan , Alex Zinin , Susan Hares , idr@merit.edu, yakov Rekhter , fenner@att.com In-Reply-To: References: <200202270446.g1R4k0i77983@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk We can always revise later. Sue At 10:21 PM 2/26/2002 -0800, Randy Bush wrote: > > But speaking of orthogonal problems, if this is a sufficiently > > controversial issue to delay the advancement process, I'd just as soon > > drop mention of IPSEC in the draft. > >that might be wise > >randy Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA25179 for ; Wed, 27 Feb 2002 10:05:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8192B91311; Wed, 27 Feb 2002 10:00:13 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C9E691312; Wed, 27 Feb 2002 10:00:13 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2597291311 for ; Wed, 27 Feb 2002 10:00:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id E053F5DDD2; Wed, 27 Feb 2002 10:00:08 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 96D175DDCA for ; Wed, 27 Feb 2002 10:00:08 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g1RExc397155; Wed, 27 Feb 2002 09:59:38 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020227095911.03b937c0@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 27 Feb 2002 09:59:37 -0500 To: Alex Zinin From: Susan Hares Subject: Re: Last Call on TCP MD5 Signature Option Cc: Andy Heffernan , Susan Hares , idr@merit.edu, yakov Rekhter , , randy Bush In-Reply-To: <10796757840.20020226181914@nexsi.com> References: <200202270208.g1R28ei72856@merlot.juniper.net> <200202270208.g1R28ei72856@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk IPSec draft6 is by David Ward. It will be proposed for an IDR working group draft. Discussion at the next IETF. Sue At 06:19 PM 2/26/2002 -0800, Alex Zinin wrote: >Andy, > > > In section 5.0, IPSEC is mentioned as the preferred solution for BGP > > in IPv6 networks. > >I couldn't find this in the draft off the IDR WG page... > >Alex. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA07212 for ; Tue, 26 Feb 2002 21:20:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7077C912B5; Tue, 26 Feb 2002 21:19:46 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3A07C912B7; Tue, 26 Feb 2002 21:19:46 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 508D6912B5 for ; Tue, 26 Feb 2002 21:19:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 332B55DDBB; Tue, 26 Feb 2002 21:19:45 -0500 (EST) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (system134.nexsi.com [66.35.197.134]) by segue.merit.edu (Postfix) with ESMTP id A5B105DDA1 for ; Tue, 26 Feb 2002 21:19:44 -0500 (EST) Received: from khonsu.sw.nexsi.com (khonsu.sw.nexsi.com [192.168.104.146] (may be forged)) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id SAA11921; Tue, 26 Feb 2002 18:18:05 -0800 Date: Tue, 26 Feb 2002 18:19:14 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <10796757840.20020226181914@nexsi.com> To: Andy Heffernan Cc: Susan Hares , idr@merit.edu, yakov Rekhter , , randy Bush Subject: Re: Last Call on TCP MD5 Signature Option In-Reply-To: <200202270208.g1R28ei72856@merlot.juniper.net> References: <200202270208.g1R28ei72856@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Andy, > In section 5.0, IPSEC is mentioned as the preferred solution for BGP > in IPv6 networks. I couldn't find this in the draft off the IDR WG page... Alex. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA26192 for ; Tue, 26 Feb 2002 13:24:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EBE6991292; Tue, 26 Feb 2002 13:24:02 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C144D91291; Tue, 26 Feb 2002 13:24:01 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2912B91297 for ; Tue, 26 Feb 2002 13:23:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 08D575DDCB; Tue, 26 Feb 2002 13:23:59 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id CB5935DDD2 for ; Tue, 26 Feb 2002 13:23:58 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g1QINM366581; Tue, 26 Feb 2002 13:23:22 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020226132143.03b2b888@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 26 Feb 2002 13:23:21 -0500 To: Andy Heffernan From: Susan Hares Subject: Re: Last Call on TCP MD5 Signature Option Cc: Alex Zinin , Susan Hares , idr@merit.edu, yakov Rekhter , fenner@att.com, randy Bush In-Reply-To: <200202261722.g1QHMFi43249@merlot.juniper.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Format from draft-ietf-idr-rfc2858bis-00.txt, please copy and re-post. 11. Comparison with RFC2858 This document makes the use of the next hop information consistent with the information carried in the NEXT_HOP BGP path attribute. 12. Comparison with RFC2283 This document restricts the MP_REACH_NLRI attribute to carry only a single instance of . This document restricts the MP_UNREACH_NLRI attribute to carry only a single instance of . This document clarifies handling of an UPDATE message that carries no NLRI, other than the one encoded in the MP_REACH_NLRI attribute. This document clarifies error handling in the presence of MP_REACH_NLRI or MP_UNREACH_NLRI attributes. This document specifies the use of BGP Capabilities Advertisements in conjunction with Multi-protocol extensions. Finally, this document includes the "IANA Consideration" Section. At 09:22 AM 2/26/2002 -0800, Andy Heffernan wrote: >I can do this. Is there an existing RFC or draft that has >the desired format of this Appendix? > > > > > It would really be nice if the document had an appendix > > describing the changes from 2385. It is also a good idea > > to send the text of appendix to the list now to help people > > during the last call review. > > > > -- > > Alex Zinin > > > > Monday, February 25, 2002, 2:01:10 PM, Susan Hares wrote: > > > > > > > Folks: > > > > > This is to start the IDR WG Last call on advancing > > > > > Protection of BGP Sessions via the TCP MD5 Signature Option > > > (draft-ietf-idr-rfc2385bis-00.txt) to Draft-Standard. > > > > > The last call ends on 3/11. > > > > > Sue Hares > > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA25677 for ; Tue, 26 Feb 2002 12:59:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2ED189128E; Tue, 26 Feb 2002 12:58:47 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE85A9128F; Tue, 26 Feb 2002 12:58:46 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 16F839128E for ; Tue, 26 Feb 2002 12:58:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id EF02E5DDBF; Tue, 26 Feb 2002 12:58:45 -0500 (EST) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (system134.nexsi.com [66.35.197.134]) by segue.merit.edu (Postfix) with ESMTP id 6A2605DDA1 for ; Tue, 26 Feb 2002 12:58:45 -0500 (EST) Received: from khonsu.sw.nexsi.com (khonsu.sw.nexsi.com [192.168.104.146] (may be forged)) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id JAA07991; Tue, 26 Feb 2002 09:56:52 -0800 Date: Tue, 26 Feb 2002 09:58:00 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <12866685949.20020226095800@nexsi.com> To: Andy Heffernan Cc: Susan Hares , idr@merit.edu, yakov Rekhter , , randy Bush Subject: Re: Last Call on TCP MD5 Signature Option In-Reply-To: <200202261722.g1QHMFi43249@merlot.juniper.net> References: <200202261722.g1QHMFi43249@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Andy, Absolutely. You can take a look at draft-ietf-idr-bgp4-17.txt or draft-ietf-idr-rfc2858bis-00.txt. I don't think there's any type of special format, just a list of changes (with reasons explained if not obvious) should be sufficient. Thanks. -- Alex Zinin Tuesday, February 26, 2002, 9:22:15 AM, Andy Heffernan wrote: > I can do this. Is there an existing RFC or draft that has > the desired format of this Appendix? >> >> It would really be nice if the document had an appendix >> describing the changes from 2385. It is also a good idea >> to send the text of appendix to the list now to help people >> during the last call review. >> >> -- >> Alex Zinin >> Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA11017 for ; Tue, 26 Feb 2002 03:06:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2B30691259; Tue, 26 Feb 2002 03:05:25 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A708D9126A; Tue, 26 Feb 2002 03:05:24 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7567691259 for ; Tue, 26 Feb 2002 03:05:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 364DA5DDC5; Tue, 26 Feb 2002 03:05:20 -0500 (EST) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (system134.nexsi.com [66.35.197.134]) by segue.merit.edu (Postfix) with ESMTP id CF0195DDAB for ; Tue, 26 Feb 2002 03:05:19 -0500 (EST) Received: from khonsu.sw.nexsi.com ([192.168.103.207]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id AAA06261; Tue, 26 Feb 2002 00:03:31 -0800 Date: Tue, 26 Feb 2002 00:04:39 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <3231085198.20020226000439@nexsi.com> To: Susan Hares Cc: idr@merit.edu, yakov Rekhter , fenner@att.com, randy Bush , Subject: Re: Last Call on TCP MD5 Signature Option In-Reply-To: <5.0.0.25.0.20020225165827.02d819c0@mail.nexthop.com> References: <5.0.0.25.0.20020225165827.02d819c0@mail.nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk It would really be nice if the document had an appendix describing the changes from 2385. It is also a good idea to send the text of appendix to the list now to help people during the last call review. -- Alex Zinin Monday, February 25, 2002, 2:01:10 PM, Susan Hares wrote: > Folks: > This is to start the IDR WG Last call on advancing > Protection of BGP Sessions via the TCP MD5 Signature Option > (draft-ietf-idr-rfc2385bis-00.txt) to Draft-Standard. > The last call ends on 3/11. > Sue Hares Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA01330 for ; Mon, 25 Feb 2002 20:58:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 368CA91265; Mon, 25 Feb 2002 20:58:18 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0258791266; Mon, 25 Feb 2002 20:58:17 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0406E91265 for ; Mon, 25 Feb 2002 20:58:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id DB6475DDA7; Mon, 25 Feb 2002 20:58:06 -0500 (EST) Delivered-To: idr@merit.edu Received: from titanium.zebra.org (12-236-104-79.client.attbi.com [12.236.104.79]) by segue.merit.edu (Postfix) with ESMTP id 4BCC65DD9A for ; Mon, 25 Feb 2002 20:58:06 -0500 (EST) Received: from titanium.zebra.org (IDENT:kunihiro@localhost [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id UAA00706; Mon, 25 Feb 2002 20:00:41 -0500 Date: Mon, 25 Feb 2002 17:00:41 -0800 Message-ID: From: Kunihiro Ishiguro To: Mareline Sheldon Cc: idr@merit.edu Subject: Re: BGP - OSPF interaction In-Reply-To: <20020226013910.24517.qmail@web20305.mail.yahoo.com> References: <20020226013910.24517.qmail@web20305.mail.yahoo.com> User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.1 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk >What is the status of the RFC 1745 >(BGP-OSPF Interaction). Are the new implementations >being written support it? It is historic. Please refer RFC3167. -- Kunihiro Ishiguro Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA01280 for ; Mon, 25 Feb 2002 20:56:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B957E91263; Mon, 25 Feb 2002 20:55:49 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 830E591264; Mon, 25 Feb 2002 20:55:49 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 892B991263 for ; Mon, 25 Feb 2002 20:55:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 624655DDA3; Mon, 25 Feb 2002 20:55:48 -0500 (EST) Delivered-To: idr@merit.edu Received: from launch.server101.com (launch.server101.com [216.218.196.178]) by segue.merit.edu (Postfix) with ESMTP id ADC305DD9A for ; Mon, 25 Feb 2002 20:55:47 -0500 (EST) Received: from LYSANDER (s3.dial1.qcy.nac.net [209.123.56.54]) (authenticated as dunn@dunn.org with LOGIN) by launch.server101.com (8.11.2/8.11.2) with ESMTP id g1Q1tiu31736; Tue, 26 Feb 2002 11:55:45 +1000 Message-ID: <003601c1be68$b473f8e0$02c8a8c0@LYSANDER> From: "Bradley Dunn" To: "Mareline Sheldon" Cc: References: <20020226013910.24517.qmail@web20305.mail.yahoo.com> Subject: Re: BGP - OSPF interaction Date: Mon, 25 Feb 2002 20:55:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idr@merit.edu Precedence: bulk > What is the status of the RFC 1745 > (BGP-OSPF Interaction). Are the new implementations > being written support it? No. RFC 1745's status is historic. See RFC 3167. Bradley Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA00874 for ; Mon, 25 Feb 2002 20:39:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 57CD891262; Mon, 25 Feb 2002 20:39:13 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27A2D91263; Mon, 25 Feb 2002 20:39:13 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 27A2691262 for ; Mon, 25 Feb 2002 20:39:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 029125DDA7; Mon, 25 Feb 2002 20:39:12 -0500 (EST) Delivered-To: idr@merit.edu Received: from web20305.mail.yahoo.com (web20305.mail.yahoo.com [216.136.226.86]) by segue.merit.edu (Postfix) with SMTP id B6D315DD9A for ; Mon, 25 Feb 2002 20:39:11 -0500 (EST) Message-ID: <20020226013910.24517.qmail@web20305.mail.yahoo.com> Received: from [165.213.0.2] by web20305.mail.yahoo.com via HTTP; Mon, 25 Feb 2002 17:39:10 PST Date: Mon, 25 Feb 2002 17:39:10 -0800 (PST) From: Mareline Sheldon Subject: BGP - OSPF interaction To: idr@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Hi, What is the status of the RFC 1745 (BGP-OSPF Interaction). Are the new implementations being written support it? regards, mareline s. __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA25956 for ; Mon, 25 Feb 2002 17:02:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8EE9391257; Mon, 25 Feb 2002 17:01:37 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CAD19125F; Mon, 25 Feb 2002 17:01:37 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 23D6091257 for ; Mon, 25 Feb 2002 17:01:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id F0A415DDA3; Mon, 25 Feb 2002 17:01:35 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 8A3095DD9C for ; Mon, 25 Feb 2002 17:01:35 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g1PM1B338194; Mon, 25 Feb 2002 17:01:11 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020225165827.02d819c0@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 25 Feb 2002 17:01:10 -0500 To: idr@merit.edu From: Susan Hares Subject: Last Call on TCP MD5 Signature Option Cc: yakov Rekhter , fenner@att.com, randy Bush , skh@nexthop.com, ahh@juniper.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Folks: This is to start the IDR WG Last call on advancing Protection of BGP Sessions via the TCP MD5 Signature Option (draft-ietf-idr-rfc2385bis-00.txt) to Draft-Standard. The last call ends on 3/11. Sue Hares Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA12625 for ; Mon, 25 Feb 2002 09:28:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9C40091245; Mon, 25 Feb 2002 09:28:16 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63EF291246; Mon, 25 Feb 2002 09:28:16 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 65FBE91245 for ; Mon, 25 Feb 2002 09:28:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4DFB65DDE1; Mon, 25 Feb 2002 09:28:15 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 06D3F5DDBA for ; Mon, 25 Feb 2002 09:28:15 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g1PERi325955 for ; Mon, 25 Feb 2002 09:27:45 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g1PEQrk12396 for idr@merit.edu; Mon, 25 Feb 2002 09:26:53 -0500 (EST) Date: Mon, 25 Feb 2002 09:26:52 -0500 From: Jeffrey Haas To: idr@merit.edu Subject: Re: Questions on ATOMIC Aggregate AND Aggregate of AS PATH Message-ID: <20020225092652.B12323@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from wongkent@hotmail.com on Sat, Feb 23, 2002 at 02:03:15AM +0000 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Sat, Feb 23, 2002 at 02:03:15AM +0000, Kent Wong wrote: > If I learn 10.0.0.0/8 and 10.1.0.0/16 and I decide to advertise > 10.0.0.0/8 as aggregate BUT I make sure the aggregate contains > all the as path information of both routes, in that case, the aggregate > route didn't lose any as path information, do I still need to add > the ATOMIC_AGGREGATE to the aggregate route? Yes, by the current wording of the spec. Logically, no you needn't. Atomic aggregate isn't a very useful thing in the spec. > 2. In Sec 9.2.2.2 Aggregating As Path information, > If I have the following two routes with as path: > Route 1: AS-SEQ: 100 200 300 200 400 500 > Route 2: AS-SEQ: 100 200 300 200 400 AS-SET 700 800 This is a loop and I would hope you've discarded the route. > ---Kent -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA15209 for ; Fri, 22 Feb 2002 21:03:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3C4CD91235; Fri, 22 Feb 2002 21:03:18 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E5A7912C4; Fri, 22 Feb 2002 21:03:17 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BB3E291235 for ; Fri, 22 Feb 2002 21:03:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9B2B85DDB4; Fri, 22 Feb 2002 21:03:16 -0500 (EST) Delivered-To: idr@merit.edu Received: from hotmail.com (f202.law7.hotmail.com [216.33.237.202]) by segue.merit.edu (Postfix) with ESMTP id 5B9155DDAF for ; Fri, 22 Feb 2002 21:03:16 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Feb 2002 18:03:15 -0800 Received: from 63.104.212.252 by lw7fd.law7.hotmail.msn.com with HTTP; Sat, 23 Feb 2002 02:03:15 GMT X-Originating-IP: [63.104.212.252] From: "Kent Wong" To: idr@merit.edu Subject: Questions on ATOMIC Aggregate AND Aggregate of AS PATH Date: Sat, 23 Feb 2002 02:03:15 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Feb 2002 02:03:15.0993 (UTC) FILETIME=[41A43890:01C1BC0E] Sender: owner-idr@merit.edu Precedence: bulk Hi, I have questions about ATOMIC aggregate and aggregate of as path information. 1. On draft 17, Section 9.1.4 Overlapping routes: |If a BGP speaker receives overlapping routes, the Decision Process |MUST consider both routes based on the configured acceptance policy. |If both a less and a more specific route are accepted, then the |Decision Process MUST either install both the less and the more |specific routes or it MUST aggregate the two routes and install the |aggregated route, provided that both routes have the same value of |the NEXT_HOP attribute. |If a BGP speaker chooses to aggregate, then it MUST add |ATOMIC_AGGREGATE attribute to the route. e.g. If I learn 10.0.0.0/8 and 10.1.0.0/16 and I decide to advertise 10.0.0.0/8 as aggregate BUT I make sure the aggregate contains all the as path information of both routes, in that case, the aggregate route didn't lose any as path information, do I still need to add the ATOMIC_AGGREGATE to the aggregate route? 2. In Sec 9.2.2.2 Aggregating As Path information, If I have the following two routes with as path: Route 1: AS-SEQ: 100 200 300 200 400 500 Route 2: AS-SEQ: 100 200 300 200 400 AS-SET 700 800 And I decide to form an aggregate of these two routes, under the specified rules, what should be the final as path? I think it would be: AS-SEQ: 100 200 300 AS-SET: 400 500 700 800 Because 200 cannot re-appear again in the leading AS-SEQ and all the rest should be put in AS-SET without duplication of value in AS-SEQ. Am I correct? Thanks. ---Kent _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA08629 for ; Fri, 22 Feb 2002 16:25:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CF6A29125A; Fri, 22 Feb 2002 16:25:06 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99373912DC; Fri, 22 Feb 2002 16:25:06 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2D8F49125A for ; Fri, 22 Feb 2002 16:25:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0AA255DE36; Fri, 22 Feb 2002 16:25:05 -0500 (EST) Delivered-To: idr@merit.edu Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 684855DE15 for ; Fri, 22 Feb 2002 16:25:04 -0500 (EST) Received: by sentry.gw.tislabs.com; id QAA05660; Fri, 22 Feb 2002 16:30:34 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma005647; Fri, 22 Feb 02 16:29:40 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g1MLO9026702; Fri, 22 Feb 2002 16:24:09 -0500 (EST) Date: Fri, 22 Feb 2002 16:24:09 -0500 (EST) Message-Id: <200202222124.g1MLO9026702@raven.gw.tislabs.com> From: sandy@tislabs.com To: idr@merit.edu Subject: new draft: draft-murphy-bgp-protect-00.txt Cc: sandy@tislabs.com Sender: owner-idr@merit.edu Precedence: bulk Network Working Group Sandra Murphy INTERNET DRAFT NAI Labs draft-murphy-bgp-protect-00.txt February 2002 BGP Security Protections Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract BGP, along with a host of other infrastructure protocols designed before the Internet environment became perilous, is designed with little consideration for protection of the information it carries. There are no mechanisms in BGP to protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior. This internet draft discusses some of the security issues with BGP routing data dissemination, and possible security solutions and the costs of those solutions. This internet draft does not discuss security issues with forwarding of packets. Murphy Expires: August 2002 [Page 1] INTERNET DRAFT BGP Security Protections November 2001 Table of Contents Status of this Memo .............................................. 1 Abstract ......................................................... 1 1 Introduction .................................................... 3 2 Possible Protections ............................................ 4 2.1 Threats from outsiders ........................................ 4 2.1.1 IP level protection ......................................... 5 2.1.2 TCP level protection ........................................ 5 2.2 Threats from BGP peers ........................................ 5 2.3 Origination Protection ........................................ 6 2.4 Origination and Adjacency Protection .......................... 7 2.5 Origination and Route Protection .............................. 8 2.5.1 Remaining Issues ............................................ 9 2.6 Filtering ..................................................... 11 3 Security Costs .................................................. 12 3.1 Protecting the Peer-Peer Link ................................. 12 3.2 Origination Protection ........................................ 12 3.3 Origination and Adjacency Protection .......................... 13 3.4 Origination and Route Protection .............................. 13 3.5 Filtering ..................................................... 14 4 Security Considerations ......................................... 14 5 References ...................................................... 14 6 Author's Address ................................................ 15 Murphy Expires: August 2002 [Page 2] INTERNET DRAFT BGP Security Protections November 2001 1. Introduction The inter-domain routing protocol BGP was created when the Internet environment had not yet reached the present contentious state. Consequently, the BGP protocol was not designed with protection against deliberate or accidental errors causing disruptions of routing behavior. Other work [11] discusses the vulnerabilities of BGP, based on the BGP RFC [1] and on [2]. We here propose several different security solutions to protect these vulnerabilities and discuss the benefits derived from each solution and its cost. Readers are expected to be familiar with the BGP RFC and the behavior of BGP. It is clear that the Internet is vulnerable to attack through its routing protocols. BGP is no exception. Faulty, misconfigured or deliberately malicious sources can disrupt overall Internet behavior by injecting bogus routing information into the BGP distributed routing database (by modifying, forging, or replaying BGP packets). The same methods can also be used to disrupt local and overall network behavior by breaking the distributed communication of information between BGP peers. The sources of bogus information can be either outsiders or true BGP peers. Under the present BGP design, cryptographic authentication of the peer- peer communication is not mandated. As a TCP/IP protocol, BGP is subject to all the TCP/IP attacks, like IP spoofing, session stealing, etc. Any outsider can inject believable BGP messages into the communication between BGP peers and thereby inject bogus routing information or break the peer to peer connection. Any break in the peer to peer communication has a ripple effect on routing that can be wide spread. Furthermore, outsider sources can also disrupt communications between BGP peers by breaking their TCP connection with spoofed RST packets. Outsider sources of bogus BGP information can reside anywhere in the world. BGP speakers themselves can inject bogus routing information, either by masquerading as information from any other legitimate BGP speaker, or by distributing unauthentic routing information as themselves. Historically, misconfigured and faulty routers have been responsible for widespread disruptions in the Internet. The damage that might result from these attacks is discussed in [11]. The risks in BGP arise from three fundamental vulnerabilities: Murphy Expires: August 2002 [Page 3] INTERNET DRAFT BGP Security Protections November 2001 no mechanism has been mandated that provides strong protection of the integrity, freshness and source authenticity of the messages in peer-peer BGP communications. no mechanism has been specified to validate the authority of an AS to announce NLRI information. no mechanism has been specified to ensure the authenticity of the AS_PATH announced by an AS. There are four different BGP message types - OPEN, KEEPALIVE, NOTIFICATION, and UPDATE. A discussion of the vulnerabilities arising from each message and the ability of outsiders or BGP peers to exploit the vulnerabilities is contained in [11]. To summarize, outsiders can use bogus OPEN, KEEPALIVE, or NOTIFICATION messages to disrupt the BGP peer-peer connections and can use bogus UPDATE messages to disrupt routing. Outsiders can also disrupt BGP peer-peer connections by inserting bogus TCP RST packets. BGP peers themselves are permitted to break peer-peer connections at any time, and so they cannot be said to be issuing "bogus" OPEN, KEEPALIVE or NOTIFICATION messages. However, BGP peers can disrupt routing by issuing bogus UPDATE messages. In particular, bogus ATOMIC_AGGREGATE and AS_PATH attributes and bogus NLRI in UPDATE messages can disrupt routing. 2. Possible Protections 2.1. Threats from outsiders Outsiders can be prevented from disrupting routing by providing cryptographic protection of the BGP peer-peer connection. The cryptography chosen should protect the source authenticity and integrity of the message and should also protect against replay. As the protection is only of the peer-peer communications, asymmetric cryptography is not needed. Two different protection against spoofing in the peer-peer connection have been suggested: IP level protection as defined by IPSEC [7] TCP level protection as defined by [8] Prevention of IP spoofing completely removes any risk associated with bogus OPEN, KEEPALIVE, or NOTIFICATION messages, as the only vulnerabilities from these messages come from outsiders. It also protects against all threats from bogus UPDATE messages and from bogus TCP messages arising from outsiders. Murphy Expires: August 2002 [Page 4] INTERNET DRAFT BGP Security Protections November 2001 2.1.1. IP level protection Protection as specified for the IPSEC [7] can be used to provide connectionless integrity, data origin authentication, and a anti-replay service. 2.1.2. TCP level protection It is possible to protect the peer-peer connection by applying cryptographic protection at the TCP level to provide connectionless integrity and data origin authentication. This has been in use with some vendors for some time as specified in [8]. Note, however, that the protections specified in [8] were put in place some time ago. The IPSEC protections have advanced since that time. In particular, the protections of [8] use MD5 directly, where the IPSEC protections mandate the use of HMAC-MD5 because of recently publicized concerns of collisions in MD5. Also, [8] does not have the provisions for anti- reply found in IPSEC. The TCP sequence numbers do provide some protection against replay. But as some packets, notably a RST packet, need only be within the receive window to be accepted, the TCP sequence number protection is not complete. Finally, [8] has no provisions for multiple keys to be used in rekeying. As these are pairwise keys used for long-lived sessions, the inability to specify multiple keys may not cause operational difficulties. Although the TCP level protection specified in [8] has deficiencies when compared with the protection of IPSEC [7], it is vastly preferable to a unprotected connection. If IPSEC is not available, then the TCP level protection of [8] should definitely be used. When IPSEC is available, IPSEC is preferable. One or the other must be used. 2.2. Threats from BGP peers Protection of the communication between BGP peers does nothing to protect against errors introduced by the BGP speakers themselves. BGP speakers can introduce bogus routing information, e.g., invalid AS_PATHs, false origination announcements of NLRI, etc., at any time. Furthermore, detecting the BGP source of bogus information (if and when the bogus-ness is detected) can be difficult if not impossible. There are several possible solutions to prevent a BGP speaker from inserting bogus information in its advertisements to its peers. (1) Origination Protection: sign the originating AS. Murphy Expires: August 2002 [Page 5] INTERNET DRAFT BGP Security Protections November 2001 (2) Origination and Adjacency Protection: sign the originating AS and predecessor information. (3) Origination and Route Protection: sign the originating AS, and nest signatures of AS_PATHs to the number of consecutive bad routers you want to prevent from causing damage. (4) Filtering: rely on a registry to verify the AS_PATH and NLRI originating AS. The first three solutions are implemented within the protocol exchanges. The last solution is an operational protection and leaves the protocol messages unchanged. 2.3. Origination Protection It would be beneficial to authenticate the AS that first advertises a route to a NLRI. This could be done by including a new path attribute which would contain the originating AS number and the originating AS's digital signature [4] of the AS number plus the NLRI advertised. A digital signature (as opposed to a message integrity check using a shared secret) is preferable because the number and identities of all eventual recipients are not known and because non-repudiation would be desired. If routing was disturbed by the presence of this advertisement, then the culprit could be determined. If an infra-structure exists representing ownership of network addresses, then the owner as well as the originator could sign. This signature would indicate that the AS was authorized by the owner to originate the network. A BGP speaker receiving a protected origination could verify that the origination was legitimate. If routes are aggregated by a BGP speaker and the aggregated route advertised, then the idea of "originator" and "owner" become less useful. There might be several "originators" and "owners" represented among the aggregated routes. Furthermore, aggregation prevents identification of the specific culprit should it be discovered that a network is being originated incorrectly. The AGGREGATOR field could be mandatory and an aggregating BGP speaker could append its signature of the AGGREGATOR field and the aggregated NLRI. The protection of the AGGREGATOR field would make it possible to trace an incorrectly originated network back to an aggregation point. Unfortunately, the protection of the aggregator information still does not make it possible to discover the culprit who is incorrectly Murphy Expires: August 2002 [Page 6] INTERNET DRAFT BGP Security Protections November 2001 originating a network. The aggregation point, however, would have the information necessary to continue the trace, at least to the next aggregation point. This protection does not ensure that the AS_PATH is authentic or current. 2.4. Origination and Adjacency Protection Reference [3] suggests several different types of cryptographic protection of BGP. The suggested protection against possibly faulty BGP speakers introduces some link state topology information (as in OSPF [5]) that can be used to verify AS_PATHs. To obviate the need to trust BGP speakers regarding NLRI information not specific to their own AS, [3] suggests adding the following information to the UPDATE message in new path attributes: - a sequence number for the UPDATE - the AS originating the information (either the aggregator or the originator of a direct route) and - the "predecessor" of the originating AS (i.e., the neighbor to which the NLRI is first advertised). This information is digitally signed by the BGP originator along with the NLRI, the ATOMIC_AGGREGATE, the ORIGIN, and the AGGREGATOR fields of the UPDATE message. The signature and the predecessor information must be included as the route in the UPDATE message propagates across the network, i.e., it is transitive. This information distributes a bit of link state topology information, concerning just the last hop before the destination network's AS, into the usual BGP distance vector (some say "path vector") protocol. Each BGP speaker will propagate this "predecessor" information. Any BGP speaker could use the signed predecessor information received to verify that each of the adjacencies represented in an AS_PATH is legitimate. That is, when a segment of an AS_PATH is a sequence, each adjacent pair in the sequence could be verified to correspond to a received signed predecessor tuple. The protection provided by the signed predecessor information becomes more difficult to use past an aggregation point where a BGP speaker advertises a less specific route which includes the originated NLRI. In Murphy Expires: August 2002 [Page 7] INTERNET DRAFT BGP Security Protections November 2001 particular, the rules for verifying an AS_PATH containing a segment that is a set would be either very lenient or very complex. While this predecessor information assures that each adjacency in a sequence of an AS_PATH is valid, it does not ensure that the AS_PATH as a whole is valid. Each AS's decision regarding routes it will advertise and traffic it will transit is individual and totally unconstrained. The fact that a valid path of ASs exists to a destination does not ensure that the corresponding AS_PATH is valid. This mechanism also does not assure that any information which comes from one router alone (LOCAL_PREF, NEXT_HOP, AGGREGATOR, etc.) is accurate. A router, then, can still falsely announce that its neighbor should be forwarded the traffic for an NLRI. 2.5. Origination and Route Protection A protection against possibly faulty BGP speakers that does provide some assurance that the AS_PATH is valid is described in [9]. The protection requires digital signatures of nested prefixes of the AS_PATH, carried in a transitive path attribute. Each BGP speaker would receive signed route information (including the AS_PATH, the ATOMIC_AGGREGATE attribute and NLRI) from its peer. The signature represents permission from the peer for the speaker to advertise the route. After making its routing decision, the BGP speaker would augment the chosen AS_PATH with its own AS and sign the resulting route (NLRI + AS_PATH) and ATOMIC_AGGREGATE. The BGP speaker would pass to its peers the augmented AS_PATH, its signature, and the signature it received from its peer which covers the received AS_PATH. The neighbor receiving this information can verify that the received AS_PATH was indeed constructed from an authorized path, by verifying the signature of the BGP speaker's peer over the tail of the received AS_PATH. The BGP speaker's signature will be passed on by the neighbor to provide similar assurance that it constructed its advertised AS_PATH legitimately. A BGP speaker could snip out a suffix of the data it received as well as the associated signatures and pass those on as the proof that its AS_PATH was based on reality. To prevent this, the signatures generated must cover not only the route information but the intended receiver as well. This procedure as described protects against one consecutive faulty router in the path. If it is desired to protect against more than one possibly faulty routers in the path, then the procedure can be nested Murphy Expires: August 2002 [Page 8] INTERNET DRAFT BGP Security Protections November 2001 arbitrarily. To protect against K consecutive faulty routers, each router would receive signed AS_PATH information from its neighbor along with K signatures of the preceding K BGP speakers in the path, each successive signature covering a shorter suffix of the AS_PATH. It would pass on a newly constructed AS_PATH along with its own signature, its neighbor's signature and K-1 of the included nested signatures. For example, consider a case where it was decided to protect against two faulty BGP speakers. Suppose AS1 receives an AS_PATH from AS2 of 'AS2 AS3 AS4 ... ASk'. (In this discussion as well as the next, ATOMIC_AGGREGATE would be included in the signature, but is omitted for brevity.) Then AS1 should also receive AS2's signature of "AS1, 'AS2 AS3 ... ASk', NLRI" as well as AS3's signature of "AS2, 'AS3 ... ASk', NLRI" and AS4's signature of "AS3, 'AS4 ... ASk', NLRI". AS1 would verify the authenticity of AS2's route by verifying the authorizing signatures from AS3 and AS4. AS1 uses AS2's signature in authorizing its own announcements. AS1 would compute a path as 'AS1 AS2 AS3 ... ASk', and pass to its neighbor AS0 this path along with its signature of "AS0, 'AS1 AS2 AS3 ... ASk', NLRI" and the authorizing signatures of AS2 and AS3. Because the intended recipient is included in the signature, each BGP speaker with N peers generates N signatures for each route announced, one for each peer. This discussion is predicated on the use of asymmetric cryptography. Each autonomous system would be required to possess an asymmetric key pair. The public key would have to be accessible to all recipients of the digital signature. The private key would have to be available to all BGP speakers in the autonomous system, but protected from exposure. 2.5.1. Remaining Issues This scheme becomes more complicated when one of the BGP speakers performs aggregation of a set of routes. To assure recipients of the validity of the aggregated route, it would be necessary to pass on the text and signatures of each of the aggregated component routes. This means an enormous increase in transmission bandwidth at each aggregation point and a similar increase in verification time at each verification point's peers. This cost would not have to be passed on to further neighbors further than K (the nesting level of signatures) hops away, but it does violate the spirit of aggregation. Alternatively, an aggregation point could be treated as another type of origination point, and signatures and verification would stop at that point. Murphy Expires: August 2002 [Page 9] INTERNET DRAFT BGP Security Protections November 2001 Unfortunately, that provides a mechanism for malicious BGP peers to announce bogus routes, simply by claiming to have aggregated the information. Aggregation also prevents identification of the specific culprit should it be discovered that a network is being originated in error. Neither this scheme nor the Origination and Adjacency Protection assures that the received route is the best route the peer could have computed. In particular, it does not guard against a peer that does not announce the best result of its decision process - for example, a peer that replays previous updates instead of forwarding a withdrawal, or does not change its announcements when it receives withdrawn routes, or replays withdrawal information after a route is reestablished, or replays an update after having forwarded a withdrawal. These are a matter for the internal correct operation of the router and cannot be precluded by authentication or authorization protection. This mechanism also does not assure that any information which comes from one router alone (LOCAL_PREF, NEXT_HOP, AGGREGATOR, etc.) is accurate. With these fields, a router can still falsely announce that its neighbor should be forwarded the traffic for an NLRI. The verification process chooses the key to use based on the AS's mentioned in the AS_PATH. If implementations do not verify that the peer BGP speaker prepended its own AS to the AS_PATH, i.e. if a BGP speaker might pass on an AS_PATH in which it's own AS is not the first in the PATH, then the AS's mentioned in the AS_PATH are not necessarily the AS's that produced the signature. In that case, this verification process could be using the wrong key. This signature scheme would have to be complicated by requiring either - that the sender's AS be included in the UPDATE message and the signature (so that the verification process could find the appropriate key for the signature) - or that each sender know the private key of the first AS in the AS_PATH (so that the signature and verification processes would be using the same key). Sharing keys between AS's makes those AS's indistinguishable to the cryptography; the second alternative design should only be chosen with that caution clearly understood. Murphy Expires: August 2002 [Page 10] INTERNET DRAFT BGP Security Protections November 2001 2.6. Filtering The Internet registries can provide data that will help to assure that AS_PATHS and NLRI origination data are authorized. If the data registered in the Internet registries is available, then an NLRI origination can be verified against the registry. Also, peering information in the registry can be used to verify that the AS_PATH as a whole was valid. The assurance provided by this protection would rely on the registry data being: complete: AS's that do not register their peering relationships or assigned networks would hamper the ability to protect the BGP data. accurate: AS's must register peering relationships that exactly match their policies. If the peering relationships are described too broadly, bogus routes will pass the filter. If the peering relationships are described too narrowly, legitimate routes will fail. timely: Additions and changes to the registry data must be communicated to the AS's in a timely manner. secure: The registries must be known to ensure the authenticity, integrity and authorization of provided information while in storage and in transmission to an AS. The assurance provided by this protection relies on the openness of the data recorded in the registries. To be truly useful, each autonomous system's policy would have to be recorded in the registry, in order that the AS_PATH as a whole can be verified to be valid. Information about policy, however, can be sensitive to an autonomous system and not openly available to every other autonomous system. Any restrictions on the availability of information stored in the registry will restrict its applicability as a protection mechanism. Filtering based on the registries can also not ensure the authenticity of the received routes. The registries currently contain permitted routes, not necessarily the current forwarding routes. If, for example, an AS will accept the same network from multiple peer, with one route to serve as a backup, filtering based on the registry would not be able to distinguish which is the route currently in use. Murphy Expires: August 2002 [Page 11] INTERNET DRAFT BGP Security Protections November 2001 3. Security Costs Choosing the protection to apply in any situation depends on the perception of the risk of attack, of the damage that can result, of the benefits derived from providing the protection, and of the cost of providing the protection. This section discusses the cost of each of the protection options mentioned above. 3.1. Protecting the Peer-Peer Link The cost of this protection is the processing required for the cryptography and the need to establish and manage the cryptographic keys. The cryptography need not be computationally expensive; HMAC or similar algorithms can be used. Shared secret keys are adequate for this protection, as the protection applies only to the communication between peers, so the key management cost is low. A separate key must be used for each BGP peering. Using one key for multiple peerings even at a peering point reduces the level of protection that is provided. This level of protection is low cost and protects against the vast number of outsiders who pose a threat. 3.2. Origination Protection The cost of signing the originating AS of each route is the cost of the processing required for the cryptography -- generating and verifying digital signatures -- as well as the need to establish and manage the cryptographic keys. For digital signatures, establishing and managing the cryptographic keys means providing a public key infrastructure to generate an asymmetric key pair for each autonomous system and to distribute and maintain certifications of the public keys associated with each autonomous system. While the key distribution and signature generation and verification provides for authentication and integrity of the messages, there is also a need to ensure the authorization of the origination. This requires another infrastructure that would provide certifications of the authority of an AS to originate a route to a network. The infrastructures required for authentication of AS messages and for authorization of origination information might be colocated. The establishment and secure operation (e.g., [6]) of the security infrastructure as well as the cost of secure communication with the infrastructure are additional costs of this technique. Murphy Expires: August 2002 [Page 12] INTERNET DRAFT BGP Security Protections November 2001 3.3. Origination and Adjacency Protection This scheme requires the same public key infrastructure and origination infrastructure as is needed for Origination Protection. It also requires that each adjacency for a BGP speaker be signed (the "predecessor" information) and transmitted along with an AS_PATH. Essentially, each BGP speaker must announce its peers, something that does not currently occur in the BGP protocol. Each BGP speaker must compute one signature for each NLRI in each UPDATE message transmitted and must verify one signature for each NLRI in each UPDATE message received. Each UPDATE message must be separately signed because the mechanism described in [3] includes a sequence number, the Withdrawn Routes and the Unfeasible Route Length fields, so the information to be signed changes with each message. (These fields are protected from outsiders by the peer-peer communication protection and so do not need to be digitally signed. If only the NLRI, ATOMIC_AGGREGATE and predecessor information were signed each time, then the signature might not have to be computed with each new UPDATE message, i.e., AS_PATH changes would not induce new signature computations.) The signed predecessor information in each route must be stored by the recipient indefinitely. Each route received must be verified by comparison to the store of predecessor information previously received in UPDATE messages from all AS sources. 3.4. Origination and Route Protection The operational cost of this scheme is described in detail in [10]. This scheme requires the same public key infrastructure and origination infrastructure as is needed for Origination Protection. For each UPDATE message received, K signatures (where K is the level of protection desired from consecutive faulty routers) must be verified. For each UPDATE message transmitted, one signature must be computed for each NLRI per recipient. As discussed before, prevention of cut and paste attacks requires that the signature include the recipient, so computing one signature per AS_PATH and NLRI announced is insufficient. The signatures contained in an UPDATE must be retained for all received routes in case the route is ever chosen and announced to the peers. This increases the size of the routing tables. Murphy Expires: August 2002 [Page 13] INTERNET DRAFT BGP Security Protections November 2001 For efficiency in situations where route flapping is occuring, withdrawn AS_PATHs and their signatures could be retained. This would mean that new announcements of flapped routes still retained would not require new signature verifications. 3.5. Filtering The cost of relying on registries would vary considerably depending on the protection provided to the information in storage and in transit. Any latency, above that caused by the use of cryptography, would depend on the mechanism used to transmit the registry information (e.g., anything from frequent complete download to real-time query and response). 4. Security Considerations This entire memo is about security, describing the possible security solutions to protect vulnerabilities in BGP. The vulnerabilities are described in a companion work, [11]. 5. References [1] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC1771, March 1995. [2] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)", work in progress, November 2001. available as <> at Internet-Draft shadow sites. [3] B. Smith and J.J. Garcia-Luna-Aceves, "Securing the Border Gateway Routing Protocol", Proc. Global Internet'96, London, UK, 20-21 November 1996. [4] Bruce Schneier. Applied Cryptography Protocols, Algorithms, and Source Code in C, John Wiley & Sons, Inc 1994. [5] John Moy, "OSPF Version 2", RFC 1583, March 1994. [6] C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy and C. Orange, "Routing Policy System Security", RFC 2725, December, 1999. [7] S. Kent and R.Atkinson, "Security Architecture for the Internet Protocol", RFC2401, November 1998. Murphy Expires: August 2002 [Page 14] INTERNET DRAFT BGP Security Protections November 2001 [8] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC2385, August 1998. [9] S.Kent, C.Lynn, and K. Seo, "Secure Border Gateway Protocol (Secure-BGP)", IEEE Journal on Selected Areas in Communications, Vol. 18, No. 4, April 2000, pp. 582-592. [10] S. Kent, C. Lynn, J. Mikkelson, and K. Seo, "Secure Border Gateway Protocol (S-BGP) -- Real World Performance and Deployment Issues", Proceedings of the IEEE Network and Distributed System Security Symposium (NDSS 2000), February 2000. [11] S. Murphy, "BGP Security Vulnerabilities Analysis", work in progress, February 2002. available as <> at Internet-Draft shadow sites. 6. Author's Address Sandra Murphy Network Associates, Inc. NAI Labs 3060 Washington Road Glenwood, MD 21738 EMail: Sandy@tislabs.com Murphy Expires: August 2002 [Page 15] Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA08606 for ; Fri, 22 Feb 2002 16:24:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E9B3C91233; Fri, 22 Feb 2002 16:24:06 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB8F99125A; Fri, 22 Feb 2002 16:24:06 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BE33F91233 for ; Fri, 22 Feb 2002 16:24:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9824A5DE1A; Fri, 22 Feb 2002 16:24:04 -0500 (EST) Delivered-To: idr@merit.edu Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 283465DE15 for ; Fri, 22 Feb 2002 16:24:04 -0500 (EST) Received: by sentry.gw.tislabs.com; id QAA05641; Fri, 22 Feb 2002 16:29:33 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma005632; Fri, 22 Feb 02 16:28:51 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g1MLNLL26672; Fri, 22 Feb 2002 16:23:21 -0500 (EST) Date: Fri, 22 Feb 2002 16:23:21 -0500 (EST) Message-Id: <200202222123.g1MLNLL26672@raven.gw.tislabs.com> From: sandy@tislabs.com To: idr@merit.edu Subject: new draft: draft-murphy-bgp-vuln-00.txt Cc: sandy@tislabs.com Sender: owner-idr@merit.edu Precedence: bulk Network Working Group Sandra Murphy INTERNET DRAFT NAI Labs draft-murphy-bgp-vuln-00.txt February 2002 BGP Security Vulnerabilities Analysis Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract BGP, along with a host of other infrastructure protocols designed before the Internet environment became perilous, is designed with little consideration for protection of the information it carries. There are no mechanisms in BGP to protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior. This internet draft discusses some of the security issues with BGP routing data dissemination. A companion work, [5], discusses possible security solutions and the costs of those solutions. This internet draft does not discuss security issues with forwarding of packets. Murphy Expires: August 2002 [Page 1] INTERNET DRAFT BGP Security Vulnerabilities Analysis November 2001 Table of Contents Status of this Memo .............................................. 1 Abstract ......................................................... 1 1 Introduction .................................................... 3 2 Vulnerabilities and Risks ....................................... 5 2.1 OPEN .......................................................... 5 2.2 KEEPALIVE ..................................................... 6 2.3 NOTIFICATION .................................................. 6 2.4 UPDATE ........................................................ 6 2.4.1 Unfeasible Routes Length, Total Path Attribute Length ....... 6 2.4.2 Withdrawn Routes ............................................ 6 2.4.3 Path Attributes ............................................. 7 Attribute Flags, Attribute Type Codes, Attribute Length .......... 7 ORIGIN ........................................................... 7 AS_PATH .......................................................... 7 Originating Routes ............................................... 8 NEXT_HOP ......................................................... 9 MULTI_EXIT_DISC .................................................. 9 LOCAL_PREF ....................................................... 9 ATOMIC_AGGREGATE ................................................. 9 AGGREGATOR ....................................................... 10 2.4.4 NLRI ........................................................ 10 2.5 BGP Extensions ................................................ 10 2.5.1 Communities ................................................. 10 2.5.2 Confederations .............................................. 11 3 Security Considerations ......................................... 11 4 References ...................................................... 11 5 Author's Address ................................................ 12 Murphy Expires: August 2002 [Page 2] INTERNET DRAFT BGP Security Vulnerabilities Analysis November 2001 1. Introduction The inter-domain routing protocol BGP was created when the Internet environment had not yet reached the present contentious state. Consequently, the BGP protocol was not designed with protection against deliberate or accidental errors causing disruptions of routing behavior. We here discuss the vulnerabilities of BGP, based on the BGP RFC [1] and on [2]. Readers are expected to be familiar with the BGP RFC and the behavior of BGP. A companion work, [5], proposes several different security solutions to protect these vulnerabilities and discuss the benefits derived from each solution and its cost. It is clear that the Internet is vulnerable to attack through its routing protocols and BGP is no exception. Faulty, misconfigured or deliberately malicious sources can disrupt overall Internet behavior by injecting bogus routing information into the BGP distributed routing database (by modifying, forging, or replaying BGP packets). The same methods can also be used to disrupt local and overall network behavior by breaking the distributed communication of information between BGP peers. The sources of bogus information can be either outsiders or true BGP peers. Under the present BGP design, cryptographic authentication of the peer- peer communication is not mandated. As a TCP/IP protocol, BGP is subject to all the TCP/IP attacks, like IP spoofing, session stealing, etc. Any outsider can inject believable BGP messages into the communication between BGP peers and thereby inject bogus routing information or break the peer to peer connection. Any break in the peer to peer communication has a ripple effect on routing that can be wide spread. Furthermore, outsider sources can also disrupt communications between BGP peers by breaking their TCP connection with spoofed RST packets. Outsider sources of bogus BGP information can reside anywhere in the world. BGP speakers themselves can inject bogus routing information, either by masquerading as information from any other legitimate BGP speaker, or by distributing unauthentic routing information as themselves. Historically, misconfigured and faulty routers have been responsible for widespread disruptions in the Internet. Bogus routing information can have many different effects on routing behavior. If the bogus information removes routing information for a particular network, that network can become unreachable for the portion of the Internet that accepts the bogus information. If the bogus Murphy Expires: August 2002 [Page 3] INTERNET DRAFT BGP Security Vulnerabilities Analysis November 2001 information changes the route to a network, then packets destined for that network may be forwarded by a sub-optimal path, or a path that does not follow the expected policy, or a path that will not forward the traffic. As a consequence, traffic to that network could be delayed by a longer than necessary path. The network could become unreachable from areas where the bogus information is accepted. Traffic might also be forwarded along a path that permits some adversary a view of the data. If the bogus information makes it appear that an autonomous system originates a network when it does not, then packets for that network may not be deliverable for the portion of the Internet that accepts the bogus information. A false announcement that an autonomous systems originates a network may also fragment aggregated address blocks in other parts of the Internet and cause routing problems for other networks. The damage that might result from these attacks are: starvation: data traffic destined for a node is forwarded to a part of the network that cannot deliver it, network congestion: more data traffic is forwarded through some portion of the network than would otherwise need to carry the traffic, blackhole: large amounts of traffic are directed to be forwarded through one router that cannot handle the increased level of traffic and drops many/most/all packets, delay: data traffic destined for a node is forwarded along a path that is in some way inferior to the path it would otherwise take, looping: data traffic is forwarded along a path that loops, so that the data is never delivered, eavesdrop: data traffic is forwarded through some router or network that would otherwise not see the traffic, affording an opportunity to see the data, partition: some portion of the network believes that it is partitioned from the rest of the network when it is not, cut: some portion of the network believes that it has no route to some network that is in fact connected, Murphy Expires: August 2002 [Page 4] INTERNET DRAFT BGP Security Vulnerabilities Analysis November 2001 churn: the forwarding in the network changes at a rapid pace, resulting in large variations in the data delivery patterns (and adversely affecting congestion control techniques), instability: BGP become unstable so that convergence on a global forwarding state is not achieved, and overload: the BGP messages themselves become a significant portion of the traffic the network carries. 2. Vulnerabilities and Risks The risks in BGP arise from three fundamental vulnerabilities: no mechanism has been mandated that provides strong protection of the integrity, freshness and source authenticity of the messages in peer-peer BGP communications. no mechanism has been specified to validate the authority of an AS to announce NLRI information. no mechanism has been specified to ensure the authenticity of the AS_PATH announced by an AS. There are four different BGP message types - OPEN, KEEPALIVE, NOTIFICATION, and UPDATE. This section contains a discussion of the vulnerabilities arising from each message and the ability of outsiders or BGP peers to exploit the vulnerabilities. To summarize, outsiders can use bogus OPEN, KEEPALIVE, or NOTIFICATION messages to disrupt the BGP peer-peer connections and can use bogus UPDATE messages to disrupt routing. Outsiders can also disrupt BGP peer-peer connections by inserting bogus TCP RST packets. BGP peers themselves are permitted to break peer-peer connections at any time, and so they cannot be said to be issuing "bogus" OPEN, KEEPALIVE or NOTIFICATION messages. However, BGP peers can disrupt routing by issuing bogus UPDATE messages. In particular, bogus ATOMIC_AGGREGATE and AS_PATH attributes and bogus NLRI in UPDATE messages can disrupt routing. Each message introduces certain different vulnerabilities and risks. 2.1. OPEN Because receipt of a new OPEN message in the Established state will cause the close of the BGP peering session and thereby induce the release of all resources and deletion of all associated routes, the Murphy Expires: August 2002 [Page 5] INTERNET DRAFT BGP Security Vulnerabilities Analysis November 2001 ability to spoof this message can lead to a severe disruption of routing. 2.2. KEEPALIVE Receipt of a KEEPALIVE message when the peering connection is in the OpenSent state can lead to a failure to establish a connection. The ability to spoof this message is a vulnerability. To exploit this vulnerability deliberately, the KEEPALIVE must be carefully timed in the sequence of messages exchanged between the peers; otherwise, it causes no damage. 2.3. NOTIFICATION Receipt of a NOTIFICATION message will cause the close of the BGP peering session and thereby induce the release of all resources and deletion of all associated routes. Therefore, the ability to spoof this message can lead to a severe disruption of routing. 2.4. UPDATE The Update message carries the routing information. The ability to spoof any part of this message can lead to a disruption of routing. 2.4.1. Unfeasible Routes Length, Total Path Attribute Length There is a vulnerability arising from the ability to modify these fields. If a length is modified, the message is not likely to parse properly, resulting in an error, the transmission of a NOTIFICATION message and the close of the connection. As a true BGP speaker is always able to close a connection at any time, this vulnerability represents an additional risk only when the source is a non-BGP speaker, i.e., it presents no additional risk from BGP sources. 2.4.2. Withdrawn Routes An outsider could cause the elimination of existing legitimate routes by forging or modifying this field. An outsider could also cause the elimination of reestablished routes by replaying this withdrawal information from earlier packets. A BGP speaker could "falsely" withdraw feasible routes using this field. However, as the BGP speaker is authoritative for the routes it will announce, it is allowed to withdraw any previously announced routes that it wants. As the receiving BGP speaker will only withdraw routes Murphy Expires: August 2002 [Page 6] INTERNET DRAFT BGP Security Vulnerabilities Analysis November 2001 associated with the sending BGP speaker, there is no opportunity for a BGP speaker to withdraw another BGP speaker's routes. Therefore, there is no additional risk from BGP peers via this field. 2.4.3. Path Attributes The path attributes present many different vulnerabilities and risks. Attribute Flags, Attribute Type Codes, Attribute Length A BGP peer or an outsider could modify the attribute length or attribute type (flags and type codes) so they did not reflect the attribute values that followed. If the flags were modified, the flags and type code could become incompatible (i.e., a mandatory attribute marked as partial), or a optional attribute could be interpreted as a mandatory attribute or vice versa. If the type code were modified, the attribute value could be interpreted as if it were the data type and value of a different attribute. The most likely result from modifying the attribute length, flags, or type code would be a parse error of the UPDATE message. A parse error would cause the transmission of a NOTIFICATION message and the close of the connection. As a true BGP speaker is always able to close a connection at any time, this vulnerability represents an additional risk only when the source is an outsider, i.e., it presents no additional risk from a BGP peer. ORIGIN This field indicates whether the information was learned from IGP or EGP information. If the route is used in inter-AS multicast routing, a value of INCOMPLETE may be used. This field is not used in making routing decisions, so there are no vulnerabilities arising from this field, either from BGP peers or outsiders. AS_PATH A BGP peer or outsider could announce an AS_PATH that was not accurate for the associated NLRI. Forwarding for the NLRI associated with the AS_PATH could potentially be induced to follow a sub-optimal path, a path that did not follow some intended policy, or even a path that would not forward the traffic. If the path would not forward the traffic, the NLRI would become unreachable for that portion of the Internet that accepted the false path. If much traffic is mis-directed, some routers and transit networks along the announced route could become flooded with Murphy Expires: August 2002 [Page 7] INTERNET DRAFT BGP Security Vulnerabilities Analysis November 2001 the mis-directed traffic. It is not clear how far an inaccurate AS_PATH could deviate from the true AS_PATH. It may be that the first AS in the AS_PATH, at least, must be a legal hop. The RFC states that a BGP speaker prepends its own AS to an AS_PATH before announcing it to a neighbor. If the BGP speaker must prepend its own AS, then a BGP speaker that produced a bogus AS_PATH could end up receiving the traffic for the associated NLRI. This could be desirable if the error was deliberate and the intent was to receive traffic that would not otherwise be received. Receiving the mis-routed traffic could be undesirable for the faulty BGP speaker if it were not prepared to handle the extra (mis-routed) traffic. So, requiring a BGP peer to prepend its own AS to the AS_PATH, might encourage or discourage it from inventing an arbitrary AS_PATH, depending on its resources and intent. If BGP peers need not prepend its own AS (or implementations do not ensure that this is done), then a malicious BGP peer could announce a path that begins with the AS of any BGP speaker with little impact on itself. Whether such an arbitrary AS_PATH is a vulnerability would depend on whether BGP implementations check the AS_PATH (to see if the first AS is the neighbor) and would catch the error. If there are legitimate situations in which a BGP speaker could pass an AS_PATH to a neighbor without putting its own AS at the head of the AS_PATH, then there is no way for implementations to detect totally bogus AS_PATHs. Originating Routes A special case of announcing a false AS_PATH occurs when the AS_PATH advertises a direct connection to a specific network address. An BGP peer or outsider could disrupt routing to the network(s) listed in the NLRI field by falsely advertising a direct connection to the network. The NLRI would become unreachable to the portion of the network that accepted this false route, unless the ultimate AS on the AS_PATH undertook to tunnel the packets it was forwarded for this NLRI on toward their true destination AS by a valid path. But even when the packets are tunneled to the correct destination AS, the route followed may not be optimal or may not follow the intended policy. Additionally, routing for other networks in the Internet could be affected if the false advertisement fragmented an aggregated address block, forcing the routers to handle (issue UPDATES, store, manage) the multiple fragments rather than the single aggregate. False originations for multiple addresses can result in routers and transit networks along the announced Murphy Expires: August 2002 [Page 8] INTERNET DRAFT BGP Security Vulnerabilities Analysis November 2001 route to become flooded with mis-directed traffic. NEXT_HOP The NEXT_HOP attribute defines the IP address of the border router that should be used as the next hop when forwarding the NLRI listed in the UPDATE message. If the recipient is an external peer, then the recipient and the NEXT_HOP address must share a subnet. It is clear that an outsider modifying this field could disrupt the forwarding of traffic between the two AS's. In the case that the recipient of the message is an external peer of an AS and the route was learned from another peer AS (this is one of two forms of "third party" NEXT_HOP), then the BGP speaker advertising the route has the opportunity to direct the recipient to forward traffic to a BGP speaker at the NEXT_HOP address. This affords the opportunity to direct traffic at a router that may not be able to continue forwarding the traffic. It is unclear whether this would also require the advertising BGP speaker to construct an AS_PATH mentioning the NEXT_HOP external peer's AS. MULTI_EXIT_DISC The MULTI_EXIT_DISC attribute is used in UPDATE messages transmitted between inter-AS BGP peers. While the MULTI_EXIT_DISC received from an inter-AS peer may be propagated within an AS, it may not be propagated to other AS's. Consequently, this field is only used in making routing decisions internal to one AS. Modifying this field, whether by an outsider or an BGP peer, could influence routing within an AS to be sub- optimal, but the effect should be limited in scope. LOCAL_PREF The LOCAL_PREF attribute must be included in all messages with internal peers and excluded from messages with external peers. Consequently, modification of the LOCAL_PREF could effect the routing process within the AS only. Note that there is no requirement in the BGP RFC that the LOCAL_PREF be consistent among the internal BGP speakers of an AS. As BGP peers are free to choose the LOCAL_PREF as they wish, modification of this field is a vulnerability with respect to outsiders only. ATOMIC_AGGREGATE The ATOMIC_AGGREGATE field indicates that an AS somewhere along the way has received a more specific and a less specific route to the NLRI and Murphy Expires: August 2002 [Page 9] INTERNET DRAFT BGP Security Vulnerabilities Analysis November 2001 installed the aggregated route. This route cannot be de-aggregated because it is not certain that the route to more specific prefixes will follow the listed AS_PATH. Consequently, BGP speakers receiving a route with ATOMIC_AGGREGATE are restricted from making the NLRI any more specific. Removing the ATOMIC_AGGREGATE attribute would remove the restriction, possibly causing traffic intended for the more specific NLRI to be routed incorrectly. Adding the ATOMIC_AGGREGATE attribute when no aggregation was done would have little effect, beyond restricting the un-aggregated NLRI from being made more specific. This vulnerability exists whether the source is a BGP peer or an outsider. AGGREGATOR This field may be included by a BGP speaker who has computed the routes represented in the UPDATE message from aggregation of other routes. The field contains the AS number and IP address of the last aggregator of the route. It is not used in making any routing decisions, so it does not represent a vulnerability. 2.4.4. NLRI By modifying or forging this field, either an outsider or BGP peer source could cause disruption of routing to the announced network, overwhelm a router along the announced route, cause data loss when the announced route will not forward traffic to the announced network, route traffic by a sub-optimal route, etc. 2.5. BGP Extensions Several standards track extensions have been defined for BGP, e.g., [3], [4]. Some have present additional vulnerabilities. 2.5.1. Communities An optional transitive path attribute called COMMUNITIES, [3], provides for more flexible and scalable configuration of routing policies and for control of configuration by the service provider customer. Routing UPDATEs may now include a communities attribute that is used by the receiver in deciding to accept, prefer, or distribute the UPDATE route. An outsider could forge values in this field to affect the routing behavior of the receiver. In particular, the defined values for this attribute of NO_EXPORT, NO_ADVERTISE, and NO_EXPORT_SUBCONFED offer the opportunity to affect the distribution of those routes. Murphy Expires: August 2002 [Page 10] INTERNET DRAFT BGP Security Vulnerabilities Analysis November 2001 Depending on the use the receiver makes of the communities attribute, a BGP peer who had knowledge of the routing decision process of the receiver could misuse communities to which it was not authorized to its own benefit or to the harm of others. 2.5.2. Confederations New types for AS_PATH segments called AS_CONFED_SEQUENCE and AS_CONFED_SET, [4], offer an alternative to ful mesh IBGP sessions. A confederation is a collection of autonomous systems advertised to BGP speaker outside the confederation as a single AS but within the confederation as if they were distinct AS's. An outsider who was able to forge this segment type could affect routing within the confederation and consequently routing with peers as well. The specification [4] makes no distinction between the values for Member-AS numbers used within a confederation and AS numbers used outside a confederation. The possibility exists for a BGP speaker to include a segment type of AS_CONFED_SEQUENCE or AS_CONFED_SET and use the same Member-AS value as used in its peer's own confederation. This presents an opportunity to considerably affect routing between the two confederations and inside the peer's confederation. 3. Security Considerations This entire memo is about security, describing an analysis of the vulnerabilities that exist in the BGP protocol. A companion work, [5], describes possible security solutions and their costs. 4. References [1] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC1771, March 1995. [2] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)", work in progress, November 2001. available as <> at Internet-Draft shadow sites. [3] R. Chandra, P. Traina, and T. Li, "BGP Communities Attribute", RFC1997, August 1996. [4] P. Traina, D. McPherson, and J. Scudder, "Autonomous System Confederations for BGP", RFC3065, February 2001. Murphy Expires: August 2002 [Page 11] INTERNET DRAFT BGP Security Vulnerabilities Analysis November 2001 [5] S. Murphy, "BGP Security Protections", work in progress, February, 2002. available as <> at Internet-Draft shadow sites. 5. Author's Address Sandra Murphy Network Associates, Inc. NAI Labs 3060 Washington Road Glenwood, MD 21738 EMail: Sandy@tislabs.com Murphy Expires: August 2002 [Page 12] Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA08582 for ; Fri, 22 Feb 2002 16:23:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8E2C791203; Fri, 22 Feb 2002 16:23:14 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E43991233; Fri, 22 Feb 2002 16:23:14 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4DBA391203 for ; Fri, 22 Feb 2002 16:23:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2FA265DE17; Fri, 22 Feb 2002 16:23:13 -0500 (EST) Delivered-To: idr@merit.edu Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id B98CE5DE15 for ; Fri, 22 Feb 2002 16:23:12 -0500 (EST) Received: by sentry.gw.tislabs.com; id QAA05625; Fri, 22 Feb 2002 16:28:32 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma005617; Fri, 22 Feb 02 16:28:16 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g1MLMjp26651; Fri, 22 Feb 2002 16:22:45 -0500 (EST) Date: Fri, 22 Feb 2002 16:22:45 -0500 (EST) Message-Id: <200202222122.g1MLMjp26651@raven.gw.tislabs.com> From: sandy@tislabs.com To: idr@merit.edu Subject: two new BGP security drafts Cc: sandy@tislabs.com Sender: owner-idr@merit.edu Precedence: bulk At the last IETF meeting, the idr working group requested that I split the BGP security draft into two: one covering vulnerabilities and the other covering possible solutions. I just sent the two draft to internet-drafts as: draft-murphy-bgp-vuln-00.txt draft-murphy-bgp-protect-00.txt There's very little new in these two drafts. The vulnerabilities draft does talk some about confederations and communities and the vulnerabilities from those extensions to the base protocol. I'll send the two drafts to the mailing list in the next few minutes. --Sandy Murphy Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA01452 for ; Wed, 20 Feb 2002 15:48:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9203A912B0; Wed, 20 Feb 2002 15:47:51 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5FBA0912B1; Wed, 20 Feb 2002 15:47:51 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4860F912B0 for ; Wed, 20 Feb 2002 15:47:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1A6CC5DDB1; Wed, 20 Feb 2002 15:47:46 -0500 (EST) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (system134.nexsi.com [66.35.197.134]) by segue.merit.edu (Postfix) with ESMTP id B954A5DD9C for ; Wed, 20 Feb 2002 15:47:45 -0500 (EST) Received: from khonsu.sw.nexsi.com (khonsu.sw.nexsi.com [192.168.104.145] (may be forged)) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id MAA01695; Wed, 20 Feb 2002 12:45:58 -0800 Date: Wed, 20 Feb 2002 12:47:06 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <37176077676.20020220124706@nexsi.com> To: Jeffrey Haas Cc: Enke Chen , idr@merit.edu Subject: Re: processing order of reach/unreach in rfc2858bis In-Reply-To: <20020220152952.S22759@nexthop.com> References: <20020220200541.30BA415D3C1@popserv1.redback.com> <20020220152952.S22759@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Jeff, Enke To get a complete picture here, maybe it's a good idea to collect info on how people order the MP_* attributes when sending a message... However, I'm feeling that we might not be able to find a solution satisfying most deployed implementations and might finally have to go with Yakov's option 3... -- Alex Zinin Wednesday, February 20, 2002, 12:29:52 PM, Jeffrey Haas wrote: > On Wed, Feb 20, 2002 at 12:05:40PM -0800, Enke Chen wrote: >> > MP_REACH_NLRI is enumerated before MP_UNREACH_NLRI in the path attributes. >> >> It may not be the actual order in an update message. > Agreed. >> The deployed code >> processes the prefixes in the sequential order of their actual presence >> in an update message. -- Enke > Well, we don't, for example. But we're not the 800lb gorilla. > We also don't send updates that contain duplicate NLRI in multiple > inappropriate fields. But we want to deal sanely with those that do. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA01039 for ; Wed, 20 Feb 2002 15:31:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 73A51912AE; Wed, 20 Feb 2002 15:30:33 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 28DF1912B0; Wed, 20 Feb 2002 15:30:33 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F08AA912AE for ; Wed, 20 Feb 2002 15:30:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id D72E45DDAB; Wed, 20 Feb 2002 15:30:31 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id C654C5DD9C for ; Wed, 20 Feb 2002 15:30:26 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g1KKUN363953; Wed, 20 Feb 2002 15:30:23 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g1KKTqE23317; Wed, 20 Feb 2002 15:29:52 -0500 (EST) Date: Wed, 20 Feb 2002 15:29:52 -0500 From: Jeffrey Haas To: Enke Chen Cc: idr@merit.edu Subject: Re: processing order of reach/unreach in rfc2858bis Message-ID: <20020220152952.S22759@nexthop.com> References: <20020220200541.30BA415D3C1@popserv1.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020220200541.30BA415D3C1@popserv1.redback.com>; from enke@redback.com on Wed, Feb 20, 2002 at 12:05:40PM -0800 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Wed, Feb 20, 2002 at 12:05:40PM -0800, Enke Chen wrote: > > MP_REACH_NLRI is enumerated before MP_UNREACH_NLRI in the path attributes. > > It may not be the actual order in an update message. Agreed. > The deployed code > processes the prefixes in the sequential order of their actual presence > in an update message. -- Enke Well, we don't, for example. But we're not the 800lb gorilla. We also don't send updates that contain duplicate NLRI in multiple inappropriate fields. But we want to deal sanely with those that do. -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA00250 for ; Wed, 20 Feb 2002 15:06:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 270B2912AD; Wed, 20 Feb 2002 15:05:47 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ECDD6912AE; Wed, 20 Feb 2002 15:05:46 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ED05A912AD for ; Wed, 20 Feb 2002 15:05:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id C168C5DDAB; Wed, 20 Feb 2002 15:05:45 -0500 (EST) Delivered-To: idr@merit.edu Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 8CDFC5DD9C for ; Wed, 20 Feb 2002 15:05:45 -0500 (EST) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 11EB2262815; Wed, 20 Feb 2002 12:05:45 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id 30BA415D3C1; Wed, 20 Feb 2002 12:05:41 -0800 (PST) To: Jeffrey Haas Cc: idr@merit.edu, enke@redback.com Subject: Re: processing order of reach/unreach in rfc2858bis In-Reply-To: Message from Jeffrey Haas of "Wed, 20 Feb 2002 14:58:07 EST." <20020220145807.P22759@nexthop.com> Date: Wed, 20 Feb 2002 12:05:40 -0800 From: Enke Chen Message-Id: <20020220200541.30BA415D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk > Date: Wed, 20 Feb 2002 14:58:07 -0500 > From: Jeffrey Haas > To: Enke Chen > Cc: idr@merit.edu > Subject: Re: processing order of reach/unreach in rfc2858bis > Message-ID: <20020220145807.P22759@nexthop.com> > References: <20020220184159.DF41E979C1@popserv2.redback.com> > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > User-Agent: Mutt/1.2.5i > In-Reply-To: <20020220184159.DF41E979C1@popserv2.redback.com>; from enke@redback.com on Wed, Feb 20, 2002 at 10:41:58AM -0800 > X-NextHop-MailScanner: Found to be clean > > On Wed, Feb 20, 2002 at 10:41:58AM -0800, Enke Chen wrote: > > For folks who care about (or need to deal with) code deployment and > > compatibility, please note that the majority of the depoyed routers > > process the prefixes in the sequential order. To do it differently, > > we will need a strong reason why the sequential processing is not > > good enough, and be willing to deal with compatibility and transition > > issues. > > MP_REACH_NLRI is enumerated before MP_UNREACH_NLRI in the path attributes. It may not be the actual order in an update message. The deployed code processes the prefixes in the sequential order of their actual presence in an update message. -- Enke > This is the opposite for WD_NLRI and NLRI. > > > -- Enke > > -- > Jeff Haas > NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA29557 for ; Wed, 20 Feb 2002 14:59:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 25B92912AB; Wed, 20 Feb 2002 14:59:11 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3642912AD; Wed, 20 Feb 2002 14:59:10 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F3D9B912AB for ; Wed, 20 Feb 2002 14:59:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id DA50B5DDA3; Wed, 20 Feb 2002 14:59:09 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 926DC5DD9C for ; Wed, 20 Feb 2002 14:59:09 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g1KJwc362949; Wed, 20 Feb 2002 14:58:38 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g1KJw7Q23240; Wed, 20 Feb 2002 14:58:07 -0500 (EST) Date: Wed, 20 Feb 2002 14:58:07 -0500 From: Jeffrey Haas To: Enke Chen Cc: idr@merit.edu Subject: Re: processing order of reach/unreach in rfc2858bis Message-ID: <20020220145807.P22759@nexthop.com> References: <20020220184159.DF41E979C1@popserv2.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020220184159.DF41E979C1@popserv2.redback.com>; from enke@redback.com on Wed, Feb 20, 2002 at 10:41:58AM -0800 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Wed, Feb 20, 2002 at 10:41:58AM -0800, Enke Chen wrote: > For folks who care about (or need to deal with) code deployment and > compatibility, please note that the majority of the depoyed routers > process the prefixes in the sequential order. To do it differently, > we will need a strong reason why the sequential processing is not > good enough, and be willing to deal with compatibility and transition > issues. MP_REACH_NLRI is enumerated before MP_UNREACH_NLRI in the path attributes. This is the opposite for WD_NLRI and NLRI. > -- Enke -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA29237 for ; Wed, 20 Feb 2002 14:55:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5B557912AA; Wed, 20 Feb 2002 14:55:39 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F0C0912AB; Wed, 20 Feb 2002 14:55:39 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2B294912AA for ; Wed, 20 Feb 2002 14:55:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id F15EA5DDB1; Wed, 20 Feb 2002 14:55:37 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id AC6235DD9C for ; Wed, 20 Feb 2002 14:55:37 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g1KJtE362851; Wed, 20 Feb 2002 14:55:14 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g1KJshu23228; Wed, 20 Feb 2002 14:54:43 -0500 (EST) Date: Wed, 20 Feb 2002 14:54:43 -0500 From: Jeffrey Haas To: Alex Zinin Cc: Yakov Rekhter , idr@merit.edu Subject: Re: processing order of reach/unreach in rfc2858bis Message-ID: <20020220145443.O22759@nexthop.com> References: <200202201537.g1KFb2i50166@merlot.juniper.net> <56167300295.20020220102049@nexsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <56167300295.20020220102049@nexsi.com>; from azinin@nexsi.com on Wed, Feb 20, 2002 at 10:20:49AM -0800 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk This preserves the functionality that I wanted and I'd be cool with this. On Wed, Feb 20, 2002 at 10:20:49AM -0800, Alex Zinin wrote: > Then I'm thinking that Option 1 could be made better if > modified to say that the prefix should be processed as if > it only appeared in the highest priority field, where > the field priorities are defined as (highest left): > > NLRI, MP_REACH_NLRI, {MP_UNREACH_NLRI or WITHDRAWN} > > The difference is that we process a prefix as if it was > in one field only (perform only one operation) instead > of processing it in all fields (and potentially all > instances of the prefix) in a specific order, which is > more consistent with the base spec, where we instruct > to ignore the prefix instance in WITHDRAWN. > > -- > Alex Zinin -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA28577 for ; Wed, 20 Feb 2002 14:49:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BB43991222; Wed, 20 Feb 2002 14:49:26 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 851C7912AA; Wed, 20 Feb 2002 14:49:26 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8903E91222 for ; Wed, 20 Feb 2002 14:49:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6EA015DDA3; Wed, 20 Feb 2002 14:49:25 -0500 (EST) Delivered-To: idr@merit.edu Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 2EDD15DD9C for ; Wed, 20 Feb 2002 14:49:25 -0500 (EST) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 860E7F2C4B; Wed, 20 Feb 2002 11:49:24 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id 369C115D3C1; Wed, 20 Feb 2002 11:49:24 -0800 (PST) To: "Rijsman, Bruno" Cc: "'idr@merit.edu'" , enke@redback.com Subject: Re: Error handling for dynamic capabilities negotiation In-Reply-To: Message from "Rijsman, Bruno" of "Wed, 13 Feb 2002 09:42:03 EST." <49FF5C6DDBD8D311BBBD009027DE980C02E7E59F@uniwest1.it.west.unispherenetworks.com> Date: Wed, 20 Feb 2002 11:49:24 -0800 From: Enke Chen Message-Id: <20020220194924.369C115D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Bruno: > Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C02E7E59F@uniwest1.it.west.unispherenetworks.com> > From: "Rijsman, Bruno" > To: "'idr@merit.edu'" > Cc: 'Enke Chen' > Subject: Error handling for dynamic capabilities negotiation > Date: Wed, 13 Feb 2002 09:42:03 -0500 > > I noticed that the dynamic capabilities draft does not > specify what should be done when a malformed CAPABILITY > message is received. Here is some suggested text to > address this issue: > > > X. Error handling. > > A new NOTIFICATION error code is defined: > > 7 CAPABILITY Message Error > > which has the following error subcodes: > > 1 Invalid capability action > 2 Invalid capability length > 3 Invalid capability data > > If the action field of a capability tuple in a received > CAPABILITY message is not 0 or 1, then a NOTIFICATION > with error subcode "invalid capability action " MUST be > sent and the data field of the NOTIFICATION MUST contain > the offending capability tuple. > > If the length field of a capability tuple in a received > CAPABILITY message is illegal (e.g. it exceeds the total > length of the message), then a NOTIFICATION with error > subcode "invalid capability length" MUST be sent and > the data field of the NOTIFICATION MUST contain the > action and length fields of the offending capability > tuple. > > If the data field of a capability tuple in a received > CAPABILITY message is illegal (the definition of > illegal depends on the capability code), then a > NOTIFICATION with error subcode "invalid capability > data" MUST be sent and the data field of the NOTIFICATION > MUST contain the offending capability tuple. > As the is the same as defined in the "Capability Advertisement" [BGP-CAP] document, we probably should start with [BGP-CAP] if the error subcodes are desirable. -- Enke Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA23418 for ; Wed, 20 Feb 2002 13:42:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 011DD912A7; Wed, 20 Feb 2002 13:42:06 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8F03912A9; Wed, 20 Feb 2002 13:42:05 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EDAEF912A7 for ; Wed, 20 Feb 2002 13:42:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id CF9F45DDA1; Wed, 20 Feb 2002 13:42:04 -0500 (EST) Delivered-To: idr@merit.edu Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 96CFB5DD9C for ; Wed, 20 Feb 2002 13:42:04 -0500 (EST) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id C34C71531C8; Wed, 20 Feb 2002 10:42:01 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv2.redback.com (Postfix) with ESMTP id DF41E979C1; Wed, 20 Feb 2002 10:41:59 -0800 (PST) To: Alex Zinin Cc: Yakov Rekhter , idr@merit.edu, enke@redback.com Subject: Re: processing order of reach/unreach in rfc2858bis In-Reply-To: Message from Alex Zinin of "Wed, 20 Feb 2002 10:20:49 PST." <56167300295.20020220102049@nexsi.com> Date: Wed, 20 Feb 2002 10:41:58 -0800 From: Enke Chen Message-Id: <20020220184159.DF41E979C1@popserv2.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Alex, > Date: Wed, 20 Feb 2002 10:20:49 -0800 > From: Alex Zinin > Message-ID: <56167300295.20020220102049@nexsi.com> > To: Yakov Rekhter > Cc: idr@merit.edu > Subject: Re: processing order of reach/unreach in rfc2858bis > In-Reply-To: <200202201537.g1KFb2i50166@merlot.juniper.net> > References: <200202201537.g1KFb2i50166@merlot.juniper.net> > > Yakov, > > > no, it was an unintentional omission. > > Then I'm thinking that Option 1 could be made better if > modified to say that the prefix should be processed as if > it only appeared in the highest priority field, where > the field priorities are defined as (highest left): > > NLRI, MP_REACH_NLRI, {MP_UNREACH_NLRI or WITHDRAWN} > > The difference is that we process a prefix as if it was > in one field only (perform only one operation) instead > of processing it in all fields (and potentially all > instances of the prefix) in a specific order, For folks who care about (or need to deal with) code deployment and compatibility, please note that the majority of the depoyed routers process the prefixes in the sequential order. To do it differently, we will need a strong reason why the sequential processing is not good enough, and be willing to deal with compatibility and transition issues. > which is more consistent with the base spec, where we instruct > to ignore the prefix instance in WITHDRAWN. Please note the sequentail processing yields the same result as ignoring the WITHDRAW prefix. -- Enke Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA23098 for ; Wed, 20 Feb 2002 13:39:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8A48B912A6; Wed, 20 Feb 2002 13:38:31 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5DFF5912A7; Wed, 20 Feb 2002 13:38:31 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 68533912A6 for ; Wed, 20 Feb 2002 13:38:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 42A145DDA1; Wed, 20 Feb 2002 13:38:30 -0500 (EST) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (system134.nexsi.com [66.35.197.134]) by segue.merit.edu (Postfix) with ESMTP id A83395DD9C for ; Wed, 20 Feb 2002 13:38:29 -0500 (EST) Received: from khonsu.sw.nexsi.com ([192.168.103.207]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id KAA32744; Wed, 20 Feb 2002 10:36:44 -0800 Date: Wed, 20 Feb 2002 10:37:53 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <126168323846.20020220103753@nexsi.com> To: Jeffrey Haas Cc: idr@merit.edu Subject: Re: counting AS-path length In-Reply-To: <20020220122322.F22759@nexthop.com> References: <20020215152935.A4906@nexthop.com> <2394755781.20020219141143@nexsi.com> <20020220122322.F22759@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Jeff > Your first statement says we should ask implementations that don't do > this to change behavior. Hmmm... I was under impression that most widely deployed implementations do max pack TLVs, and since it is a natural thing to do, I think it makes sense to explicitly say so. Unless of course this message triggers an avalanche of replies saying "we don't do this and think it is better..." > Your second statements says the opposite. :-) > What I'd like to see: > Implementations should treat any adjacent AS_SETs as being part of > the same set for purposes of AS_PATH length computation. > Can we make this change to the specification? > I'd prefer to see us state what we'd like to have implementors do > and have implementors be non-compliant for a period of time and > eventually fix stuff to be deterministic rather than leave this vague. If I were to choose between two options: 1) state that TLVs should be max packed and do not require "merger" of adjacent sets for calculation, and 2) leave TLV packing loose, but say that computing router should count adjacent sets as one -- I would choose option 1, because: - it seems more likely that most implementations already max pack TLVs, and less likely that they do the counting trick, so it should be less of a "compliance" problem - option 2 may cause inconsistent route selection among routers that do the merger and those that don't, while in option 1 everyone treats the route equally and even if the aggregator did not max pack TLVs and suddenly starts doing so, we should not have problems. Alex. > For compliance purposes, this is doesn't seem to be a big deal. > I don't see a lot of aggregates floating around the Internet at the > moment. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA21392 for ; Wed, 20 Feb 2002 13:22:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7714991221; Wed, 20 Feb 2002 13:21:30 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B222912A6; Wed, 20 Feb 2002 13:21:30 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5D39191221 for ; Wed, 20 Feb 2002 13:21:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 431985DDC9; Wed, 20 Feb 2002 13:21:29 -0500 (EST) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (system134.nexsi.com [66.35.197.134]) by segue.merit.edu (Postfix) with ESMTP id B344E5DDA3 for ; Wed, 20 Feb 2002 13:21:28 -0500 (EST) Received: from khonsu.sw.nexsi.com ([192.168.103.207]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id KAA32568; Wed, 20 Feb 2002 10:19:40 -0800 Date: Wed, 20 Feb 2002 10:20:49 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <56167300295.20020220102049@nexsi.com> To: Yakov Rekhter Cc: idr@merit.edu Subject: Re: processing order of reach/unreach in rfc2858bis In-Reply-To: <200202201537.g1KFb2i50166@merlot.juniper.net> References: <200202201537.g1KFb2i50166@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Yakov, > no, it was an unintentional omission. Then I'm thinking that Option 1 could be made better if modified to say that the prefix should be processed as if it only appeared in the highest priority field, where the field priorities are defined as (highest left): NLRI, MP_REACH_NLRI, {MP_UNREACH_NLRI or WITHDRAWN} The difference is that we process a prefix as if it was in one field only (perform only one operation) instead of processing it in all fields (and potentially all instances of the prefix) in a specific order, which is more consistent with the base spec, where we instruct to ignore the prefix instance in WITHDRAWN. -- Alex Zinin Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA16481 for ; Wed, 20 Feb 2002 12:24:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 41C63912A1; Wed, 20 Feb 2002 12:24:11 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0F5DD912A4; Wed, 20 Feb 2002 12:24:10 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 09717912A1 for ; Wed, 20 Feb 2002 12:24:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id D6EE75DD9C; Wed, 20 Feb 2002 12:24:09 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id BAD465DD94 for ; Wed, 20 Feb 2002 12:24:09 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g1KHNr358242; Wed, 20 Feb 2002 12:23:53 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g1KHNMX22921; Wed, 20 Feb 2002 12:23:22 -0500 (EST) Date: Wed, 20 Feb 2002 12:23:22 -0500 From: Jeffrey Haas To: Alex Zinin Cc: idr@merit.edu Subject: Re: counting AS-path length Message-ID: <20020220122322.F22759@nexthop.com> References: <20020215152935.A4906@nexthop.com> <2394755781.20020219141143@nexsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2394755781.20020219141143@nexsi.com>; from azinin@nexsi.com on Tue, Feb 19, 2002 at 02:11:43PM -0800 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Tue, Feb 19, 2002 at 02:11:43PM -0800, Alex Zinin wrote: > Sounds like we should explicitly say that the TLVs > should be maximally packed. We would still have > the case where we have more ASNs than fit into > one TLV, but I don't think that current implementations > try to be smart and treat two adjacent sets as one, > if so, the spec should not say so either. Your first statement says we should ask implementations that don't do this to change behavior. Your second statements says the opposite. :-) What I'd like to see: Implementations should treat any adjacent AS_SETs as being part of the same set for purposes of AS_PATH length computation. Can we make this change to the specification? I'd prefer to see us state what we'd like to have implementors do and have implementors be non-compliant for a period of time and eventually fix stuff to be deterministic rather than leave this vague. For compliance purposes, this is doesn't seem to be a big deal. I don't see a lot of aggregates floating around the Internet at the moment. > Alex Zinin -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA11263 for ; Wed, 20 Feb 2002 10:37:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EE11F91297; Wed, 20 Feb 2002 10:37:13 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7A8591298; Wed, 20 Feb 2002 10:37:12 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 913AC91297 for ; Wed, 20 Feb 2002 10:37:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6F3765DDBF; Wed, 20 Feb 2002 10:37:11 -0500 (EST) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 1E63B5DDBC for ; Wed, 20 Feb 2002 10:37:11 -0500 (EST) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g1KFb2i50166; Wed, 20 Feb 2002 07:37:02 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200202201537.g1KFb2i50166@merlot.juniper.net> To: Alex Zinin Cc: idr@merit.edu Subject: Re: processing order of reach/unreach in rfc2858bis In-Reply-To: Your message of "Wed, 20 Feb 2002 00:48:00 PST." <26132931134.20020220004800@nexsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23131.1014219422.1@juniper.net> Date: Wed, 20 Feb 2002 07:37:02 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Alex, > Yakov, > > Is this intentional that the definition of "the same address > prefix" in Option 2 contains "(of the same )", while > in the other two options it does not? no, it was an unintentional omission. Yakov. > > -- > Alex Zinin > > Tuesday, February 19, 2002, 4:26:49 PM, Yakov Rekhter wrote: > > > Folks, > > > I see at least three options on how to deal with this: > > > Option 1: > > > An UPDATE message should not include the same address prefix in > > more than one of the following fields: WITHDRAWN ROUTES, Network > > Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI. > > An implementation that receives a packet in this form should process > > the Update as if it had processed it in the following order: > > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer > > Reachability Information. > > > Option 2: > > > An UPDATE message should not include the same address prefix > > (of the same ) in more than one of the following > > fields: WITHDRAWN ROUTES field, Network Reachability Information > > fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. However > > a BGP speaker MUST be able to process UPDATE messages in this > > form. A BGP speaker should treat an UPDATE message of this form > > as if that the address prefix were included only in the last > > field of the message. > > > Option 3: > > > An UPDATE message should not include the same address prefix in > > more than one of the following fields: WITHDRAWN ROUTES field, > > Network Reachability Information fields, MP_REACH_NLRI field, > > and MP_UNREACH_NLRI field. The processing of an UPDATE message > > in this form is un-defined. > > > Perhaps it is time to poll for a "rough consensus". So, please > > send me an e-mail stating your first and second choices. The > > deadline for this is March 6, 2002. > > > Yakov. > > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA02137 for ; Wed, 20 Feb 2002 04:25:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AF2EF91288; Wed, 20 Feb 2002 04:24:49 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 80E6391289; Wed, 20 Feb 2002 04:24:49 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 401DE91288 for ; Wed, 20 Feb 2002 04:24:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1C0575DD98; Wed, 20 Feb 2002 04:24:48 -0500 (EST) Delivered-To: idr@merit.edu Received: from ganesh.ctd.hctech.com (unknown [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id 23D2C5DD8C for ; Wed, 20 Feb 2002 04:24:47 -0500 (EST) Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 14:51:56 +0530 Message-ID: From: "Venu Kumar G - CTD, Chennai." To: idr@merit.edu Subject: AS_PATH attribute Date: Wed, 20 Feb 2002 14:52:45 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk hi ! I need three clarification on AS_PATH. 1qn . When you receive update packet which contains AS_PATH attribute of type AS_SET with only one AS number and no more AS_SEQUENCE's. Is it valid update packet.., or should we ignore such type of packets..? If i look more into details, when i receive such type of packet from internal peer, their is possibility that it can be valid, but when i receive the same thing from external peer, it is valid..? . (Such type of scenariao can never hapen). So when i receive this type of packets from external peers, Should i just discard the packet or I shoudl close the connection by sending notification to remote peer. 2 qn. So my 1st question raises a request to put one more update packet validation checking: Whenever you receive an update packet from ebgp peer, we should check for AS_SEQUENCE type in AS_PATTH attribute with atleast one is the length field of a AS-SEQUENCE length. Are this type of error should be covered under the catogorey of "AS_PATH attribute syntactical correctness". 3 qn . When i receive an update packet from internal peer with Zero length AS_PATH attribute and optional aggregator attibute is thier with local AS number and some ip address means. Should We consider this valid update packet..? But again, If it is valid ..... should i also compare the attomic aggregator attribute AS number with the BGP speakers AS number. Regards Venu G. When i receive update packet Regards Venu G. Disclaimer: This document is intended for transmission to the named recipient only. If you are not that person, you should note that legal rights reside in this document and you are not authorized to access, read, disclose, copy, use or otherwise deal with it and any such actions are prohibited and may be unlawful. The views expressed in this document are not necessarily those of HCL Technologies Ltd. Notice is hereby given that no representation, contract or other binding obligation shall be created by this e-mail, which must be interpreted accordingly. Any representations, contractual rights or obligations shall be separately communicated in writing and signed in the original by a duly authorized officer of the relevant company. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA01390 for ; Wed, 20 Feb 2002 03:49:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8C5E191286; Wed, 20 Feb 2002 03:48:45 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5BF5A91287; Wed, 20 Feb 2002 03:48:45 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 603C491286 for ; Wed, 20 Feb 2002 03:48:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3D24C5DDAE; Wed, 20 Feb 2002 03:48:44 -0500 (EST) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (system134.nexsi.com [66.35.197.134]) by segue.merit.edu (Postfix) with ESMTP id 96CB65DDA1 for ; Wed, 20 Feb 2002 03:48:43 -0500 (EST) Received: from khonsu.sw.nexsi.com ([192.168.103.205]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id AAA29499; Wed, 20 Feb 2002 00:46:51 -0800 Date: Wed, 20 Feb 2002 00:48:00 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <26132931134.20020220004800@nexsi.com> To: Yakov Rekhter Cc: idr@merit.edu, Jeffrey Haas , skh@nexthop.com Subject: Re: processing order of reach/unreach in rfc2858bis In-Reply-To: <200202200026.g1K0Qni14977@merlot.juniper.net> References: <200202200026.g1K0Qni14977@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Yakov, Is this intentional that the definition of "the same address prefix" in Option 2 contains "(of the same )", while in the other two options it does not? -- Alex Zinin Tuesday, February 19, 2002, 4:26:49 PM, Yakov Rekhter wrote: > Folks, > I see at least three options on how to deal with this: > Option 1: > An UPDATE message should not include the same address prefix in > more than one of the following fields: WITHDRAWN ROUTES, Network > Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI. > An implementation that receives a packet in this form should process > the Update as if it had processed it in the following order: > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer > Reachability Information. > Option 2: > An UPDATE message should not include the same address prefix > (of the same ) in more than one of the following > fields: WITHDRAWN ROUTES field, Network Reachability Information > fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. However > a BGP speaker MUST be able to process UPDATE messages in this > form. A BGP speaker should treat an UPDATE message of this form > as if that the address prefix were included only in the last > field of the message. > Option 3: > An UPDATE message should not include the same address prefix in > more than one of the following fields: WITHDRAWN ROUTES field, > Network Reachability Information fields, MP_REACH_NLRI field, > and MP_UNREACH_NLRI field. The processing of an UPDATE message > in this form is un-defined. > Perhaps it is time to poll for a "rough consensus". So, please > send me an e-mail stating your first and second choices. The > deadline for this is March 6, 2002. > Yakov. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA28604 for ; Wed, 20 Feb 2002 01:48:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5F31691284; Wed, 20 Feb 2002 01:48:10 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 30F7391285; Wed, 20 Feb 2002 01:48:10 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CFED291284 for ; Wed, 20 Feb 2002 01:48:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9AD7C5DDAD; Wed, 20 Feb 2002 01:48:08 -0500 (EST) Delivered-To: idr@merit.edu Received: from ep_mailout2 (unknown [203.254.224.14]) by segue.merit.edu (Postfix) with ESMTP id 51AA25DD95 for ; Wed, 20 Feb 2002 01:48:08 -0500 (EST) Received: from custom-daemon.mailout.samsung.com by mailout.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GRT00004K7V3V@mailout.samsung.com> for idr@merit.edu; Wed, 20 Feb 2002 15:47:55 +0900 (KST) Received: from ep_mmp (localhost [127.0.0.1]) by mailout.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GRT00N2MK7U0J@mailout.samsung.com> for idr@merit.edu (ORCPT idr@merit.edu); Wed, 20 Feb 2002 15:47:54 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GRT00A2RJW1ZR@mmp.samsung.com> for idr@merit.edu (ORCPT idr@merit.edu); Wed, 20 Feb 2002 15:40:50 +0900 (KST) Date: Wed, 20 Feb 2002 12:21:01 +0530 From: Manav Bhatia Subject: Re: Cluster can overlap.? To: "Venu Kumar G - CTD, Chennai." Cc: idr@merit.edu Reply-To: Manav Bhatia Message-id: <0e8501c1b9da$f67079e0$b4036c6b@Manav> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-idr@merit.edu Precedence: bulk Venu, A lot of ISPs operate with the hierarchical configuration of route reflectors in their domain. I am putting up the relevant parts of the configuration where a RR is defined as a client of another BIG RR for your understanding. Top-level router, peering in a full-mesh with other top-level routers: router bgp 1611 bgp cluster-id neighbor remote-as 1611 neighbor update-source Loopback0 neighbor route-reflector-client Next-level router, client of the top level, server for the bottom level: router bgp 1611 bgp cluster-id neighbor remote-as 1611 neighbor next-hop-self neighbor remote-as 1611 neighbor update-source Loopback0 neighbor route-reflector-client I agree that the rfc is not very *explicit* about this scenario but i always took it for granted. Hope it helps. Manav ----- Original Message ----- From: "Venu Kumar G - CTD, Chennai." To: "Manav Bhatia" Cc: Sent: Wednesday, February 20, 2002 12:04 PM Subject: RE: Cluster can overlap.? | hi manav ! | then all RR's in the same | cluster (big cluseter which including the overlap cluster RR) should | have different different cluster-id right...? But the rfc does not the | says the soo.... see the last line of the following rfc section 6 of rfc | 2796 | | | all RRs in the same cluster can be | configured with a 4-byte CLUSTER_ID so that an | RR can discard routes from other RRs in the same cluster. | | Regards | Venu G. | | | | -----Original Message----- | From: Manav Bhatia [mailto:manav@samsung.com] | Sent: Wednesday, February 20, 2002 11:59 AM | To: Venu Kumar G - CTD, Chennai.; idr@merit.edu | Subject: Re: Cluster can overlap.? | | | Venu, | One cluster can overlap with another cluster i.e. a RR for one cluster can | be a client peer of another BIG cluster. | | Manav | ----- Original Message ----- | From: "Venu Kumar G - CTD, Chennai." | To: | Sent: Wednesday, February 20, 2002 11:23 AM | Subject: Cluster can overlap.? | | | | hi ! | | | | | | | | In BGP route-reflector concepts..? Can one cluster can | overlap | | in ohter cluster. if it can overlap, all RR's in the same | cluster | | (including the overlap cluster RR) should have different different | | cluster-id. But the rfc does not the says the soo.... | | | | To make it clear, Here I am not discussing the point of | | redundant RR's in a cluster. | | | | | | | | | | Regards | | Venu g. | | | | Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA28377 for ; Wed, 20 Feb 2002 01:37:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AADBF91283; Wed, 20 Feb 2002 01:36:41 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7674191284; Wed, 20 Feb 2002 01:36:41 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3DC1791283 for ; Wed, 20 Feb 2002 01:36:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id ED73C5DDAD; Wed, 20 Feb 2002 01:36:39 -0500 (EST) Delivered-To: idr@merit.edu Received: from ganesh.ctd.hctech.com (unknown [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id 0E4975DD95 for ; Wed, 20 Feb 2002 01:36:39 -0500 (EST) Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 12:03:56 +0530 Message-ID: From: "Venu Kumar G - CTD, Chennai." To: Manav Bhatia Cc: idr@merit.edu Subject: RE: Cluster can overlap.? Date: Wed, 20 Feb 2002 12:04:44 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk hi manav ! then all RR's in the same cluster (big cluseter which including the overlap cluster RR) should have different different cluster-id right...? But the rfc does not the says the soo.... see the last line of the following rfc section 6 of rfc 2796 all RRs in the same cluster can be configured with a 4-byte CLUSTER_ID so that an RR can discard routes from other RRs in the same cluster. Regards Venu G. -----Original Message----- From: Manav Bhatia [mailto:manav@samsung.com] Sent: Wednesday, February 20, 2002 11:59 AM To: Venu Kumar G - CTD, Chennai.; idr@merit.edu Subject: Re: Cluster can overlap.? Venu, One cluster can overlap with another cluster i.e. a RR for one cluster can be a client peer of another BIG cluster. Manav ----- Original Message ----- From: "Venu Kumar G - CTD, Chennai." To: Sent: Wednesday, February 20, 2002 11:23 AM Subject: Cluster can overlap.? | hi ! | | | | In BGP route-reflector concepts..? Can one cluster can overlap | in ohter cluster. if it can overlap, all RR's in the same cluster | (including the overlap cluster RR) should have different different | cluster-id. But the rfc does not the says the soo.... | | To make it clear, Here I am not discussing the point of | redundant RR's in a cluster. | | | | | Regards | Venu g. | | Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA28114 for ; Wed, 20 Feb 2002 01:26:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2A1C491282; Wed, 20 Feb 2002 01:25:55 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EBEF491283; Wed, 20 Feb 2002 01:25:54 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD1D591282 for ; Wed, 20 Feb 2002 01:25:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8CD665DDAD; Wed, 20 Feb 2002 01:25:53 -0500 (EST) Delivered-To: idr@merit.edu Received: from ep_mailout2 (unknown [203.254.224.14]) by segue.merit.edu (Postfix) with ESMTP id 3B92E5DD95 for ; Wed, 20 Feb 2002 01:25:53 -0500 (EST) Received: from custom-daemon.mailout.samsung.com by mailout.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GRT00M01J6T1R@mailout.samsung.com> for idr@merit.edu; Wed, 20 Feb 2002 15:25:41 +0900 (KST) Received: from ep_mmp (localhost [127.0.0.1]) by mailout.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GRT00KJXJ6SCM@mailout.samsung.com> for idr@merit.edu (ORCPT idr@merit.edu); Wed, 20 Feb 2002 15:25:41 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GRT008IFIUZH9@mmp.samsung.com> for idr@merit.edu (ORCPT idr@merit.edu); Wed, 20 Feb 2002 15:18:37 +0900 (KST) Date: Wed, 20 Feb 2002 11:58:45 +0530 From: Manav Bhatia Subject: Re: Cluster can overlap.? To: "Venu Kumar G - CTD, Chennai." , idr@merit.edu Reply-To: Manav Bhatia Message-id: <0e1d01c1b9d7$db8c0b60$b4036c6b@Manav> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-idr@merit.edu Precedence: bulk Venu, One cluster can overlap with another cluster i.e. a RR for one cluster can be a client peer of another BIG cluster. Manav ----- Original Message ----- From: "Venu Kumar G - CTD, Chennai." To: Sent: Wednesday, February 20, 2002 11:23 AM Subject: Cluster can overlap.? | hi ! | | | | In BGP route-reflector concepts..? Can one cluster can overlap | in ohter cluster. if it can overlap, all RR's in the same cluster | (including the overlap cluster RR) should have different different | cluster-id. But the rfc does not the says the soo.... | | To make it clear, Here I am not discussing the point of | redundant RR's in a cluster. | | | | | Regards | Venu g. | | Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA27453 for ; Wed, 20 Feb 2002 00:55:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 11AE091281; Wed, 20 Feb 2002 00:55:08 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D17A291282; Wed, 20 Feb 2002 00:55:07 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 98C7F91281 for ; Wed, 20 Feb 2002 00:55:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5A0C75DDAD; Wed, 20 Feb 2002 00:55:06 -0500 (EST) Delivered-To: idr@merit.edu Received: from ganesh.ctd.hctech.com (unknown [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id 7D2DC5DDAE for ; Wed, 20 Feb 2002 00:55:05 -0500 (EST) Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 11:22:23 +0530 Message-ID: From: "Venu Kumar G - CTD, Chennai." To: idr@merit.edu Subject: Cluster can overlap.? Date: Wed, 20 Feb 2002 11:23:11 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk hi ! In BGP route-reflector concepts..? Can one cluster can overlap in ohter cluster. if it can overlap, all RR's in the same cluster (including the overlap cluster RR) should have different different cluster-id. But the rfc does not the says the soo.... To make it clear, Here I am not discussing the point of redundant RR's in a cluster. Regards Venu g. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA26362 for ; Wed, 20 Feb 2002 00:01:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7CDBB9127F; Wed, 20 Feb 2002 00:00:46 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4CBA091280; Wed, 20 Feb 2002 00:00:46 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 13D8D9127F for ; Wed, 20 Feb 2002 00:00:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id DD89F5DDB3; Wed, 20 Feb 2002 00:00:44 -0500 (EST) Delivered-To: idr@merit.edu Received: from ganesh.ctd.hctech.com (unknown [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id 068865DDAE for ; Wed, 20 Feb 2002 00:00:44 -0500 (EST) Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 10:28:02 +0530 Message-ID: From: "Venu Kumar G - CTD, Chennai." To: idr@merit.edu Subject: New RFC clarifications... Missed Last point Date: Wed, 20 Feb 2002 10:28:49 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk hi ! After reading the new BGP spec's, i have the following things unclear. 1 st clarification Section 3 last paragraph says.... Care must be taken to ensure that the interior routers have all been updated with transit information before the EBGP speakers announce to other ASs that transit service is being provided. Section 9.1.2 If the NEXT_HOP attribute of a BGP route depicts an address that is not resolvable, or it would become unresolvable if the route was installed in the routing table the BGP route should be excluded from the Phase 2 decision function. This first point raises the question that ....LOC-RIB considered all best routes may not be resolvabe. 2 nd clarification rfc 1772 section 7 point 1 says Care must be taken when a BGP speaker selects a new route that can't be announced to a particular external peer, while the previously selected route was announced to that peer. Specifically, the local system must explicitly indicate to the peer that the previous route is now infeasible. newdraft section 3.1 page 6 "b" point b) a replacement route with the same NLRI can be advertised, or the context of explanation for both points is same or different ..? it also links to the below point to some extent if the " rfc 1772 section " is correct, even after the new draft. new draft 4.3 section last paragraph An UPDATE message should not include the same address prefix in the WITHDRAWN ROUTES and Network Layer Reachability Information fields, however a BGP speaker MUST be able to process UPDATE messages in this form. A BGP speaker should treat an UPDATE message of this form as if the WITHDRAWN ROUTES doesn't contain the address prefix. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA26027 for ; Tue, 19 Feb 2002 23:46:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8FCEE9127E; Tue, 19 Feb 2002 23:46:22 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D60249127F; Tue, 19 Feb 2002 23:46:21 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 63D389127E for ; Tue, 19 Feb 2002 23:46:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 20A655DDAD; Tue, 19 Feb 2002 23:46:20 -0500 (EST) Delivered-To: idr@merit.edu Received: from ganesh.ctd.hctech.com (unknown [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id 385DA5DDAE for ; Tue, 19 Feb 2002 23:46:19 -0500 (EST) Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 10:13:34 +0530 Message-ID: From: "Venu Kumar G - CTD, Chennai." To: idr@merit.edu Subject: New RFC clarifications Date: Wed, 20 Feb 2002 10:14:21 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk hi ! After reading the new BGP spec's, i have the following things unclear. 1 st clarification Section 3 last paragraph says.... Care must be taken to ensure that the interior routers have all been updated with transit information before the EBGP speakers announce to other ASs that transit service is being provided. Section 9.1.2 If the NEXT_HOP attribute of a BGP route depicts an address that is not resolvable, or it would become unresolvable if the route was installed in the routing table the BGP route should be excluded from the Phase 2 decision function. This first point raises the question that ....LOC-RIB considered all best routes may not be resolvabe. 2 nd clarification rfc 1772 section 7 point 1 says Care must be taken when a BGP speaker selects a new route that can't be announced to a particular external peer, while the previously selected route was announced to that peer. Specifically, the local system must explicitly indicate to the peer that the previous route is now infeasible. newdraft section 3.1 page 6 "b" point b) a replacement route with the same NLRI can be advertised, or the context of explanation for both points is same or different ..? it also links to the below point to some extent if the " rfc 1772 section " is correct, even after the new draft. Disclaimer: This document is intended for transmission to the named recipient only. If you are not that person, you should note that legal rights reside in this document and you are not authorized to access, read, disclose, copy, use or otherwise deal with it and any such actions are prohibited and may be unlawful. The views expressed in this document are not necessarily those of HCL Technologies Ltd. Notice is hereby given that no representation, contract or other binding obligation shall be created by this e-mail, which must be interpreted accordingly. Any representations, contractual rights or obligations shall be separately communicated in writing and signed in the original by a duly authorized officer of the relevant company. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA20476 for ; Tue, 19 Feb 2002 19:42:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8811891208; Tue, 19 Feb 2002 19:41:51 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 560029127D; Tue, 19 Feb 2002 19:41:51 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3B81291208 for ; Tue, 19 Feb 2002 19:41:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 212235DDBA; Tue, 19 Feb 2002 19:41:50 -0500 (EST) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (unknown [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id C4C2D5DDAD for ; Tue, 19 Feb 2002 19:41:49 -0500 (EST) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g1K0Qni14977; Tue, 19 Feb 2002 16:26:49 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200202200026.g1K0Qni14977@merlot.juniper.net> To: idr@merit.edu Cc: Jeffrey Haas , skh@nexthop.com Subject: processing order of reach/unreach in rfc2858bis MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <41732.1014164809.1@juniper.net> Date: Tue, 19 Feb 2002 16:26:49 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, I see at least three options on how to deal with this: Option 1: An UPDATE message should not include the same address prefix in more than one of the following fields: WITHDRAWN ROUTES, Network Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI. An implementation that receives a packet in this form should process the Update as if it had processed it in the following order: WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer Reachability Information. Option 2: An UPDATE message should not include the same address prefix (of the same ) in more than one of the following fields: WITHDRAWN ROUTES field, Network Reachability Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. However a BGP speaker MUST be able to process UPDATE messages in this form. A BGP speaker should treat an UPDATE message of this form as if that the address prefix were included only in the last field of the message. Option 3: An UPDATE message should not include the same address prefix in more than one of the following fields: WITHDRAWN ROUTES field, Network Reachability Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. The processing of an UPDATE message in this form is un-defined. Perhaps it is time to poll for a "rough consensus". So, please send me an e-mail stating your first and second choices. The deadline for this is March 6, 2002. Yakov. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA17487 for ; Tue, 19 Feb 2002 17:12:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C19FB9127A; Tue, 19 Feb 2002 17:12:33 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F64D9127B; Tue, 19 Feb 2002 17:12:33 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A3AE79127A for ; Tue, 19 Feb 2002 17:12:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 82ABC5DDA7; Tue, 19 Feb 2002 17:12:32 -0500 (EST) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (system134.nexsi.com [66.35.197.134]) by segue.merit.edu (Postfix) with ESMTP id F13EB5DD8C for ; Tue, 19 Feb 2002 17:12:31 -0500 (EST) Received: from khonsu.sw.nexsi.com (khonsu.sw.nexsi.com [192.168.104.145] (may be forged)) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id OAA25190; Tue, 19 Feb 2002 14:10:34 -0800 Date: Tue, 19 Feb 2002 14:11:43 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <2394755781.20020219141143@nexsi.com> To: Jeffrey Haas Cc: idr@merit.edu Subject: Re: counting AS-path length In-Reply-To: <20020215152935.A4906@nexthop.com> References: <20020215152935.A4906@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Jeff, Sounds like we should explicitly say that the TLVs should be maximally packed. We would still have the case where we have more ASNs than fit into one TLV, but I don't think that current implementations try to be smart and treat two adjacent sets as one, if so, the spec should not say so either. -- Alex Zinin Friday, February 15, 2002, 12:29:35 PM, Jeffrey Haas wrote: > Yimei Zhang at NextHop recently pointed out something interesting. > Recently, the BGP specification was rev'ed to include the following: > : a) Remove from consideration all routes which are not tied for > : having the smallest number of AS numbers present in their AS_PATH > : attributes. Note, that when counting this number, an AS_SET counts > : as 1, no matter how many ASs are in the set, and that, if the > : implementation supports [13], then AS numbers present in segments > : of type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in > : the count of AS numbers present in the AS_PATH. > The changes include: > 1. Counting sets as length 1. > 2. Ignoring confed elements in the length calculation. > When we perform aggregation and generate an AS-set, the rules for > aggregation have us treat the elements of the path as > tuples. We then perform our aggregation. However, the aggregation > section doesn't talk about how the generated Aggregate's AS_PATH > is to be structured. > By the current specification, it is legal for the generated AS_PATH > to construct the AS_PATH TLV's such that they are not maximally filled > (i.e. 255 elements for a given type) prior to making a new one. > IOW, it is legal to have an AS_PATH of: > "1 2 3" [4 5 6] -or- > "1" "2" "3" [4] [5] [6] > Where "" denotes a AS_SEQ and [] denotes an AS_SET. > This is primarily important since sets are considered in the length > computation for tie breaking. > This is admittedly an edge case since all the implementations I've seen > will maximally pack the TLV. It becomes an issue if we ever have more > than 255 elements in a set and need two sets. Is the length of two > adjacent sets "1" or "2"? > Thoughts? Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA12865 for ; Tue, 19 Feb 2002 13:43:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4562791272; Tue, 19 Feb 2002 13:43:26 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 193E891273; Tue, 19 Feb 2002 13:43:26 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DCA8091272 for ; Tue, 19 Feb 2002 13:43:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id B85745DD8D; Tue, 19 Feb 2002 13:43:24 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailwest.unispherenetworks.com (unknown [65.194.140.130]) by segue.merit.edu (Postfix) with ESMTP id 847F35DD8C for ; Tue, 19 Feb 2002 13:43:24 -0500 (EST) Received: by uniwest1.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id <1J3BYF6V>; Tue, 19 Feb 2002 13:43:20 -0500 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C02E7E5F7@uniwest1.it.west.unispherenetworks.com> From: "Rijsman, Bruno" To: "'Jeffrey Haas'" , idr@merit.edu Subject: RE: processing order of reach/unreach in rfc2858bis Date: Tue, 19 Feb 2002 13:43:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk The Unisphere implementation processes mp_unreach first and mp_reach next (i.e. same deterministic order as regular prefixes), regardless of the order in which they are encoded in the received UPDATE. So, I agree with Jeffry's suggestion in item 4 below. -- Bruno -----Original Message----- From: Jeffrey Haas [mailto:jhaas@nexthop.com] Sent: Tuesday, February 19, 2002 1:35 PM To: idr@merit.edu Subject: processing order of reach/unreach in rfc2858bis I'd like to ask people to look at this issue one last time. The last call drum is being beaten. Here is the relevant list mail, mildly edited to remove the safi=3 stuff. Quick synopsis: 1. Current version of rfc2858bis recommends processing mp_(un)reach_nlri in packet order. 2. In implementations that sort path attributes, mp_reach will precede mp_unreach. 3. In the base bgp draft, we state that wd_nlri should be processed prior to nlri. 4. I would like to see the same determinism (unreach processed first, reach processed next) in the mp fields, regardless of packet ordering. ----- Forwarded message from Jeffrey Haas ----- Date: Mon, 14 Jan 2002 23:21:28 -0500 From: Jeffrey Haas To: Enke Chen On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote: > As Yakov and Sue pointed out, it is a good idea to discourage > having one prefix in multiple fields of an update message. How about the > following text: > > An UPDATE message should not include the same address prefix in more than > one of the following fields: WITHDRAWN ROUTES field, Network Reachability > Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. The > processing of an UPDATE message in this form is un-defined. I think that "undefined" is overkill. I would suggest the following instead: An UPDATE message should not include the same address prefix in more than one of the following fields: WITHDRAWN ROUTES, Network Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI. An implementation that receives a packet in this form should process the Update as if it had processed it in the following order: WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer Reachability Information. The wording could probably use some tightening. The intended result is that reachability rules over unreachability. > -- Enke -- Jeff Haas NextHop Technologies ----- End forwarded message ----- ----- Forwarded message from Enke Chen ----- Date: Tue, 15 Jan 2002 09:47:16 -0800 From: Enke Chen To: Jeffrey Haas Jeff, [...] So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem to add much value, but has caused a lot of confusion and complexity. I am not aware of any depolyment either. > > > As Yakov and Sue pointed out, it is a good idea to discourage > > having one prefix in multiple fields of an update message. How about the > > following text: > > > > An UPDATE message should not include the same address prefix in more than > > one of the following fields: WITHDRAWN ROUTES field, Network Reachability > > Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. The > > processing of an UPDATE message in this form is un-defined. > > I think that "undefined" is overkill. I would suggest the following instead: > > An UPDATE message should not include the same address prefix in > more than one of the following fields: WITHDRAWN ROUTES, Network > Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI. > An implementation that receives a packet in this form should process > the Update as if it had processed it in the following order: > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer > Reachability Information. > > The wording could probably use some tightening. > > The intended result is that reachability rules over unreachability. If we want to define the behavior, I would like to suggest sticking to the order in the message. That probably would reflect the sender's intention more closely, and make the processing simpler. -- Enke ----- End forwarded message ----- ----- Forwarded message from Jeffrey Haas ----- Date: Tue, 15 Jan 2002 16:15:52 -0500 From: Jeffrey Haas To: Enke Chen On Tue, Jan 15, 2002 at 09:47:16AM -0800, Enke Chen wrote: > If we want to define the behavior, I would like to suggest sticking to > the order in the message. That probably would reflect the sender's > intention more closely, and make the processing simpler. Two issues: 1. Path attribute order, when sorted, puts MP_UNREACH_NLRI after MP_REACH_NLRI. 2. Path attributes are now explicitly allowed to be unordered. I'd rather see some determinism across implementations. > -- Enke -- Jeff Haas NextHop Technologies ----- End forwarded message ----- -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA12731 for ; Tue, 19 Feb 2002 13:36:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8AEC891271; Tue, 19 Feb 2002 13:35:40 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CD1491272; Tue, 19 Feb 2002 13:35:40 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4672D91271 for ; Tue, 19 Feb 2002 13:35:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1E8AF5DD8D; Tue, 19 Feb 2002 13:35:39 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 04C015DD8C for ; Tue, 19 Feb 2002 13:35:39 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g1JIZG324567 for ; Tue, 19 Feb 2002 13:35:16 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g1JIYoO20739 for idr@merit.edu; Tue, 19 Feb 2002 13:34:50 -0500 (EST) Date: Tue, 19 Feb 2002 13:34:50 -0500 From: Jeffrey Haas To: idr@merit.edu Subject: processing order of reach/unreach in rfc2858bis Message-ID: <20020219133450.A20727@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk I'd like to ask people to look at this issue one last time. The last call drum is being beaten. Here is the relevant list mail, mildly edited to remove the safi=3 stuff. Quick synopsis: 1. Current version of rfc2858bis recommends processing mp_(un)reach_nlri in packet order. 2. In implementations that sort path attributes, mp_reach will precede mp_unreach. 3. In the base bgp draft, we state that wd_nlri should be processed prior to nlri. 4. I would like to see the same determinism (unreach processed first, reach processed next) in the mp fields, regardless of packet ordering. ----- Forwarded message from Jeffrey Haas ----- Date: Mon, 14 Jan 2002 23:21:28 -0500 From: Jeffrey Haas To: Enke Chen On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote: > As Yakov and Sue pointed out, it is a good idea to discourage > having one prefix in multiple fields of an update message. How about the > following text: > > An UPDATE message should not include the same address prefix in more than > one of the following fields: WITHDRAWN ROUTES field, Network Reachability > Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. The > processing of an UPDATE message in this form is un-defined. I think that "undefined" is overkill. I would suggest the following instead: An UPDATE message should not include the same address prefix in more than one of the following fields: WITHDRAWN ROUTES, Network Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI. An implementation that receives a packet in this form should process the Update as if it had processed it in the following order: WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer Reachability Information. The wording could probably use some tightening. The intended result is that reachability rules over unreachability. > -- Enke -- Jeff Haas NextHop Technologies ----- End forwarded message ----- ----- Forwarded message from Enke Chen ----- Date: Tue, 15 Jan 2002 09:47:16 -0800 From: Enke Chen To: Jeffrey Haas Jeff, [...] So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem to add much value, but has caused a lot of confusion and complexity. I am not aware of any depolyment either. > > > As Yakov and Sue pointed out, it is a good idea to discourage > > having one prefix in multiple fields of an update message. How about the > > following text: > > > > An UPDATE message should not include the same address prefix in more than > > one of the following fields: WITHDRAWN ROUTES field, Network Reachability > > Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. The > > processing of an UPDATE message in this form is un-defined. > > I think that "undefined" is overkill. I would suggest the following instead: > > An UPDATE message should not include the same address prefix in > more than one of the following fields: WITHDRAWN ROUTES, Network > Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI. > An implementation that receives a packet in this form should process > the Update as if it had processed it in the following order: > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer > Reachability Information. > > The wording could probably use some tightening. > > The intended result is that reachability rules over unreachability. If we want to define the behavior, I would like to suggest sticking to the order in the message. That probably would reflect the sender's intention more closely, and make the processing simpler. -- Enke ----- End forwarded message ----- ----- Forwarded message from Jeffrey Haas ----- Date: Tue, 15 Jan 2002 16:15:52 -0500 From: Jeffrey Haas To: Enke Chen On Tue, Jan 15, 2002 at 09:47:16AM -0800, Enke Chen wrote: > If we want to define the behavior, I would like to suggest sticking to > the order in the message. That probably would reflect the sender's > intention more closely, and make the processing simpler. Two issues: 1. Path attribute order, when sorted, puts MP_UNREACH_NLRI after MP_REACH_NLRI. 2. Path attributes are now explicitly allowed to be unordered. I'd rather see some determinism across implementations. > -- Enke -- Jeff Haas NextHop Technologies ----- End forwarded message ----- -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA13861 for ; Fri, 15 Feb 2002 15:30:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B7C7D912E0; Fri, 15 Feb 2002 15:29:59 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B4BB912E3; Fri, 15 Feb 2002 15:29:59 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 89A1D912E0 for ; Fri, 15 Feb 2002 15:29:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 68DBE5DDE5; Fri, 15 Feb 2002 15:29:58 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 49DA35DDC6 for ; Fri, 15 Feb 2002 15:29:58 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g1FKTi396563 for ; Fri, 15 Feb 2002 15:29:44 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g1FKTZD04919 for idr@merit.edu; Fri, 15 Feb 2002 15:29:35 -0500 (EST) Date: Fri, 15 Feb 2002 15:29:35 -0500 From: Jeffrey Haas To: idr@merit.edu Subject: counting AS-path length Message-ID: <20020215152935.A4906@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Yimei Zhang at NextHop recently pointed out something interesting. Recently, the BGP specification was rev'ed to include the following: : a) Remove from consideration all routes which are not tied for : having the smallest number of AS numbers present in their AS_PATH : attributes. Note, that when counting this number, an AS_SET counts : as 1, no matter how many ASs are in the set, and that, if the : implementation supports [13], then AS numbers present in segments : of type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in : the count of AS numbers present in the AS_PATH. The changes include: 1. Counting sets as length 1. 2. Ignoring confed elements in the length calculation. When we perform aggregation and generate an AS-set, the rules for aggregation have us treat the elements of the path as tuples. We then perform our aggregation. However, the aggregation section doesn't talk about how the generated Aggregate's AS_PATH is to be structured. By the current specification, it is legal for the generated AS_PATH to construct the AS_PATH TLV's such that they are not maximally filled (i.e. 255 elements for a given type) prior to making a new one. IOW, it is legal to have an AS_PATH of: "1 2 3" [4 5 6] -or- "1" "2" "3" [4] [5] [6] Where "" denotes a AS_SEQ and [] denotes an AS_SET. This is primarily important since sets are considered in the length computation for tie breaking. This is admittedly an edge case since all the implementations I've seen will maximally pack the TLV. It becomes an issue if we ever have more than 255 elements in a set and need two sets. Is the length of two adjacent sets "1" or "2"? Thoughts? -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA09222 for ; Fri, 15 Feb 2002 12:03:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 47B579121F; Fri, 15 Feb 2002 12:03:33 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21EC691220; Fri, 15 Feb 2002 12:03:33 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4B7A59121F for ; Fri, 15 Feb 2002 12:03:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 270C65DDC5; Fri, 15 Feb 2002 12:03:23 -0500 (EST) Delivered-To: idr@merit.edu Received: from exc-sc1.yagosys.com (host3.riverstonenet.com [63.113.148.3]) by segue.merit.edu (Postfix) with ESMTP id C1AEE5DD9E for ; Fri, 15 Feb 2002 12:03:22 -0500 (EST) Received: by exc-sc1 with Internet Mail Service (5.5.2653.19) id <1PZY5HKD>; Fri, 15 Feb 2002 09:02:31 -0800 Message-ID: <3820E2042B6ED5118DC200D0B78EDC470F2111@exc-reo1.yagosys.com> From: "Waters, Stephen" To: "'idr@merit.edu'" Subject: ORF - no wildcard = losts of typing Date: Fri, 15 Feb 2002 09:02:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk The ORF spec. state that (in section 7): "If a particular route maintained by a BGP speaker doesn't match any of the ORF entries of any of the ORFs associated with a particular peer, then this route should not be advertised to the peer". If the BGP manager simply wants to block "some unwanted routes" (section 3), they would need to enter every other possible route to insure that no routes are lost. Since there is no wild-carding defined in communities or the ORFs, these would be hard/impossible. Do we need a wild-card ORF entry which specifies the default case (DENY or PERMIT), or perhaps the 'no-match' action could be defined as part of the capability negotiation? Regards, Steve. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA28173 for ; Fri, 15 Feb 2002 03:51:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 23D6891257; Fri, 15 Feb 2002 03:51:29 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D379D912C6; Fri, 15 Feb 2002 03:51:28 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7EC7991257 for ; Fri, 15 Feb 2002 03:51:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5AD6C5DDBE; Fri, 15 Feb 2002 03:51:26 -0500 (EST) Delivered-To: idr@merit.edu Received: from exc-sc1.yagosys.com (host3.riverstonenet.com [63.113.148.3]) by segue.merit.edu (Postfix) with ESMTP id F3DBD5DDAC for ; Fri, 15 Feb 2002 03:51:25 -0500 (EST) Received: by exc-sc1 with Internet Mail Service (5.5.2653.19) id <1PZY5CJR>; Fri, 15 Feb 2002 00:50:44 -0800 Message-ID: <3820E2042B6ED5118DC200D0B78EDC470F210C@exc-reo1.yagosys.com> From: "Waters, Stephen" To: "'Enke Chen'" Cc: "'idr@merit.edu'" Subject: RE: ORF and mixed community sets Date: Fri, 15 Feb 2002 00:50:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk Hi Enke, thanks for the reply. That would seem to work. So, reading between the lines of the spec, with standard, and extended ORF-Types have been received, routes that carry both standard and extended communities will have to match both ORFs. I have another issue with the spec. that is causing me sleepless nights: This section, in 4.1: "NORMAL scope indicates that the remote peer should consider only those routes whose Communities attribute either is equal to the Communities list specified in the ORF, or exhibit a subset relation with the Communities list specified in the ORF." Since it may not be predictable what communities will arrive in a route, requiring that the ORF be a superset of those communities in a route seems difficult/impossible. It would seem more useful (to me) if this relationship was reverse, i.e. the ORF matches if it forms a subset of the communities in a route. How do you feel about that? Cheers, Steve. > -----Original Message----- > From: Enke Chen [mailto:enke@redback.com] > Sent: Thursday, February 14, 2002 6:01 PM > To: Waters, Stephen > Cc: 'idr@merit.edu'; enke@redback.com > Subject: Re: ORF and mixed community sets > > > Hi, Steve: > > > Message-ID: > <3820E2042B6ED5118DC200D0B78EDC470F210B@exc-reo1.yagosys.com> > > From: "Waters, Stephen" > > To: "'idr@merit.edu'" > > Subject: ORF and mixed community sets > > Date: Thu, 14 Feb 2002 09:26:40 -0800 > > MIME-Version: 1.0 > > X-Mailer: Internet Mail Service (5.5.2653.19) > > Content-Type: text/plain; > > charset="iso-8859-2" > > Sender: owner-idr@merit.edu > > Precedence: bulk > > > > > > >From the format described in > draft-ietf-idr-route-filter-05.txt, it is not > > possible to establish a filter for route that has both > standard and extended > > community attributes since part of the 'common-part' is the > ORF-Type, which > > indicates if the communities are standard or extended. > > Please note the community-ORF and ext-community-ORF are two different > ORF types. > > See the following text in the draft on how to handle multiple > ORF types: > > Sect. 7 Operation > > If a BGP speaker maintains multiple ORFs of different > ORF-Types for a > particular peer, then the decision by the speaker to advertise a > route to the peer is determined by passing the route through each > such ORF, and and-ing the results (and-ing of PERMIT and > DENY results > in DENY). > > -- Enke > > > > > As things stand, local inbound policy which addresses > filtering on routes > > with mixed community-id types can not be sent as part of the ORF. > > > > To fix this, perhaps the ORF-TYPE can be moved to the > type-specific coding: > > > > ...> > > > > Regards, > > Steve. > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA08485 for ; Thu, 14 Feb 2002 13:01:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6921A912A7; Thu, 14 Feb 2002 13:01:00 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09F3E912C6; Thu, 14 Feb 2002 13:00:59 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EA006912A7 for ; Thu, 14 Feb 2002 13:00:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id CFD9B5DDE3; Thu, 14 Feb 2002 13:00:58 -0500 (EST) Delivered-To: idr@merit.edu Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 9608B5DD8C for ; Thu, 14 Feb 2002 13:00:58 -0500 (EST) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id BDDC3F2C44; Thu, 14 Feb 2002 10:00:39 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id F0FF515D3C1; Thu, 14 Feb 2002 10:00:38 -0800 (PST) To: "Waters, Stephen" Cc: "'idr@merit.edu'" , enke@redback.com Subject: Re: ORF and mixed community sets In-Reply-To: Message from "Waters, Stephen" of "Thu, 14 Feb 2002 09:26:40 PST." <3820E2042B6ED5118DC200D0B78EDC470F210B@exc-reo1.yagosys.com> Date: Thu, 14 Feb 2002 10:00:38 -0800 From: Enke Chen Message-Id: <20020214180039.F0FF515D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Steve: > Message-ID: <3820E2042B6ED5118DC200D0B78EDC470F210B@exc-reo1.yagosys.com> > From: "Waters, Stephen" > To: "'idr@merit.edu'" > Subject: ORF and mixed community sets > Date: Thu, 14 Feb 2002 09:26:40 -0800 > MIME-Version: 1.0 > X-Mailer: Internet Mail Service (5.5.2653.19) > Content-Type: text/plain; > charset="iso-8859-2" > Sender: owner-idr@merit.edu > Precedence: bulk > > > >From the format described in draft-ietf-idr-route-filter-05.txt, it is not > possible to establish a filter for route that has both standard and extended > community attributes since part of the 'common-part' is the ORF-Type, which > indicates if the communities are standard or extended. Please note the community-ORF and ext-community-ORF are two different ORF types. See the following text in the draft on how to handle multiple ORF types: Sect. 7 Operation If a BGP speaker maintains multiple ORFs of different ORF-Types for a particular peer, then the decision by the speaker to advertise a route to the peer is determined by passing the route through each such ORF, and and-ing the results (and-ing of PERMIT and DENY results in DENY). -- Enke > > As things stand, local inbound policy which addresses filtering on routes > with mixed community-id types can not be sent as part of the ORF. > > To fix this, perhaps the ORF-TYPE can be moved to the type-specific coding: > > ...> > > Regards, > Steve. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA07816 for ; Thu, 14 Feb 2002 12:27:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 64F909129C; Thu, 14 Feb 2002 12:27:07 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2EB99912C5; Thu, 14 Feb 2002 12:27:07 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 061A89129C for ; Thu, 14 Feb 2002 12:27:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id DFA495DDE3; Thu, 14 Feb 2002 12:27:05 -0500 (EST) Delivered-To: idr@merit.edu Received: from exc-sc1.yagosys.com (host3.riverstonenet.com [63.113.148.3]) by segue.merit.edu (Postfix) with ESMTP id 731435DD8C for ; Thu, 14 Feb 2002 12:27:05 -0500 (EST) Received: by exc-sc1 with Internet Mail Service (5.5.2653.19) id <1PZYZW3D>; Thu, 14 Feb 2002 09:26:25 -0800 Message-ID: <3820E2042B6ED5118DC200D0B78EDC470F210B@exc-reo1.yagosys.com> From: "Waters, Stephen" To: "'idr@merit.edu'" Subject: ORF and mixed community sets Date: Thu, 14 Feb 2002 09:26:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-2" Sender: owner-idr@merit.edu Precedence: bulk >From the format described in draft-ietf-idr-route-filter-05.txt, it is not possible to establish a filter for route that has both standard and extended community attributes since part of the 'common-part' is the ORF-Type, which indicates if the communities are standard or extended. As things stand, local inbound policy which addresses filtering on routes with mixed community-id types can not be sent as part of the ORF. To fix this, perhaps the ORF-TYPE can be moved to the type-specific coding: ...> Regards, Steve. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA05149 for ; Thu, 14 Feb 2002 10:27:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8B19791299; Thu, 14 Feb 2002 10:26:36 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5AC939129A; Thu, 14 Feb 2002 10:26:36 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3664F91299 for ; Thu, 14 Feb 2002 10:26:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 17D215DDA7; Thu, 14 Feb 2002 10:26:35 -0500 (EST) Delivered-To: idr@merit.edu Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by segue.merit.edu (Postfix) with ESMTP id B74755DD8C for ; Thu, 14 Feb 2002 10:26:34 -0500 (EST) Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.50 2002/02/08 23:45:02 root Exp $) with SMTP id PAA04485 for ; Thu, 14 Feb 2002 15:26:18 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002021407270531571 ; Thu, 14 Feb 2002 07:27:05 -0800 Received: from alpha.igk.intel.com ([172.28.168.68]) by fmsmsx29.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1YPHZ70W; Thu, 14 Feb 2002 07:26:18 -0800 Received: by alpha.igk.intel.com with Internet Mail Service (5.5.2653.19) id <4L8KF4NZ>; Thu, 14 Feb 2002 16:25:55 +0100 Message-ID: <413FBB0BA5AED1119122000083234B1A015A92E9@alpha.igk.intel.com> From: "Fryczke, Pawel" To: "'Manav Bhatia'" Cc: idr@merit.edu Subject: RE: Route refresh question Date: Thu, 14 Feb 2002 16:25:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-2" Sender: owner-idr@merit.edu Precedence: bulk >>If a route is not to be announced then a withdrawn is sent instead. This is the answer I expected. Thanks for help. Pawel P.S Maybe it is worth to be mentioned in RFC ? -----Original Message----- From: Manav Bhatia [mailto:manav@samsung.com] Sent: Thursday, February 14, 2002 2:55 PM To: Fryczke, Pawel Cc: idr@merit.edu Subject: Re: Route refresh question Hi Pawel, | 1. Router_A and Router_B are BGP peers. Router_B advertises several prefixes | to Router_A. | 2. Router_A sends RR message to Router_B (because of export policy | reconfiguration) | 3. Router_B re-advertises its adj-RIB-out and replies with several UPDATE | messages. These updates does not include few prefixes advertised to router_A | before RR message was sent (because of policy change) Router B should traverse its entire BGP RIB for the particular afi-safi combination and announce all routes learnt from peers other than Router_A. If a route is not to be announced then a withdrawn is sent instead. Router_A in turn applies its new policies and accepts the UPDATEs from Router_B. | How does the Router_A know about missing prefixes? Note that these prefixes | must be withdrawn from Loc-Rib which missing prefixes are you talking of? If its the prefixes which were initially discarded due to its inbound policy setting then it need not know about them. Router_B will send all the valid UPDATEs once again. | How does the Router_A know that re-advertisement is finished and it won't | receive any other UPDATE messages in response to originated RR message ? why does it need to know this? | Withdrawing all received prefixes from Loc-Rib before sending RR does not | make any sense. i'm sorry .. i couldn't get you? Regards, Manav Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA03079 for ; Thu, 14 Feb 2002 08:54:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3B39E91298; Thu, 14 Feb 2002 08:53:43 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06EF191299; Thu, 14 Feb 2002 08:53:42 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BE3A391298 for ; Thu, 14 Feb 2002 08:53:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id A0C1B5DDDA; Thu, 14 Feb 2002 08:53:41 -0500 (EST) Delivered-To: idr@merit.edu Received: from exc-sc1.yagosys.com (host3.riverstonenet.com [63.113.148.3]) by segue.merit.edu (Postfix) with ESMTP id 3DBCF5DDA7 for ; Thu, 14 Feb 2002 08:53:41 -0500 (EST) Received: by exc-sc1 with Internet Mail Service (5.5.2653.19) id <1PZYZ4AF>; Thu, 14 Feb 2002 05:53:00 -0800 Message-ID: <3820E2042B6ED5118DC200D0B78EDC470F2107@exc-reo1.yagosys.com> From: "Waters, Stephen" To: "'idr@merit.edu'" Subject: ORF - subset or superset ? ( draft-ietf-idr-route-filter-05.txt) Date: Thu, 14 Feb 2002 05:53:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk In this draft, for a 'NORMAL' match, it requires that the communities in the route form a 'subset' of those defined in the ORF filter. This seems to block the useful (necessary?) desire to apply a filter where the ORF communities match if they are a subset of those specified in a route. If I wanted to permit all routes that contain "160:1 and 170:1", regardless of what other communities they may be part of, there is no way to express that. To resolve this, it seems that the 'Scope' value would need to support EXACT, SUBSET, SUPERSET, where SUBSET = 'match if ORF communities for part of those in the route', and SUPERSET = current 'NORMAL' case. Steve. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA03045 for ; Thu, 14 Feb 2002 08:52:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8795C91297; Thu, 14 Feb 2002 08:51:45 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 573C491298; Thu, 14 Feb 2002 08:51:45 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E1FF491297 for ; Thu, 14 Feb 2002 08:51:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id B58EE5DDE8; Thu, 14 Feb 2002 08:51:43 -0500 (EST) Delivered-To: idr@merit.edu Received: from ep_mailout2 (unknown [203.254.224.14]) by segue.merit.edu (Postfix) with ESMTP id 6BFAD5DDA7 for ; Thu, 14 Feb 2002 08:51:43 -0500 (EST) Received: from custom-daemon.mailout.samsung.com by mailout.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GRI00I01ZTUKT@mailout.samsung.com> for idr@merit.edu; Thu, 14 Feb 2002 22:51:30 +0900 (KST) Received: from ep_mmp (localhost [127.0.0.1]) by mailout.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GRI00H5VZTUWD@mailout.samsung.com> for idr@merit.edu (ORCPT idr@merit.edu); Thu, 14 Feb 2002 22:51:30 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GRI00HH9ZI3OR@mmp.samsung.com> for idr@merit.edu (ORCPT idr@merit.edu); Thu, 14 Feb 2002 22:44:29 +0900 (KST) Date: Thu, 14 Feb 2002 19:24:51 +0530 From: Manav Bhatia Subject: Re: Route refresh question To: "Fryczke, Pawel" Cc: idr@merit.edu Reply-To: Manav Bhatia Message-id: <02a601c1b55f$2d6aa950$b4036c6b@Manav> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=ISO-8859-2 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <413FBB0BA5AED1119122000083234B1A015A92E6@alpha.igk.intel.com> Sender: owner-idr@merit.edu Precedence: bulk Hi Pawel, | 1. Router_A and Router_B are BGP peers. Router_B advertises several prefixes | to Router_A. | 2. Router_A sends RR message to Router_B (because of export policy | reconfiguration) | 3. Router_B re-advertises its adj-RIB-out and replies with several UPDATE | messages. These updates does not include few prefixes advertised to router_A | before RR message was sent (because of policy change) Router B should traverse its entire BGP RIB for the particular afi-safi combination and announce all routes learnt from peers other than Router_A. If a route is not to be announced then a withdrawn is sent instead. Router_A in turn applies its new policies and accepts the UPDATEs from Router_B. | How does the Router_A know about missing prefixes? Note that these prefixes | must be withdrawn from Loc-Rib which missing prefixes are you talking of? If its the prefixes which were initially discarded due to its inbound policy setting then it need not know about them. Router_B will send all the valid UPDATEs once again. | How does the Router_A know that re-advertisement is finished and it won't | receive any other UPDATE messages in response to originated RR message ? why does it need to know this? | Withdrawing all received prefixes from Loc-Rib before sending RR does not | make any sense. i'm sorry .. i couldn't get you? Regards, Manav Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA29422 for ; Thu, 14 Feb 2002 06:04:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 35A2791295; Thu, 14 Feb 2002 06:04:05 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 035F891297; Thu, 14 Feb 2002 06:04:04 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 89EC391295 for ; Thu, 14 Feb 2002 06:04:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 695135DDA7; Thu, 14 Feb 2002 06:04:03 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 283015DDA2 for ; Thu, 14 Feb 2002 06:04:03 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id GAA23564; Thu, 14 Feb 2002 06:03:56 -0500 (EST) Date: Thu, 14 Feb 2002 06:03:56 -0500 (EST) From: Russ White Reply-To: Russ White To: andrea403@interfree.it Cc: idr@merit.edu Subject: Re: NEXT HOP ATTRIBUTE In-Reply-To: <20020213145357.29684.qmail@community9.interfree.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk > In the rfc1771 I read that in a IBGP session BGP routers > can't change the NEXT HOP ATTRIBUTE. I query a Looking > Glasses with "show ip bgp prefix" command. This is the > output: > > ....... > 7660 22388 11537 9010 137, (aggregated by 137 193.206.129.252) > 202.241.2.100 (metric 4) from 202.241.2.100 (202.241.2.100) > Origin IGP, localpref 90, valid, internal, atomic-aggregate, best > Community: 756091333 > ......... > This route was redistribuited from a internal BGP router, but > the NEXT HOP attribute and the IP of advertisor are the same > and there are in the same AS of the Looking GLass. Why a IGBP > router have changed the NEXT HOP attribute in a IBGP session? Quite a number of networks use 'next hop self' in a lot of places where it makes topological sense, and (I presume) all the vendors support it. Sounds like this is something that should be checked on in the current work and considered? Russ _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA28095 for ; Thu, 14 Feb 2002 05:11:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0D9C591254; Thu, 14 Feb 2002 05:11:26 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD4E691295; Thu, 14 Feb 2002 05:11:25 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 98C0391254 for ; Thu, 14 Feb 2002 05:11:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 713D85DDE4; Thu, 14 Feb 2002 05:11:24 -0500 (EST) Delivered-To: idr@merit.edu Received: from community9.interfree.it (community9.interfree.it [213.158.72.64]) by segue.merit.edu (Postfix) with SMTP id B4BF75DDA7 for ; Thu, 14 Feb 2002 05:11:23 -0500 (EST) Received: (qmail 24786 invoked by uid 320); 14 Feb 2002 10:11:19 -0000 Date: 14 Feb 2002 10:11:19 -0000 Message-ID: <20020214101119.24785.qmail@community9.interfree.it> From: andrea403@interfree.it () Reply-To: andrea403@interfree.it To: idr@merit.edu Subject: SHOW IP BGP OUTPUT 2 Sender: owner-idr@merit.edu Precedence: bulk In the "show ip BGP output" i read a row with three IP address. The first is the next hop ip, the second is the advertiser ip, and what is the third? Is the router ID of the next hop or of the advertiser? Thankyou Andrea Monaco ----------------------------------------------------- Salve, il messaggio che hai ricevuto è stato inviato per mezzo del sistema di web mail interfree. Se anche tu vuoi una casella di posta free visita il sito http://club.interfree.it Ti aspettiamo! ----------------------------------------------------- Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA10809 for ; Wed, 13 Feb 2002 15:02:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4F69E91246; Wed, 13 Feb 2002 15:01:31 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 869D891247; Wed, 13 Feb 2002 15:01:25 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1F08891246 for ; Wed, 13 Feb 2002 15:01:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id DF3835DDDA; Wed, 13 Feb 2002 15:01:21 -0500 (EST) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 5DA625DDAA for ; Wed, 13 Feb 2002 15:01:21 -0500 (EST) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g1DK1L608879; Wed, 13 Feb 2002 12:01:21 -0800 (PST) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g1DK1K411254; Wed, 13 Feb 2002 12:01:20 -0800 (PST) (envelope-from roque) Date: Wed, 13 Feb 2002 12:01:20 -0800 (PST) Message-Id: <200202132001.g1DK1K411254@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Shah, VJ" Cc: "'idr@merit.edu'" Subject: RE: Clarficiation required on ID - Cooperative Route Filtering Ca pabi lity for BGP-4 In-Reply-To: <9BF027DAD859D511A383000347713E20263F01@uniwest2.it.west.unispherenetworks.com> References: <9BF027DAD859D511A383000347713E20263F01@uniwest2.it.west.unispherenetworks.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Shah, VJ writes: > Finally, if the remote peer currently does not support the > ipv6-unicast address family, we still expect it to remember our orf > capability advertisement so that it will be used when the > ipv6-unicast address family is turned on on the remote peer (without > us re-advertising it). The simplest aproach would be to mandate that options that apply to a given af/safi pair should not be negociated before the af/safi is... There really is no reason to send an ORF for an address family that is not enabled on the session.... if the peers support dynamic negociation of address families then these capabities can be negociated afterwards... Pedro. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA08022 for ; Wed, 13 Feb 2002 13:11:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A3EA1912BF; Wed, 13 Feb 2002 13:11:20 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71823912C0; Wed, 13 Feb 2002 13:11:20 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 51314912BF for ; Wed, 13 Feb 2002 13:11:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3579D5DDDC; Wed, 13 Feb 2002 13:11:19 -0500 (EST) Delivered-To: idr@merit.edu Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by segue.merit.edu (Postfix) with ESMTP id 889C65DDDB for ; Wed, 13 Feb 2002 13:11:17 -0500 (EST) Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.50 2002/02/08 23:45:02 root Exp $) with SMTP id SAA09418 for ; Wed, 13 Feb 2002 18:11:12 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002021310120011423 for ; Wed, 13 Feb 2002 10:12:00 -0800 Received: from alpha.igk.intel.com ([172.28.168.68]) by fmsmsx29.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1YPHYZB2; Wed, 13 Feb 2002 10:11:12 -0800 Received: by alpha.igk.intel.com with Internet Mail Service (5.5.2653.19) id <4L8KFSA3>; Wed, 13 Feb 2002 19:10:49 +0100 Message-ID: <413FBB0BA5AED1119122000083234B1A015A92E6@alpha.igk.intel.com> From: "Fryczke, Pawel" To: "'idr@merit.edu'" Subject: Route refresh question Date: Wed, 13 Feb 2002 19:10:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-2" Sender: owner-idr@merit.edu Precedence: bulk I couldn't find in RFC2918 how BGP router should behave in scenario described below. Scenario: 1. Router_A and Router_B are BGP peers. Router_B advertises several prefixes to Router_A. 2. Router_A sends RR message to Router_B (because of export policy reconfiguration) 3. Router_B re-advertises its adj-RIB-out and replies with several UPDATE messages. These updates does not include few prefixes advertised to router_A before RR message was sent (because of policy change) How does the Router_A know about missing prefixes? Note that these prefixes must be withdrawn from Loc-Rib How does the Router_A know that re-advertisement is finished and it won't receive any other UPDATE messages in response to originated RR message ? Withdrawing all received prefixes from Loc-Rib before sending RR does not make any sense. Any comments ? Pawel Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA07036 for ; Wed, 13 Feb 2002 12:25:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3B87E91243; Wed, 13 Feb 2002 12:25:19 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B63B912B6; Wed, 13 Feb 2002 12:25:18 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DCFB991243 for ; Wed, 13 Feb 2002 12:25:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id B4EC45DDDA; Wed, 13 Feb 2002 12:25:17 -0500 (EST) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 64CC45DDD9 for ; Wed, 13 Feb 2002 12:25:17 -0500 (EST) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g1DHPC698031; Wed, 13 Feb 2002 09:25:12 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200202131725.g1DHPC698031@merlot.juniper.net> To: "Shah, VJ" Cc: "'idr@merit.edu'" Subject: Re: Clarficiation required on ID - Cooperative Route Filtering Ca pabi lity for BGP-4 In-Reply-To: Your message of "Wed, 13 Feb 2002 11:47:46 EST." <9BF027DAD859D511A383000347713E20263F01@uniwest2.it.west.unispherenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <41834.1013621111.1@juniper.net> Date: Wed, 13 Feb 2002 09:25:12 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk VJ, > Thanks for your reply. > Just to clarify my understanding of your notes, you are saying that: > > It is legal to send the an OPEN message as follows: > capability multi-protocol: ipv4-unicast > capability orf: prefix-list both ipv4-multicast > > And this implicitly means that we support the ipv4-mutlicast > address family, so it would be the exact same thing as > sending an OPEN message as follows: > capability multi-protocol: ipv4-unicast + ipv4-multicast > capability orf: prefix-list both ipv4-multicast That is correct. > Also, it is legal to subsequently send a CAPABILITY message > as follows: > capability orf: prefix-list both ipv6-unicast > > and this implicitly means we support the ipv6-unicast > address family so it means the exact same thing as sending > a CAPABILITY message as follows: > capability multi-protocol: ipv6-unicast > capability orf: prefix-list both ipv6-unicast > > Finally, if the remote peer currently does not support > the ipv6-unicast address family, we still expect it to remember > our orf capability advertisement so that it will be used > when the ipv6-unicast address family is turned on on the > remote peer (without us re-advertising it). I think that this part of your message is related the dynamic capabilities. So, I would like the authors of the dynamic capabilities draft to answer this. Yakov. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA06217 for ; Wed, 13 Feb 2002 11:52:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A7FD6912B4; Wed, 13 Feb 2002 11:51:48 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 79C30912B5; Wed, 13 Feb 2002 11:51:48 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9A5C4912B4 for ; Wed, 13 Feb 2002 11:51:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7F13B5DDDA; Wed, 13 Feb 2002 11:51:47 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailwest2.unispherenetworks.com (unknown [65.194.140.146]) by segue.merit.edu (Postfix) with ESMTP id 4A60D5DDD9 for ; Wed, 13 Feb 2002 11:51:47 -0500 (EST) Received: by uniwest2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id <1JN8YPGP>; Wed, 13 Feb 2002 11:47:55 -0500 Message-ID: <9BF027DAD859D511A383000347713E20263F01@uniwest2.it.west.unispherenetworks.com> From: "Shah, VJ" To: "'Yakov Rekhter'" Cc: "'idr@merit.edu'" Subject: RE: Clarficiation required on ID - Cooperative Route Filtering Ca pabi lity for BGP-4 Date: Wed, 13 Feb 2002 11:47:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk Yakov, Thanks for your reply. Just to clarify my understanding of your notes, you are saying that: It is legal to send the an OPEN message as follows: capability multi-protocol: ipv4-unicast capability orf: prefix-list both ipv4-multicast And this implicitly means that we support the ipv4-mutlicast address family, so it would be the exact same thing as sending an OPEN message as follows: capability multi-protocol: ipv4-unicast + ipv4-multicast capability orf: prefix-list both ipv4-multicast Also, it is legal to subsequently send a CAPABILITY message as follows: capability orf: prefix-list both ipv6-unicast and this implicitly means we support the ipv6-unicast address family so it means the exact same thing as sending a CAPABILITY message as follows: capability multi-protocol: ipv6-unicast capability orf: prefix-list both ipv6-unicast Finally, if the remote peer currently does not support the ipv6-unicast address family, we still expect it to remember our orf capability advertisement so that it will be used when the ipv6-unicast address family is turned on on the remote peer (without us re-advertising it). VJ > > VJ, > > > Reference: draft-ietf-idr-route-filter-05.txt > > The draft does not specify whether a BGP peer is allowed to > advertise ORF > > capability for a particular when that SAFI> capability has > > not been advertised by the remote peer during > Multi-protocol capability > > negotiation. > > > What is the expected behavior? > > Should there be an explicit restriction in the draft saying > that "Do not > > advertise ORF capability for a for which > capability has not been > > agreed upon". > > AND > > Remote peer should ignore (i.e. throw away the information) > ORF capability > > advertisements for all address families that have not been > negotiated > > OR > > Remote peer is expected to retain the ORF capability > advertisement for the > > address family which has not been negotiated and is > expected to use it if > > and when it is configured with that particular address family. > > Please note that the ORF capability (just like any other capability) > is advertised in the OPEN message, and a BGP speaker may send an > OPEN message to a peer *without* waiting for the OPEN message from > the peer. > > Also note that when a BGP speaker advertises the ORF capability > with a particular , that implies that the speaker supports > routes with that NLRI. > > Yakov. > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA03319 for ; Wed, 13 Feb 2002 09:55:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 74D9291240; Wed, 13 Feb 2002 09:55:20 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4ADD1912A5; Wed, 13 Feb 2002 09:55:20 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 222A791240 for ; Wed, 13 Feb 2002 09:55:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id F3E805DDD3; Wed, 13 Feb 2002 09:55:18 -0500 (EST) Delivered-To: idr@merit.edu Received: from community9.interfree.it (unknown [213.158.72.64]) by segue.merit.edu (Postfix) with SMTP id DB7F85DDD2 for ; Wed, 13 Feb 2002 09:55:17 -0500 (EST) Received: (qmail 29685 invoked by uid 320); 13 Feb 2002 14:53:57 -0000 Date: 13 Feb 2002 14:53:57 -0000 Message-ID: <20020213145357.29684.qmail@community9.interfree.it> From: andrea403@interfree.it () Reply-To: andrea403@interfree.it To: idr@merit.edu Subject: NEXT HOP ATTRIBUTE Sender: owner-idr@merit.edu Precedence: bulk In the rfc1771 I read that in a IBGP session BGP routers can't change the NEXT HOP ATTRIBUTE. I query a Looking Glasses with "show ip bgp prefix" command. This is the output: ....... 7660 22388 11537 9010 137, (aggregated by 137 193.206.129.252) 202.241.2.100 (metric 4) from 202.241.2.100 (202.241.2.100) Origin IGP, localpref 90, valid, internal, atomic-aggregate, best Community: 756091333 ......... This route was redistribuited from a internal BGP router, but the NEXT HOP attribute and the IP of advertisor are the same and there are in the same AS of the Looking GLass. Why a IGBP router have changed the NEXT HOP attribute in a IBGP session? Thankyou Andrea Monaco ----------------------------------------------------- Salve, il messaggio che hai ricevuto è stato inviato per mezzo del sistema di web mail interfree. Se anche tu vuoi una casella di posta free visita il sito http://club.interfree.it Ti aspettiamo! ----------------------------------------------------- Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA03096 for ; Wed, 13 Feb 2002 09:42:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DD96D9123B; Wed, 13 Feb 2002 09:42:16 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94B8291240; Wed, 13 Feb 2002 09:42:16 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0D06B9123B for ; Wed, 13 Feb 2002 09:42:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id DCB245DDD2; Wed, 13 Feb 2002 09:42:14 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailwest.unispherenetworks.com (unknown [65.194.140.130]) by segue.merit.edu (Postfix) with ESMTP id AA9485DDA9 for ; Wed, 13 Feb 2002 09:42:14 -0500 (EST) Received: by uniwest1.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id <1J3BX80D>; Wed, 13 Feb 2002 09:42:12 -0500 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C02E7E59F@uniwest1.it.west.unispherenetworks.com> From: "Rijsman, Bruno" To: "'idr@merit.edu'" Cc: "'Enke Chen'" Subject: Error handling for dynamic capabilities negotiation Date: Wed, 13 Feb 2002 09:42:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk I noticed that the dynamic capabilities draft does not specify what should be done when a malformed CAPABILITY message is received. Here is some suggested text to address this issue: X. Error handling. A new NOTIFICATION error code is defined: 7 CAPABILITY Message Error which has the following error subcodes: 1 Invalid capability action 2 Invalid capability length 3 Invalid capability data If the action field of a capability tuple in a received CAPABILITY message is not 0 or 1, then a NOTIFICATION with error subcode "invalid capability action " MUST be sent and the data field of the NOTIFICATION MUST contain the offending capability tuple. If the length field of a capability tuple in a received CAPABILITY message is illegal (e.g. it exceeds the total length of the message), then a NOTIFICATION with error subcode "invalid capability length" MUST be sent and the data field of the NOTIFICATION MUST contain the action and length fields of the offending capability tuple. If the data field of a capability tuple in a received CAPABILITY message is illegal (the definition of illegal depends on the capability code), then a NOTIFICATION with error subcode "invalid capability data" MUST be sent and the data field of the NOTIFICATION MUST contain the offending capability tuple. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA26818 for ; Wed, 13 Feb 2002 04:53:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B9D23912A0; Wed, 13 Feb 2002 04:53:10 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F62F912A1; Wed, 13 Feb 2002 04:53:10 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5F04A912A0 for ; Wed, 13 Feb 2002 04:53:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3C80C5DDD2; Wed, 13 Feb 2002 04:53:09 -0500 (EST) Delivered-To: idr@merit.edu Received: from web14913.mail.yahoo.com (web14913.mail.yahoo.com [216.136.225.240]) by segue.merit.edu (Postfix) with SMTP id B48215DDA1 for ; Wed, 13 Feb 2002 04:53:08 -0500 (EST) Message-ID: <20020213095308.79251.qmail@web14913.mail.yahoo.com> Received: from [203.200.20.226] by web14913.mail.yahoo.com via HTTP; Wed, 13 Feb 2002 01:53:08 PST Date: Wed, 13 Feb 2002 01:53:08 -0800 (PST) From: Manav Bhatia Subject: Re: Questions about dynamic capability negotiation To: idr@merit.edu Cc: roque@juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Hi Pedro, | Router A does not need to send a refresh request if has an | Adj-Rib-In... It may simply process configuration as a local matter, | even if it does support refresh. Depends. Most of the implementations out there in the field maintain a separate Adj-Rib-In per peer and thus implicitly support soft reconfig. But this does not stop them from using and negotiating RR capability. It can so happen that the user generally uses "clear ip bgp in/out" causing RR messages to be sent to the remote peer. To reduce the load he may then resort to "clear ip bgp soft in/out". It sounds unlikely that a sys admin will do this but the underlying protocol should be capable enough to support this eventuality. | | Refresh capability is really a capability of the software | implementation rather than a configured object, imho. very true. But the user has been left with the option to use this OR the other method to soft reconfigure his inbound/outbound updates. Regards, Manav | | Some of the capabilities being considered for dynamic negociation have | some interesting corner cases that really make me wonder how much the | operations community cares about them... | | Having a session negotiating its configuration parameters on the fly | has a few potential drawbacks when it comes to diagnosing | problems. Perhaps this is one of those issues where it would be best | to apply the KISS principle... | | Pedro. __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA26417 for ; Wed, 13 Feb 2002 04:33:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CE9549129E; Wed, 13 Feb 2002 04:32:05 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D23B912A0; Wed, 13 Feb 2002 04:32:05 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B340A9129E for ; Wed, 13 Feb 2002 04:32:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8F0985DDA9; Wed, 13 Feb 2002 04:32:03 -0500 (EST) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 3A51E5DDA1 for ; Wed, 13 Feb 2002 04:32:03 -0500 (EST) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g1D9W2683972; Wed, 13 Feb 2002 01:32:02 -0800 (PST) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g1D9W2809857; Wed, 13 Feb 2002 01:32:02 -0800 (PST) (envelope-from roque) Date: Wed, 13 Feb 2002 01:32:02 -0800 (PST) Message-Id: <200202130932.g1D9W2809857@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Manav Bhatia Cc: idr@merit.edu, enke@redback.com, BRijsman@unispherenetworks.com Subject: Re: Questions about dynamic capability negotiation In-Reply-To: <20020213064145.75465.qmail@web14904.mail.yahoo.com> References: <20020213064145.75465.qmail@web14904.mail.yahoo.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Manav Bhatia writes: > Hi Enke, > | Does it make sense to make the ROUTE-REFRESH capability dynamic? > Yesterday i was too thinking the same but it then later struck me > that we can indeed have a situation in which a user *might* want to > withdraw the ROUTE-REFRESH capability. > Say A peers up with B negotiating RR capability. If A is changing > his policies frequently (he might be testing/configuring or doing > something!) then each time he does that he will send a RR message to > B requesting for fresh updates. > This can considerably increase the traffic on the links. If A's > implementation supports separate Adj-Rib-In per peer then he can as > well do a soft reconfiguration by running the Decision process over > the routes stored in Adj-Rib-In without congesting its links. Router A does not need to send a refresh request if has an Adj-Rib-In... It may simply process configuration as a local matter, even if it does support refresh. Refresh capability is really a capability of the software implementation rather than a configured object, imho. Some of the capabilities being considered for dynamic negociation have some interesting corner cases that really make me wonder how much the operations community cares about them... Having a session negotiating its configuration parameters on the fly has a few potential drawbacks when it comes to diagnosing problems. Perhaps this is one of those issues where it would be best to apply the KISS principle... Pedro. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA22013 for ; Wed, 13 Feb 2002 01:42:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9D18D9123A; Wed, 13 Feb 2002 01:41:47 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F35E91296; Wed, 13 Feb 2002 01:41:47 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5286D9123A for ; Wed, 13 Feb 2002 01:41:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 35C2A5DDD2; Wed, 13 Feb 2002 01:41:46 -0500 (EST) Delivered-To: idr@merit.edu Received: from web14904.mail.yahoo.com (web14904.mail.yahoo.com [216.136.225.56]) by segue.merit.edu (Postfix) with SMTP id ADA9C5DDA4 for ; Wed, 13 Feb 2002 01:41:45 -0500 (EST) Message-ID: <20020213064145.75465.qmail@web14904.mail.yahoo.com> Received: from [203.200.20.226] by web14904.mail.yahoo.com via HTTP; Tue, 12 Feb 2002 22:41:45 PST Date: Tue, 12 Feb 2002 22:41:45 -0800 (PST) From: Manav Bhatia Subject: Re: Questions about dynamic capability negotiation To: idr@merit.edu Cc: enke@redback.com, BRijsman@unispherenetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Hi Enke, | Does it make sense to make the ROUTE-REFRESH capability dynamic? Yesterday i was too thinking the same but it then later struck me that we can indeed have a situation in which a user *might* want to withdraw the ROUTE-REFRESH capability. Say A peers up with B negotiating RR capability. If A is changing his policies frequently (he might be testing/configuring or doing something!) then each time he does that he will send a RR message to B requesting for fresh updates. This can considerably increase the traffic on the links. If A's implementation supports separate Adj-Rib-In per peer then he can as well do a soft reconfiguration by running the Decision process over the routes stored in Adj-Rib-In without congesting its links. In such a scenario the system admin may wish to temporarily suspend his RR capability so that in the subsequent soft reconfigs the network is not flooded with UPDATEs from the peer. Please correct me if i am missing some point. Manav __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA21661 for ; Wed, 13 Feb 2002 01:30:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1900491212; Wed, 13 Feb 2002 01:29:43 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D904191296; Wed, 13 Feb 2002 01:29:42 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 93D2291212 for ; Wed, 13 Feb 2002 01:29:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6D6B45DDD2; Wed, 13 Feb 2002 01:29:41 -0500 (EST) Delivered-To: idr@merit.edu Received: from web14912.mail.yahoo.com (web14912.mail.yahoo.com [216.136.225.248]) by segue.merit.edu (Postfix) with SMTP id E3FBB5DD9B for ; Wed, 13 Feb 2002 01:29:40 -0500 (EST) Message-ID: <20020213062940.35695.qmail@web14912.mail.yahoo.com> Received: from [203.200.20.226] by web14912.mail.yahoo.com via HTTP; Tue, 12 Feb 2002 22:29:40 PST Date: Tue, 12 Feb 2002 22:29:40 -0800 (PST) From: Manav Bhatia Subject: RE: Dynamic Capability negotiation - 4byte AS To: idr@merit.edu Cc: BRijsman@unispherenetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk This removes all the ambiguities frlom the draft. what do others say? Manav ----- Original Message ----- From: "Rijsman, Bruno" To: "'Manav Bhatia'" Cc: Sent: Wednesday, February 13, 2002 12:58 AM Subject: RE: Dynamic Capability negotiation - 4byte AS Hi Manay, I basically agree with both of your last two e-mails. I'd like to suggest that the authors of the draft add some more precise language to the dynamic-capability draft to formalize the various cases. I've given a shot at the wording below: 1. Four-octet-as-numbers capability The four-octet-as-numbers capability can not be dynamically negotiated. A BGP speaker MUST NOT send a CAPABILITIES message containing capability code four-octet-as-numbers. A BGP speaker MUST ignore received CAPABILITIES messages containing capability code four-octet-as-numbers. 2. Dynamic-capability-negotiation capability The dynamic-capability-negotiation capability can not be dynamically negotiated. A BGP speaker MUST NOT send a CAPABILITIES message containing capability code dynamic-capability-negotiation. A BGP speaker MUST ignore received CAPABILITIES messages containing capability dynamic-capability-negotiation. 3. Route-refresh capability The route-refresh capability can be dynamically negotiated. It is possible that a) a CAPABILITIES message with contents "remove capability route-refresh" from peer A to peer B and b) a ROUTE-REFRESH message from peer B to peer A cross each other if sent almost simultaniously by both peers. For this reason, a peer which has sent a a CAPABILITIES message with contents "remove capability route-refresh" MUST be prepared to receive ROUTE-REFRESH messages and MUST react to them in the usual fashion (i.e. by re-sending the RIB-out). Once a peer has sent a a CAPABILITIES message with contents "remove capability route-refresh" it MUST NOT send any ROUTE-REFRESH messages until the route-refresh capability is re-advertised using another CAPABILITIES message. 4. Multi-protocol capability The multi-protocol capability can be dynamically negotiated. It is possible that a) a CAPABILITIES message with contents "remove capability multi-protocol for a given AFI/SAFI" from peer A to peer B and b) an UPDATE or a ROUTE-REFRESH message for that same AFI/SAFI from peer B to peer A cross each other if sent almost simultaniously by both peers. For this reason, a peer which has sent a a CAPABILITIES message with contents "remove capability multi-protocol for a given AFI/SAFI": · MUST be prepared to receive UPDATE messages for that same AFI/SAFI and MUST ignore them. · MUST be prepared to receive ROUTE-REFRESH messages for that same AFI/SAFI and MUST ignore them. Once a peer has sent a a CAPABILITIES message with contents "remove capability multi-protocol for a given AFI/SAFI" it MUST NOT send any UPDATE or ROUTE-REFRESH messages for that AFI/SAFI until the multi-protocol capability is re-advertised for that AFI/SAFI using another CAPABILITIES message. 5. ORF capability < Add a section here as well > 6. Future capabilities Future RFCs describing new capabilities must include a section describing whether or not the capability can be dynamically negotiated, and establish procedures for dealing with situations where the CAPABILITIES message collides with a message influenced by that capability. __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA16771 for ; Tue, 12 Feb 2002 21:58:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E151291239; Tue, 12 Feb 2002 21:58:11 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A91F991296; Tue, 12 Feb 2002 21:58:11 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A5BC91239 for ; Tue, 12 Feb 2002 21:58:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 54D895DDC7; Tue, 12 Feb 2002 21:58:10 -0500 (EST) Delivered-To: idr@merit.edu Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 11AD25DDB0 for ; Tue, 12 Feb 2002 21:58:10 -0500 (EST) Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 3FF031DCC69; Tue, 12 Feb 2002 18:58:09 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id 265F47E6C1; Tue, 12 Feb 2002 18:58:07 -0800 (PST) To: "Rijsman, Bruno" Cc: "'idr@merit.edu'" , enke@redback.com Subject: Re: Questions about dynamic capability negotiation In-Reply-To: Message from "Rijsman, Bruno" of "Mon, 11 Feb 2002 17:22:08 EST." <49FF5C6DDBD8D311BBBD009027DE980C02E7E58A@uniwest1.it.west.unispherenetworks.com> Date: Tue, 12 Feb 2002 18:58:07 -0800 From: Enke Chen Message-Id: <20020213025808.265F47E6C1@popserv3.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Bruno: > From: "Rijsman, Bruno" > To: "'idr@merit.edu'" > Subject: Questions about dynamic capability negotiation > Date: Mon, 11 Feb 2002 17:22:08 -0500 > > > I have some questions about dynamic capability negotiation: > > > > 1. What should a BGP speaker do when some event occurs that > > is not legal given the current state of negotiated > > capabilities, e.g: > > > > 1a) A route-refresh message is received after a > > capability message removing the route-refresh > > capability has been sent. > > > > 1b) An ipv4-multicast update is received after a > > capability message removing the multi-protocol > > capability for ipv4-multicast has been sent. > > > > Note that the above two situations can occur without > > either side violating the protocol as is demonstrated > > by the following example: > > > > A B > > | | > > | OPEN | > > | cap. routee-refresh | > > |........................>| > > | | > > | | > > | CAPABILITY | > > | remove route-refresh | > > |... | > > | ... ....| > > | ... .... | > > | ... .... | > > | ...... | > > | .... ... | > > (X)|<.... ... | > > | ROUTE-REFRESH ...>| > > | | > > > > What should A do at time (X) ? > > > > I see 3 possibilities: > > > > i) ignore the route-refresh: not good because > > B will not get the UPDATEs it requested > > (and B has no indication anything is wrong) > > > > ii) send a notification: not good because > > now the session is aborted although neither > > side did anything illegal > > > > iii) process the route refresh (i.e. send the > > RIB-out again): in that case what is the > > point of removing the route-refresh > > capability? You raises a good question in iii), and it might be the answer to your original question :-) Does it make sense to make the ROUTE-REFRESH capability dynamic? Regarding your question on 1b), the issue can occur without dynamic capability (that is, receiving an update for an Address Family that you have not advertised). > > > > It seems to me that there is no single answer > > that can apply to all capabilities and each > > capability should specify: > > > > A) Whether or not dynamic capability negotiation > > is legal, and if so > > > > B) What to do in case of collisions as shown > > above. > > > > 2. What should a BGP speaker do when it receives an illegal > > capability message, e.g. a capability message with > > capability code dynamic-capability-negotiation or > > four-octet-as-numbers. > > > > Keep in mind that the draft already specifies that > > capability messages with an unknown capability code > > must be ignored (so, if the answer is: send a notification > > we get inconsistent behavior between peer which know > > and peers which don't know a certain capability). There is certainly a difference between "Illegal capability" and "unknown capability". For the former, I think the action should depend on whether the message causes any harm. -- Enke Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA14128 for ; Tue, 12 Feb 2002 19:51:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 21C2291236; Tue, 12 Feb 2002 19:51:03 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E7EB091237; Tue, 12 Feb 2002 19:51:02 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9E9F991236 for ; Tue, 12 Feb 2002 19:51:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7C0A45DDB0; Tue, 12 Feb 2002 19:51:01 -0500 (EST) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 2C1C55DDA4 for ; Tue, 12 Feb 2002 19:51:01 -0500 (EST) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g1D0ox667844; Tue, 12 Feb 2002 16:50:59 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200202130050.g1D0ox667844@merlot.juniper.net> To: "Shah, VJ" Cc: "'idr@merit.edu'" Subject: Re: Clarficiation required on ID - Cooperative Route Filtering Capabi lity for BGP-4 In-Reply-To: Your message of "Tue, 12 Feb 2002 10:35:20 EST." <9BF027DAD859D511A383000347713E20263EF9@uniwest2.it.west.unispherenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <74553.1013561459.1@juniper.net> Date: Tue, 12 Feb 2002 16:50:59 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk VJ, > Reference: draft-ietf-idr-route-filter-05.txt > The draft does not specify whether a BGP peer is allowed to advertise ORF > capability for a particular when that capability has > not been advertised by the remote peer during Multi-protocol capability > negotiation. > What is the expected behavior? > Should there be an explicit restriction in the draft saying that "Do not > advertise ORF capability for a for which capability has not been > agreed upon". > AND > Remote peer should ignore (i.e. throw away the information) ORF capability > advertisements for all address families that have not been negotiated > OR > Remote peer is expected to retain the ORF capability advertisement for the > address family which has not been negotiated and is expected to use it if > and when it is configured with that particular address family. Please note that the ORF capability (just like any other capability) is advertised in the OPEN message, and a BGP speaker may send an OPEN message to a peer *without* waiting for the OPEN message from the peer. Also note that when a BGP speaker advertises the ORF capability with a particular , that implies that the speaker supports routes with that NLRI. Yakov. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA06545 for ; Tue, 12 Feb 2002 14:28:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DA4069128E; Tue, 12 Feb 2002 14:28:33 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9DB199128F; Tue, 12 Feb 2002 14:28:33 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 365209128E for ; Tue, 12 Feb 2002 14:28:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 063765DDC0; Tue, 12 Feb 2002 14:28:32 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailwest.unispherenetworks.com (unknown [65.194.140.130]) by segue.merit.edu (Postfix) with ESMTP id C67E65DDB0 for ; Tue, 12 Feb 2002 14:28:31 -0500 (EST) Received: by uniwest1.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id <1J3BX74A>; Tue, 12 Feb 2002 14:28:31 -0500 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C02E7E596@uniwest1.it.west.unispherenetworks.com> From: "Rijsman, Bruno" To: "'Manav Bhatia'" Cc: "'idr@merit.edu'" Subject: RE: Dynamic Capability negotiation - 4byte AS Date: Tue, 12 Feb 2002 14:28:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id OAA06545 Hi Manay, I basically agree with both of your last two e-mails. I'd like to suggest that the authors of the draft add some more precise language to the dynamic-capability draft to formalize the various cases. I've given a shot at the wording below: 1. Four-octet-as-numbers capability The four-octet-as-numbers capability can not be dynamically negotiated. A BGP speaker MUST NOT send a CAPABILITIES message containing capability code four-octet-as-numbers. A BGP speaker MUST ignore received CAPABILITIES messages containing capability code four-octet-as-numbers. 2. Dynamic-capability-negotiation capability The dynamic-capability-negotiation capability can not be dynamically negotiated. A BGP speaker MUST NOT send a CAPABILITIES message containing capability code dynamic-capability-negotiation. A BGP speaker MUST ignore received CAPABILITIES messages containing capability dynamic-capability-negotiation. 3. Route-refresh capability The route-refresh capability can be dynamically negotiated. It is possible that a) a CAPABILITIES message with contents "remove capability route-refresh" from peer A to peer B and b) a ROUTE-REFRESH message from peer B to peer A cross each other if sent almost simultaniously by both peers. For this reason, a peer which has sent a a CAPABILITIES message with contents "remove capability route-refresh" MUST be prepared to receive ROUTE-REFRESH messages and MUST react to them in the usual fashion (i.e. by re-sending the RIB-out). Once a peer has sent a a CAPABILITIES message with contents "remove capability route-refresh" it MUST NOT send any ROUTE-REFRESH messages until the route-refresh capability is re-advertised using another CAPABILITIES message. 4. Multi-protocol capability The multi-protocol capability can be dynamically negotiated. It is possible that a) a CAPABILITIES message with contents "remove capability multi-protocol for a given AFI/SAFI" from peer A to peer B and b) an UPDATE or a ROUTE-REFRESH message for that same AFI/SAFI from peer B to peer A cross each other if sent almost simultaniously by both peers. For this reason, a peer which has sent a a CAPABILITIES message with contents "remove capability multi-protocol for a given AFI/SAFI": · MUST be prepared to receive UPDATE messages for that same AFI/SAFI and MUST ignore them. · MUST be prepared to receive ROUTE-REFRESH messages for that same AFI/SAFI and MUST ignore them. Once a peer has sent a a CAPABILITIES message with contents "remove capability multi-protocol for a given AFI/SAFI" it MUST NOT send any UPDATE or ROUTE-REFRESH messages for that AFI/SAFI until the multi-protocol capability is re-advertised for that AFI/SAFI using another CAPABILITIES message. 5. ORF capability < Add a section here as well > 6. Future capabilities Future RFCs describing new capabilities must include a section describing whether or not the capability can be dynamically negotiated, and establish procedures for dealing with situations where the CAPABILITIES message collides with a message influenced by that capability. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA01138 for ; Tue, 12 Feb 2002 10:39:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EC9B391233; Tue, 12 Feb 2002 10:39:18 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B890591234; Tue, 12 Feb 2002 10:39:18 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CEB2191233 for ; Tue, 12 Feb 2002 10:39:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id B4CE85DDB4; Tue, 12 Feb 2002 10:39:17 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailwest2.unispherenetworks.com (unknown [65.194.140.146]) by segue.merit.edu (Postfix) with ESMTP id 8302B5DDA4 for ; Tue, 12 Feb 2002 10:39:17 -0500 (EST) Received: by uniwest2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id <1JN8Y3BG>; Tue, 12 Feb 2002 10:35:27 -0500 Message-ID: <9BF027DAD859D511A383000347713E20263EF9@uniwest2.it.west.unispherenetworks.com> From: "Shah, VJ" To: "'idr@merit.edu'" Subject: Clarficiation required on ID - Cooperative Route Filtering Capabi lity for BGP-4 Date: Tue, 12 Feb 2002 10:35:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk Reference: draft-ietf-idr-route-filter-05.txt The draft does not specify whether a BGP peer is allowed to advertise ORF capability for a particular when that capability has not been advertised by the remote peer during Multi-protocol capability negotiation. What is the expected behavior? Should there be an explicit restriction in the draft saying that "Do not advertise ORF capability for a for which capability has not been agreed upon". AND Remote peer should ignore (i.e. throw away the information) ORF capability advertisements for all address families that have not been negotiated OR Remote peer is expected to retain the ORF capability advertisement for the address family which has not been negotiated and is expected to use it if and when it is configured with that particular address family. VJ Shah Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA29694 for ; Tue, 12 Feb 2002 10:01:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BAA1791287; Tue, 12 Feb 2002 10:00:14 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 873EF91284; Tue, 12 Feb 2002 10:00:13 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F194791282 for ; Tue, 12 Feb 2002 10:00:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id E91C65DDD1; Tue, 12 Feb 2002 10:00:07 -0500 (EST) Delivered-To: idr@merit.edu Received: from web14909.mail.yahoo.com (web14909.mail.yahoo.com [216.136.225.61]) by segue.merit.edu (Postfix) with SMTP id 5AEF85DDB4 for ; Tue, 12 Feb 2002 10:00:07 -0500 (EST) Message-ID: <20020212145936.79051.qmail@web14909.mail.yahoo.com> Received: from [203.200.20.226] by web14909.mail.yahoo.com via HTTP; Tue, 12 Feb 2002 06:59:36 PST Date: Tue, 12 Feb 2002 06:59:36 -0800 (PST) From: Manav Bhatia Subject: Re: Questions about dynamic capability negotiation - RR To: BRijsman@unispherenetworks.com Cc: idr@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk | >>> Are we going to try to fix this problem using | >>> some kind of ACK mechanism? Personally I would | >>> vote against an ACK mechanism because it opens | >>> a whole new can of worms. But maybe there is | >>> another solution? There is a solution. I guess we must follow one general rule which says that we must do whatever is necessary to remove the effect of the previous announcement of the capability which is now being removed by the peer. We must also look at this is in a different light. Why, a peer which previously announced RR capability is removing it? It means that this peer "supports" RR messages (in effect understands them).. but its only now that it doesn't feel like accepting more from its remote peer. If it sends out a dynamic request stating to withdraw this capability and if in mean time it recieves a RR packet it should process it as it normally does! The example which you produced can only happen in *certain* critical cases when there is almost no time gap between a peer's sending of dynamic capability and the remote end's sending of a RR message. The peer receiving the RR message (one which wants to withdraw this capability) must understand that the remote peer has not yet receieved its withdrawal request and that it must process the RR request. It MUST in turn never send a RR message to the remote peer. In a correct implementation the remote peer upon receiving the dynamic request will never again send a RR message to this peer. This obviates the need for sending ACKs, NOTIFICATIONs, etc. and appears as the most generic and a simple solution with complicating the thngs. What do the others feel? Regards, Manav Bhatia __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA28291 for ; Tue, 12 Feb 2002 08:55:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A3B7B9127F; Tue, 12 Feb 2002 08:54:50 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F74F91280; Tue, 12 Feb 2002 08:54:50 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 100E19127F for ; Tue, 12 Feb 2002 08:54:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id EAF2A5DDB7; Tue, 12 Feb 2002 08:54:48 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailwest.unispherenetworks.com (unknown [65.194.140.130]) by segue.merit.edu (Postfix) with ESMTP id B8C085DDB4 for ; Tue, 12 Feb 2002 08:54:48 -0500 (EST) Received: by uniwest1.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id <1J3BX7BW>; Tue, 12 Feb 2002 08:54:48 -0500 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C02E7E58F@uniwest1.it.west.unispherenetworks.com> From: "Rijsman, Bruno" To: "'Manav Bhatia'" Cc: "'idr@merit.edu'" Subject: RE: Questions about dynamic capability negotiation - RR Date: Tue, 12 Feb 2002 08:54:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk See >>> below -----Original Message----- From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] Sent: Tuesday, February 12, 2002 8:41 AM To: idr@merit.edu Cc: Rijsman, Bruno Subject: RE: Questions about dynamic capability negotiation - RR Bruno, | Let me describe the scenario in text: | | 1. A sends OPEN to B with route-refresh capability | | 2. (some time passes) | | 3. A sends some UPDATEs to B Before this can happen , B must have also sent an OPEN message with OR without RR capability support. If B supports RR then both the peers shall support RR OR else none of them shall support RR. >>> Yes, for brevity's sake I skipped the other >>> OPEN and the KEEP-ALIVEs since they were not >>> relevant to the example. | | 4. (some time passes) | | 5. A sends a CAPABILITY message to B to remove the route-refresh | capability. After the BGP session has gone up !?!? Okay .. so you're talking of dynamic capabilities >>> Yes, I was talking about dynamic capabilities here coz this can happen ONLY if both peers agree to peer up using dynamic capabilities. The draft by Enke clearly states that this feature may not be feasible for all the capabilities. RR then happens to be one of them. OR an ACK scheme must be included in the draft which informs the remote peer that the Dynamic Capability message has been received and that it can now act upon it. This will avoid the scenario which you just explained. >>> That is the heart of the matter. >>> Are we going to try to fix this problem using >>> some kind of ACK mechanism? Personally I would >>> vote against an ACK mechanism because it opens >>> a whole new can of worms. But maybe there is >>> another solution? >>> Or, are we going to declare lots of capabilities >>> as "not dynamically negotiable"? If so, we should >>> define precisely what should be done when an >>> CAPABILITY message for a non-negotiable capability >>> is received (notification vs ignore or maybe some >>> bits in the capability message indicating what to >>> do). >>> Also, if we are going down the latter path (i.e. >>> declaring certain capabilities as non-negotiable), >>> I wonder whether there will be any capabilities >>> left that *can* safely by dynamically negotiated. >>> For example, don't the ORF capabilities have >>> the same problem of a CAPABILITY message and an >>> ORF message crossing each other? And doesn't >>> the multi-protocol capability have the same >>> problem of a CAPABILITY message and an UPDATE >>> message crossing each other? __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA28259 for ; Tue, 12 Feb 2002 08:53:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D84379127E; Tue, 12 Feb 2002 08:52:53 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A617E9127F; Tue, 12 Feb 2002 08:52:53 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4D3BF9127E for ; Tue, 12 Feb 2002 08:52:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 300F75DDB7; Tue, 12 Feb 2002 08:52:51 -0500 (EST) Delivered-To: idr@merit.edu Received: from web14914.mail.yahoo.com (web14914.mail.yahoo.com [216.136.225.241]) by segue.merit.edu (Postfix) with SMTP id A0CE05DDB4 for ; Tue, 12 Feb 2002 08:52:50 -0500 (EST) Message-ID: <20020212135247.77585.qmail@web14914.mail.yahoo.com> Received: from [203.200.20.226] by web14914.mail.yahoo.com via HTTP; Tue, 12 Feb 2002 05:52:47 PST Date: Tue, 12 Feb 2002 05:52:47 -0800 (PST) From: Manav Bhatia Subject: Re: Dynamic Capability negotiation - 4byte AS To: idr@merit.edu Cc: BRijsman@unispherenetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Bruno, Pl. find my comments inline .. | Let's say I'm a BGP speaker which supports the | four-octet-numbers-capability. | | When I receive a CAPABILITY message with capability | code 99 (not yet defined), clearly I should ignore it | because from my point of view it is an "unsupported" | capability. Yes. | | When I receive a CAPABILITY message with capability | code 65, I recognize that code as being | four-octet-as-numbers which is a capability that | I support. However, the dynamic capability draft | specifically says that four-octet-as-numbers cannot | be negotiated dynamically (due to similar problems | as I described above for route-refresh). So, what | should I do when I receive this CAPABILITY message | (which is not unsupported but illegal)? Here you are not negotiating it dynamically. Each peer advertises its capabilities in its OPEN message. This OPEN message when reaches the other end causes the remote peer to see if it supports the capability it just received. If it does then this capability is supported and both the peers use it OR else even if one of the peers doesn't support this then the capability is not used. The draft on dynamic capabilities says that 4 byte AS number capability cannot be dynamically changed i.e if you once advertised it then you cannot discontinue it without disrupting your session once. Hope it helps. ~Manav __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA28028 for ; Tue, 12 Feb 2002 08:41:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2669E91206; Tue, 12 Feb 2002 08:40:48 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC8499127D; Tue, 12 Feb 2002 08:40:47 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C5C5691206 for ; Tue, 12 Feb 2002 08:40:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9D5275DDB7; Tue, 12 Feb 2002 08:40:46 -0500 (EST) Delivered-To: idr@merit.edu Received: from web14906.mail.yahoo.com (web14906.mail.yahoo.com [216.136.225.58]) by segue.merit.edu (Postfix) with SMTP id 193985DDB4 for ; Tue, 12 Feb 2002 08:40:46 -0500 (EST) Message-ID: <20020212134031.42823.qmail@web14906.mail.yahoo.com> Received: from [203.200.20.226] by web14906.mail.yahoo.com via HTTP; Tue, 12 Feb 2002 05:40:31 PST Date: Tue, 12 Feb 2002 05:40:31 -0800 (PST) From: Manav Bhatia Subject: RE: Questions about dynamic capability negotiation - RR To: idr@merit.edu Cc: BRijsman@unispherenetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Bruno, | Let me describe the scenario in text: | | 1. A sends OPEN to B with route-refresh capability | | 2. (some time passes) | | 3. A sends some UPDATEs to B Before this can happen , B must have also sent an OPEN message with OR without RR capability support. If B supports RR then both the peers shall support RR OR else none of them shall support RR. | | 4. (some time passes) | | 5. A sends a CAPABILITY message to B to remove the route-refresh | capability. After the BGP session has gone up !?!? Okay .. so you're talking of dynamic capabilities here coz this can happen ONLY if both peers agree to peer up using dynamic capabilities. The draft by Enke clearly states that this feature may not be feasible for all the capabilities. RR then happens to be one of them. OR an ACK scheme must be included in the draft which informs the remote peer that the Dynamic Capability message has been received and that it can now act upon it. This will avoid the scenario which you just explained. __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA27636 for ; Tue, 12 Feb 2002 08:24:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2658791275; Tue, 12 Feb 2002 08:24:31 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC50F91276; Tue, 12 Feb 2002 08:24:30 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9919091275 for ; Tue, 12 Feb 2002 08:24:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 796005DDB7; Tue, 12 Feb 2002 08:24:29 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailwest.unispherenetworks.com (unknown [65.194.140.130]) by segue.merit.edu (Postfix) with ESMTP id 485A25DDB4 for ; Tue, 12 Feb 2002 08:24:29 -0500 (EST) Received: by uniwest1.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id <1J3BX608>; Tue, 12 Feb 2002 08:24:29 -0500 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C02E7E58E@uniwest1.it.west.unispherenetworks.com> From: "Rijsman, Bruno" To: "'Manav Bhatia'" Cc: "'idr@merit.edu'" Subject: RE: Questions about dynamic capability negotiation Date: Tue, 12 Feb 2002 08:24:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk * | >>> Yes, it can happen with a correct implementation if the CAPABILITY * | >>> message and the ROUTE-REFRESH message cross each other as I showed * | >>> in the example in my original mail. * * The example in your previous mail was not very clear and the figure which i received was * distorted. Can you please explain me the scenario once again wherein the above can happen in * the correct implementation? Let me describe the scenario in text: 1. A sends OPEN to B with route-refresh capability 2. (some time passes) 3. A sends some UPDATEs to B 4. (some time passes) 5. A sends a CAPABILITY message to B to remove the route-refresh capability. 6. *BEFORE* this CAPABILITY message arrives at B, B sends a ROUTE-REFRESH message to A. In other words, the CAPABILITY message and the ROUTE-REFRESH message cross each other (this is possible due to TCP send queues, TCP re-assembly queues, line delays, etc). Note that it is legal for B to send a ROUTE-REFRESH message at this point. 7. A receives the ROUTE-REFRESH message *AFTER* it has already sent a CAPABILITY message to remove the route-refresh capability. The question is: what should A do at this point? A has no way of knowing whether B sent the ROUTE-REFRESH message before or after A sent the CAPABILITY message. * | >>> I'm not talking about an unsupported capability, but a capability * | >>> which is supported but which cannot be negotiated dynamically * | >>> (such as four-octet-as-numbers). * * can you please expound on this? Let's say I'm a BGP speaker which supports the four-octet-numbers-capability. When I receive a CAPABILITY message with capability code 99 (not yet defined), clearly I should ignore it because from my point of view it is an "unsupported" capability. When I receive a CAPABILITY message with capability code 65, I recognize that code as being four-octet-as-numbers which is a capability that I support. However, the dynamic capability draft specifically says that four-octet-as-numbers cannot be negotiated dynamically (due to similar problems as I described above for route-refresh). So, what should I do when I receive this CAPABILITY message (which is not unsupported but illegal)? If your answer is "you should send a notification" you should be aware that this implies that speakers which support four-octet-as-numbers will react differently from speaker which do not support four-octet-as-numbers (send notification vs ignore). I'm not sure whether or not that is a problem. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA27325 for ; Tue, 12 Feb 2002 08:07:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AC6F091274; Tue, 12 Feb 2002 08:07:07 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 784C091275; Tue, 12 Feb 2002 08:07:07 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 57B4891274 for ; Tue, 12 Feb 2002 08:07:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3EE085DDB7; Tue, 12 Feb 2002 08:07:06 -0500 (EST) Delivered-To: idr@merit.edu Received: from web14914.mail.yahoo.com (web14914.mail.yahoo.com [216.136.225.241]) by segue.merit.edu (Postfix) with SMTP id B02965DDB4 for ; Tue, 12 Feb 2002 08:07:05 -0500 (EST) Message-ID: <20020212130657.70723.qmail@web14914.mail.yahoo.com> Received: from [203.200.20.226] by web14914.mail.yahoo.com via HTTP; Tue, 12 Feb 2002 05:06:57 PST Date: Tue, 12 Feb 2002 05:06:57 -0800 (PST) From: Manav Bhatia Subject: RE: Questions about dynamic capability negotiation To: idr@merit.edu Cc: BRijsman@unispherenetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Bruno, | >>> Yes, it can happen with a correct implementation if the CAPABILITY | >>> message and the ROUTE-REFRESH message cross each other as I showed | >>> in the example in my original mail. The example in your previous mail was not very clear and the figure which i received was distorted. Can you please explain me the scenario once again wherein the above can happen in the correct implementation? | >>> I'm not talking about an unsupported capability, but a capability | >>> which is supported but which cannot be negotiated dynamically | >>> (such as four-octet-as-numbers). can you please expound on this? ~Manav __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA26946 for ; Tue, 12 Feb 2002 07:48:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1ED6391273; Tue, 12 Feb 2002 07:48:11 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D8AE991274; Tue, 12 Feb 2002 07:48:10 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6606391273 for ; Tue, 12 Feb 2002 07:47:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 37A7D5DDDA; Tue, 12 Feb 2002 07:47:36 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailwest.unispherenetworks.com (unknown [65.194.140.130]) by segue.merit.edu (Postfix) with ESMTP id DEC815DDE0 for ; Tue, 12 Feb 2002 07:47:35 -0500 (EST) Received: by uniwest1.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id <1J3BX602>; Tue, 12 Feb 2002 07:47:33 -0500 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C02E7E58B@uniwest1.it.west.unispherenetworks.com> From: "Rijsman, Bruno" To: "'Manav Bhatia'" Cc: "'idr@merit.edu'" Subject: RE: Questions about dynamic capability negotiation Date: Tue, 12 Feb 2002 07:47:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk See >>> below -----Original Message----- From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] Sent: Monday, February 11, 2002 11:15 PM To: idr@merit.edu Cc: Rijsman, Bruno Subject: Re: Questions about dynamic capability negotiation Hi Bruno, | > I have some questions about dynamic capability negotiation: | > | > 1. What should a BGP speaker do when some event occurs that | > is not legal given the current state of negotiated | > capabilities, e.g: | > | > 1a) A route-refresh message is received after a | > capability message removing the route-refresh | > capability has been sent. If the implementation is correct then this particular scenario would never arise because even if the user requests a soft reconfig then a route refresh message is ONLY sent if this capability has been negotiated between the two peers. In short, it means that if the two peers have not negotiated on route refresh and even then if one of the peers receive a RR message then it is safe to bring down the session by sending a NOTIFICATION message because we know that the other end is doing something wrong and we no longer want to continue peering with him! A correct implementation will NEVER send a RR message if this capability has NOT been negotiated between the two peers. >>> Yes, it can happen with a correct implementation if the CAPABILITY >>> message and the ROUTE-REFRESH message cross each other as I showed >>> in the example in my original mail. | > 2. What should a BGP speaker do when it receives an illegal | > capability message, e.g. a capability message with | > capability code dynamic-capability-negotiation or | > four-octet-as-numbers. A correct implementation will ignore the unsupported capability code and NOT send a NOTIFICATION message. >>> I'm not talking about an unsupported capability, but a capability >>> which is supported but which cannot be negotiated dynamically >>> (such as four-octet-as-numbers). ~Manav __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA17135 for ; Tue, 12 Feb 2002 01:00:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B0DDE91428; Tue, 12 Feb 2002 00:48:29 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 32495913D8; Tue, 12 Feb 2002 00:39:30 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A0ADE9145A for ; Mon, 11 Feb 2002 23:15:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8004F5DD97; Mon, 11 Feb 2002 23:15:30 -0500 (EST) Delivered-To: idr@merit.edu Received: from web14914.mail.yahoo.com (web14914.mail.yahoo.com [216.136.225.241]) by segue.merit.edu (Postfix) with SMTP id F08675DDBD for ; Mon, 11 Feb 2002 23:15:29 -0500 (EST) Message-ID: <20020212041529.14750.qmail@web14914.mail.yahoo.com> Received: from [203.200.20.226] by web14914.mail.yahoo.com via HTTP; Mon, 11 Feb 2002 20:15:29 PST Date: Mon, 11 Feb 2002 20:15:29 -0800 (PST) From: Manav Bhatia Subject: Re: Questions about dynamic capability negotiation To: idr@merit.edu Cc: BRijsman@unispherenetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Hi Bruno, | > I have some questions about dynamic capability negotiation: | > | > 1. What should a BGP speaker do when some event occurs that | > is not legal given the current state of negotiated | > capabilities, e.g: | > | > 1a) A route-refresh message is received after a | > capability message removing the route-refresh | > capability has been sent. If the implementation is correct then this particular scenario would never arise because even if the user requests a soft reconfig then a route refresh message is ONLY sent if this capability has been negotiated between the two peers. In short, it means that if the two peers have not negotiated on route refresh and even then if one of the peers receive a RR message then it is safe to bring down the session by sending a NOTIFICATION message because we know that the other end is doing something wrong and we no longer want to continue peering with him! A correct implementation will NEVER send a RR message if this capability has NOT been negotiated between the two peers. | > 2. What should a BGP speaker do when it receives an illegal | > capability message, e.g. a capability message with | > capability code dynamic-capability-negotiation or | > four-octet-as-numbers. A correct implementation will ignore the unsupported capability code and NOT send a NOTIFICATION message. ~Manav __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA07162 for ; Mon, 11 Feb 2002 17:22:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EF91A9122B; Mon, 11 Feb 2002 17:22:12 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B978A9122F; Mon, 11 Feb 2002 17:22:11 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4DBCE9122B for ; Mon, 11 Feb 2002 17:22:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2E91D5DDB8; Mon, 11 Feb 2002 17:22:10 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailwest.unispherenetworks.com (unknown [65.194.140.130]) by segue.merit.edu (Postfix) with ESMTP id E90815DD94 for ; Mon, 11 Feb 2002 17:22:09 -0500 (EST) Received: by uniwest1.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id <1J3BX6ND>; Mon, 11 Feb 2002 17:22:09 -0500 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C02E7E58A@uniwest1.it.west.unispherenetworks.com> From: "Rijsman, Bruno" To: "'idr@merit.edu'" Subject: Questions about dynamic capability negotiation Date: Mon, 11 Feb 2002 17:22:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk > I have some questions about dynamic capability negotiation: > > 1. What should a BGP speaker do when some event occurs that > is not legal given the current state of negotiated > capabilities, e.g: > > 1a) A route-refresh message is received after a > capability message removing the route-refresh > capability has been sent. > > 1b) An ipv4-multicast update is received after a > capability message removing the multi-protocol > capability for ipv4-multicast has been sent. > > Note that the above two situations can occur without > either side violating the protocol as is demonstrated > by the following example: > > A B > | | > | OPEN | > | cap. routee-refresh | > |........................>| > | | > | | > | CAPABILITY | > | remove route-refresh | > |... | > | ... ....| > | ... .... | > | ... .... | > | ...... | > | .... ... | > (X)|<.... ... | > | ROUTE-REFRESH ...>| > | | > > What should A do at time (X) ? > > I see 3 possibilities: > > i) ignore the route-refresh: not good because > B will not get the UPDATEs it requested > (and B has no indication anything is wrong) > > ii) send a notification: not good because > now the session is aborted although neither > side did anything illegal > > iii) process the route refresh (i.e. send the > RIB-out again): in that case what is the > point of removing the route-refresh > capability? > > It seems to me that there is no single answer > that can apply to all capabilities and each > capability should specify: > > A) Whether or not dynamic capability negotiation > is legal, and if so > > B) What to do in case of collisions as shown > above. > > 2. What should a BGP speaker do when it receives an illegal > capability message, e.g. a capability message with > capability code dynamic-capability-negotiation or > four-octet-as-numbers. > > Keep in mind that the draft already specifies that > capability messages with an unknown capability code > must be ignored (so, if the answer is: send a notification > we get inconsistent behavior between peer which know > and peers which don't know a certain capability). > > > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA08109 for ; Wed, 6 Feb 2002 02:24:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AD21591216; Wed, 6 Feb 2002 02:24:14 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D2059121D; Wed, 6 Feb 2002 02:24:14 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6CBA991216 for ; Wed, 6 Feb 2002 02:24:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 474D95DDE3; Wed, 6 Feb 2002 02:24:13 -0500 (EST) Delivered-To: idr@merit.edu Received: from web20306.mail.yahoo.com (web20306.mail.yahoo.com [216.136.226.87]) by segue.merit.edu (Postfix) with SMTP id B877B5DDC7 for ; Wed, 6 Feb 2002 02:24:12 -0500 (EST) Message-ID: <20020206072411.27903.qmail@web20306.mail.yahoo.com> Received: from [203.200.20.226] by web20306.mail.yahoo.com via HTTP; Tue, 05 Feb 2002 23:24:11 PST Date: Tue, 5 Feb 2002 23:24:11 -0800 (PST) From: Mareline Sheldon Subject: RE: Route Reflectors To: jhaas@nexthop.com Cc: idr@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Jeff, Pl. find my comments inline .. | From RFC 2796: | : When a RR reflects a route, it must prepend the local CLUSTER_ID to | : the CLUSTER_LIST. If the CLUSTER_LIST is empty, it must create a new | : one. Using this attribute an RR can identify if the routing | : information is looped back to the same cluster due to mis- | : configuration. If the local CLUSTER_ID is found in the cluster-list, | : the advertisement received should be ignored. | | In other words, it must always prepend the cluster_id when it reflects | a route. the rfc says when the route is reflected from the clients to the non-clients it appends the cluster ID. It does not say anything when the route is to be reflected from the nonclients to the clients which happens in the scenario i had explained (RR receives a route from EBGP .. should the cluster ID be appended when advertising this route to clients/non clients?) regards, mareline s. __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA13759 for ; Tue, 5 Feb 2002 08:53:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A6A3D91224; Tue, 5 Feb 2002 08:52:39 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C8C591268; Tue, 5 Feb 2002 08:52:39 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6E6A491224 for ; Tue, 5 Feb 2002 08:52:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 55DBD5DDE2; Tue, 5 Feb 2002 08:52:38 -0500 (EST) Delivered-To: idr@merit.edu Received: from web20301.mail.yahoo.com (web20301.mail.yahoo.com [216.136.226.82]) by segue.merit.edu (Postfix) with SMTP id 12C6C5DDA3 for ; Tue, 5 Feb 2002 08:52:38 -0500 (EST) Message-ID: <20020205135233.6212.qmail@web20301.mail.yahoo.com> Received: from [203.200.20.226] by web20301.mail.yahoo.com via HTTP; Tue, 05 Feb 2002 05:52:33 PST Date: Tue, 5 Feb 2002 05:52:33 -0800 (PST) From: Mareline Sheldon Subject: Route Reflectors To: idr@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Hi, Does rfc 1996 support hierarchical configuration of Route reflectors i.e can i have multiple Route reflectors as clients of another BIG route reflector? Regards, mareline s. __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA21526 for ; Sun, 3 Feb 2002 17:57:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A5B2191213; Sun, 3 Feb 2002 17:57:05 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 75AA491251; Sun, 3 Feb 2002 17:57:05 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1209B91213 for ; Sun, 3 Feb 2002 17:57:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 02F375DD9D; Sun, 3 Feb 2002 17:56:39 -0500 (EST) Delivered-To: idr@merit.edu Received: from hotmail.com (f185.law7.hotmail.com [216.33.237.185]) by segue.merit.edu (Postfix) with ESMTP id B26C65DD9C for ; Sun, 3 Feb 2002 17:56:38 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 3 Feb 2002 14:56:16 -0800 Received: from 63.104.212.252 by lw7fd.law7.hotmail.msn.com with HTTP; Sun, 03 Feb 2002 22:56:16 GMT X-Originating-IP: [63.104.212.252] From: "Kent Wong" To: idr@merit.edu Subject: Questions on BGP Graceful Restart Date: Sun, 03 Feb 2002 22:56:16 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Feb 2002 22:56:16.0765 (UTC) FILETIME=[FC9CA2D0:01C1AD05] Sender: owner-idr@merit.edu Precedence: bulk Hi, I have a couple questions regarding Graceful Restart draft-ietf-idr-restart-01.txt for the Receiving Speaker after it establihed session with its potential restarting peer: 1. If a receiving speaker receives an OPEN msg from the restarting peer with the Restart Bit set to FALSE, how should it respond? Should it still mark routes as stale and wait for route retain timer or just flush all the staled routes from the restarting peer right away? I saw this question was asked in the mailing list but couldn't find any answer posted yet. 2. If the receiving speaker receives an OPEN msg from the restarting peer with a different Restart Time than the OPEN msg it previously received from the peer before the restart, should it set its restart timer to be this new restart time OR it should still use the old advertised restart time and save this for the next time use? In other words, any graceful restart procedure executed by this receiving speaker should based on the previous negotiated parameter and newly advertised parameter cannot take effect until next restart happens? 3. If before the receiving speaker finishes its initial routing update to the restarting peer (i.e. before it sends out the End-of-RIB marker), it already receives updates from the restarting peer (this could happen because restarting peer's route selection defer timer expires), should it still wait for End-of-RIB marker from restarting peer OR it should take it as a signal that Graceful restart already fails and flush all its staled routes learnt from the peer right away? I think it should treat it as an end of Graceful restart and start flushing the staled routes. I didn't see this mentioned in the draft though. Thanks in advance. ---Kent Wong _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com