From mailman-admin@ietf.org Sat Feb 1 08:56:05 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05674 for ; Sat, 1 Feb 2003 08:56:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h11E0bJ09412 for ; Sat, 1 Feb 2003 09:00:37 -0500 Date: Sat, 01 Feb 2003 09:00:37 -0500 Message-ID: <20030201140037.8821.85124.Mailman@www1.ietf.org> Subject: www.ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: idr-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your www.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, idr-request@www.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for idr-archive@ietf.org: List Password // URL ---- -------- idr@www.ietf.org omkeeh https://www1.ietf.org/mailman/options/idr/idr-archive%40ietf.org From owner-idr@merit.edu Sat Feb 1 18:06:40 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17271 for ; Sat, 1 Feb 2003 18:06:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1628C9121E; Sat, 1 Feb 2003 18:10:05 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE0B691273; Sat, 1 Feb 2003 18:10: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 7ABA89121E for ; Sat, 1 Feb 2003 18:10:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 377835DEAF; Sat, 1 Feb 2003 18:10:02 -0500 (EST) Delivered-To: idr@merit.edu Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 12AC65DEAB for ; Sat, 1 Feb 2003 18:10:01 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id SAA50699; Sat, 1 Feb 2003 18:09:53 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302012309.SAA50699@workhorse.fictitious.org> To: andrewl@xix-w.bengi.exodus.net Cc: Mathew Richardson , idr@merit.edu, curtis@fictitious.org, yakov@juniper.net Reply-To: curtis@fictitious.org Subject: Re: Issue 18 In-reply-to: Your message of "Fri, 31 Jan 2003 14:41:31 PST." <20030131144131.A256@demiurge.exodus.net> Date: Sat, 01 Feb 2003 18:09:53 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <20030131144131.A256@demiurge.exodus.net>, andrewl@xix-w.bengi.exodu s.net writes: > Although I don't want to extend the time this issue is still open, I have > to agree with mrr here. The text, as it stands is not as clear as > the text mrr is proposing, or the text I proposed a while back. Of the > two alternates, I prefer mrr's text, since it states more clearly that > the comparison is optional. > > Is there any compelling reason NOT to go with one of these two? > > > If a MULTI_EXIT_DISC attribute is removed before re-advertising a > > route into IBGP, then if MULTI_EXIT_DISC comparisons are performed > ^^^^^^^ "and if" better? > > during tie-breaking, the routes that will have their MULTI_EXIT_DISC > > attributes removed before readvertisement in IGBP MUST be treated > > as having been received without a MULTI_EXIT_DISC attribute. > > > or > > > If a MULTI_EXIT_DISC attribute is removed before re-advertising a > > route into IBGP, then comparison based on the received MULTI_EXIT_DISC > > attribute MAY still be performed. If an implementation chooses to > > perform this comparison, then the comparison MUST be performed only > > among EBGP learned routes, and it MUST be performed before the removal > > of the MULTI_EXIT_DISC attribute. > > Andrew The second one is wrong. The second sentence should start with "If an implementation chooses to remove MULTI_EXIT_DISC". Replace "perform this comparison" with "remove MULTI_EXIT_DISC" in the second sentence, it then becomes redundant. Since the comparison is optional, the "and it MUST be performed before the removal ..." could be interpreted as an ambiguity (is it optional or not). If a MULTI_EXIT_DISC attribute is removed before re-advertising a route into IBGP, then comparison based on the received EBGP MULTI_EXIT_DISC attribute MAY still be performed. If an implementation chooses to remove MULTI_EXIT_DISC, then the optional comparison on MULTI_EXIT_DISC if performed at all MUST be performed only among EBGP learned routes. The best EBGP learned route may then be compared with IBGP learned routes after the removal of the MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a subset of EBGP learned routes and the selected "best" EBGP learned route will not have MULTI_EXIT_DISC removed, then the MULTI_EXIT_DISC must be used in the comparison with IBGP learned routes. For IBGP learned routes the MULTI_EXIT_DISC MUST be used in route comparisons which reach this step in the decision process. I think all cases are covered. I think the above is unambiguous. If we must change it, might as well make it completely unambiguous preferably without becoming cumbersome or overly wordy. Curtis From owner-idr@merit.edu Mon Feb 3 11:47:21 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12912 for ; Mon, 3 Feb 2003 11:47:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BF0D691220; Mon, 3 Feb 2003 11:50:48 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88CB591227; Mon, 3 Feb 2003 11:50: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 27E4091220 for ; Mon, 3 Feb 2003 11:50:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 147ED5DF5E; Mon, 3 Feb 2003 11:50:46 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 50B685DDDC for ; Mon, 3 Feb 2003 11:50:45 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h13GoAO02476; Mon, 3 Feb 2003 11:50:10 -0500 (EST) (envelope-from mrr@mrichardson.nexthop.com) 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 h13Go7C02469; Mon, 3 Feb 2003 11:50:07 -0500 (EST) (envelope-from mrr@mrichardson.nexthop.com) Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id h13Go7v00775; Mon, 3 Feb 2003 11:50:07 -0500 (EST) Date: Mon, 3 Feb 2003 11:50:07 -0500 From: Mathew Richardson To: Curtis Villamizar Cc: andrewl@xix-w.bengi.exodus.net, idr@merit.edu, yakov@juniper.net Subject: Re: Issue 18 Message-ID: <20030203165007.GA608@nexthop.com> References: <20030131144131.A256@demiurge.exodus.net> <200302012309.SAA50699@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302012309.SAA50699@workhorse.fictitious.org> User-Agent: Mutt/1.4i X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk > Curtis Villamizar [Sat, Feb 01, 2003 at 06:09:53PM -0500]: > >In message <20030131144131.A256@demiurge.exodus.net>, andrewl@xix-w.bengi.exodu >s.net writes: >> > If a MULTI_EXIT_DISC attribute is removed before re-advertising a >> > route into IBGP, then comparison based on the received MULTI_EXIT_DISC >> > attribute MAY still be performed. If an implementation chooses to >> > perform this comparison, then the comparison MUST be performed only >> > among EBGP learned routes, and it MUST be performed before the removal >> > of the MULTI_EXIT_DISC attribute. >The second one is wrong. The second sentence should start with "If an >implementation chooses to remove MULTI_EXIT_DISC". Replace "perform >this comparison" with "remove MULTI_EXIT_DISC" in the second sentence, >it then becomes redundant. Since the comparison is optional, the "and >it MUST be performed before the removal ..." could be interpreted as >an ambiguity (is it optional or not). I disagree, but that doesn't matter since I'm fine with your proposed text below. In fact, I prefer it because it clarifies the handling of the comparison between EBGP and IBGP learned routes in the presence of MULTI_EXIT_DISC stripping. > If a MULTI_EXIT_DISC attribute is removed before re-advertising a > route into IBGP, then comparison based on the received EBGP > MULTI_EXIT_DISC attribute MAY still be performed. If an > implementation chooses to remove MULTI_EXIT_DISC, then the optional > comparison on MULTI_EXIT_DISC if performed at all MUST be performed > only among EBGP learned routes. The best EBGP learned route may > then be compared with IBGP learned routes after the removal of the > MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a > subset of EBGP learned routes and the selected "best" EBGP learned > route will not have MULTI_EXIT_DISC removed, then the > MULTI_EXIT_DISC must be used in the comparison with IBGP learned > routes. For IBGP learned routes the MULTI_EXIT_DISC MUST be used > in route comparisons which reach this step in the decision process. mrr From owner-idr@merit.edu Mon Feb 3 12:09:00 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13515 for ; Mon, 3 Feb 2003 12:08:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B4FC891227; Mon, 3 Feb 2003 12:12:25 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86E8A91228; Mon, 3 Feb 2003 12:12: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 3BBCA91227 for ; Mon, 3 Feb 2003 12:12:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 20D9E5DF97; Mon, 3 Feb 2003 12:12:24 -0500 (EST) Delivered-To: idr@merit.edu Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 510805DF5E for ; Mon, 3 Feb 2003 12:12:23 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA57020; Mon, 3 Feb 2003 12:11:55 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302031711.MAA57020@workhorse.fictitious.org> To: Mathew Richardson Cc: Curtis Villamizar , andrewl@xix-w.bengi.exodus.net, idr@merit.edu, yakov@juniper.net Reply-To: curtis@fictitious.org Subject: Re: Issue 18 In-reply-to: Your message of "Mon, 03 Feb 2003 11:50:07 EST." <20030203165007.GA608@nexthop.com> Date: Mon, 03 Feb 2003 12:11:55 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <20030203165007.GA608@nexthop.com>, Mathew Richardson writes: > > > I disagree, but that doesn't matter since I'm fine with your proposed > text below. In fact, I prefer it because it clarifies the handling > of the comparison between EBGP and IBGP learned routes in the presence > of MULTI_EXIT_DISC stripping. OK. > > If a MULTI_EXIT_DISC attribute is removed before re-advertising a > > route into IBGP, then comparison based on the received EBGP > > MULTI_EXIT_DISC attribute MAY still be performed. If an > > implementation chooses to remove MULTI_EXIT_DISC, then the optional > > comparison on MULTI_EXIT_DISC if performed at all MUST be performed > > only among EBGP learned routes. The best EBGP learned route may > > then be compared with IBGP learned routes after the removal of the > > MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a > > subset of EBGP learned routes and the selected "best" EBGP learned > > route will not have MULTI_EXIT_DISC removed, then the > > MULTI_EXIT_DISC must be used in the comparison with IBGP learned > > routes. For IBGP learned routes the MULTI_EXIT_DISC MUST be used > > in route comparisons which reach this step in the decision process. > > > > mrr If there is no disagreement about changing our prior near consensus, then we have no real change in the intent but some additional clarification and may have converted "not quite concensus" to full concensus. Full consensus is good if that's what we have. Curtis ps - I wonder if there is any "most modified paragraph" in bgp4 where the meaning was not changed just the wording. It would have to be somewhere in route selection or the state machine. No Cc to the list please - if it gets started it could be a lengthy thread. :-) From owner-idr@merit.edu Tue Feb 4 00:13:13 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00397 for ; Tue, 4 Feb 2003 00:13:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 341A49123A; Tue, 4 Feb 2003 00:16:44 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1FD79123C; Tue, 4 Feb 2003 00:16:43 -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 583629123A for ; Tue, 4 Feb 2003 00:16:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4760B5DFC5; Tue, 4 Feb 2003 00:16:00 -0500 (EST) Delivered-To: idr@merit.edu Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id C64715DFA7 for ; Tue, 4 Feb 2003 00:15:59 -0500 (EST) Received: from cisco.com (megha.cisco.com [192.122.173.140]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h145FvSQ022840 for ; Mon, 3 Feb 2003 21:15:58 -0800 (PST) Received: from ROJOSEW2K ([10.77.139.156]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id KAA04644 for ; Tue, 4 Feb 2003 10:44:50 +0530 (IST) Message-ID: <062301c2cc0c$7f444690$9c8b4d0a@apac.cisco.com> From: "Roy Jose" To: Subject: Why drafts and RFC's are not shown up in the IDR page Date: Tue, 4 Feb 2003 10:45:56 +0530 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 Content-Transfer-Encoding: 7bit Thanks, Roy From owner-idr@merit.edu Wed Feb 5 09:07:26 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25644 for ; Wed, 5 Feb 2003 09:07:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E27139127C; Wed, 5 Feb 2003 09:10:54 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1DB69127E; Wed, 5 Feb 2003 09:10: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 6D4509127C for ; Wed, 5 Feb 2003 09:10:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 45F0B5DF5F; Wed, 5 Feb 2003 09:10:53 -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 C62845DF4D for ; Wed, 5 Feb 2003 09:10:52 -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 h15EAbS74944; Wed, 5 Feb 2003 06:10:37 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200302051410.h15EAbS74944@merlot.juniper.net> To: curtis@fictitious.org Cc: Mathew Richardson , andrewl@xix-w.bengi.exodus.net, idr@merit.edu Subject: Re: Issue 18 In-Reply-To: Your message of "Mon, 03 Feb 2003 12:11:55 EST." <200302031711.MAA57020@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17708.1044454237.1@juniper.net> Date: Wed, 05 Feb 2003 06:10:37 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Curtis, > > I disagree, but that doesn't matter since I'm fine with your proposed > > text below. In fact, I prefer it because it clarifies the handling > > of the comparison between EBGP and IBGP learned routes in the presence > > of MULTI_EXIT_DISC stripping. > > OK. > > > > If a MULTI_EXIT_DISC attribute is removed before re-advertising a > > > route into IBGP, then comparison based on the received EBGP > > > MULTI_EXIT_DISC attribute MAY still be performed. If an > > > implementation chooses to remove MULTI_EXIT_DISC, then the optional > > > comparison on MULTI_EXIT_DISC if performed at all MUST be performed > > > only among EBGP learned routes. The best EBGP learned route may > > > then be compared with IBGP learned routes after the removal of the > > > MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a > > > subset of EBGP learned routes and the selected "best" EBGP learned > > > route will not have MULTI_EXIT_DISC removed, then the > > > MULTI_EXIT_DISC must be used in the comparison with IBGP learned > > > routes. For IBGP learned routes the MULTI_EXIT_DISC MUST be used > > > in route comparisons which reach this step in the decision process. > > > > > > > > mrr > > > If there is no disagreement about changing our prior near consensus, > then we have no real change in the intent but some additional > clarification and may have converted "not quite concensus" to full > concensus. Full consensus is good if that's what we have. Your text will be incorporated into the next release of the draft. Yakov. From owner-idr@merit.edu Thu Feb 6 13:10:57 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28745 for ; Thu, 6 Feb 2003 13:10:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3878391213; Thu, 6 Feb 2003 13:14:27 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0045991217; Thu, 6 Feb 2003 13:14: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 EC37391213 for ; Thu, 6 Feb 2003 13:14:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id CFA945DE3F; Thu, 6 Feb 2003 13:14:25 -0500 (EST) Delivered-To: idr@merit.edu Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by segue.merit.edu (Postfix) with ESMTP id 59E655DD9B for ; Thu, 6 Feb 2003 13:14:25 -0500 (EST) Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id h16IEMc01243 for ; Thu, 6 Feb 2003 13:14:22 -0500 (EST) Received: from 192.168.0.185 by tenornet.com; THU, 6 Feb 2003 13:10:18 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Feb 2003 13:10:17 -0500 Message-ID: <6B190B34070BD411ACA000B0D0214E560165B8D2@newman.tenornet.com> From: "Tsillas, Jim" To: "'idr@merit.edu'" Subject: md5 TCP resets Date: Thu, 6 Feb 2003 13:10:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk rfc 2385 states that resets are ignored even when they originate due to a stale connection. If the connection is stale and the md5 digest can still be built, shouldn't the stale end issue the reset with an md5 digest so that the opposite end can receive the reset? Also, does it make sense to send resets with no digest (for the case where there is no listener) when the received packet contained a digest? It seems that would simply be a waste. -Jim. From owner-idr@merit.edu Tue Feb 11 08:54:23 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04936 for ; Tue, 11 Feb 2003 08:54:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 15D1B91245; Tue, 11 Feb 2003 08:57:56 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D17F091246; Tue, 11 Feb 2003 08:57:55 -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 B33A691245 for ; Tue, 11 Feb 2003 08:57:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 987C65DF8C; Tue, 11 Feb 2003 08:57:54 -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 E11B35DF6E for ; Tue, 11 Feb 2003 08:57:53 -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 h1BDvrS55018; Tue, 11 Feb 2003 05:57:53 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200302111357.h1BDvrS55018@merlot.juniper.net> To: idr@merit.edu Cc: skh@nexthop.com Subject: agenda for the IDR WG meeting MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46159.1044971873.1@juniper.net> Date: Tue, 11 Feb 2003 05:57:53 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, It is time to start setting the agenda for the San Francisco meeting. If you want to discuss issues with drafts at the San Francisco meeting please request a slot to do so, by sending mail to the wg chairs (skh@nexthop.com, yakov@juniper.net). Yakov. From owner-idr@merit.edu Tue Feb 11 09:01:46 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05145 for ; Tue, 11 Feb 2003 09:01:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2494D91247; Tue, 11 Feb 2003 09:05:24 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC7F091248; Tue, 11 Feb 2003 09:05:23 -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 EEA6791247 for ; Tue, 11 Feb 2003 09:05:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2A1905DF8C; Tue, 11 Feb 2003 09:05:22 -0500 (EST) Delivered-To: idr@merit.edu Received: from web20310.mail.yahoo.com (web20310.mail.yahoo.com [216.136.226.91]) by segue.merit.edu (Postfix) with SMTP id B56F15DE37 for ; Tue, 11 Feb 2003 09:05:21 -0500 (EST) Message-ID: <20030211140520.45651.qmail@web20310.mail.yahoo.com> Received: from [203.200.20.226] by web20310.mail.yahoo.com via HTTP; Tue, 11 Feb 2003 06:05:20 PST Date: Tue, 11 Feb 2003 06:05:20 -0800 (PST) From: Mareline Sheldon Subject: Route Reflectors and IPv6 To: idr@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Hello, The standard says that if the remote router ID is not configured then a router may include its IP address in sending the originator id. What will happen in case when i have peering using IPv6? In that case i will not be having an IPv4 address to fill. Has any thought gone on this? Regards, Mareline S. __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com From owner-idr@merit.edu Tue Feb 11 10:17:01 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07835 for ; Tue, 11 Feb 2003 10:17:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0660F9123D; Tue, 11 Feb 2003 10:20:39 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA61991262; Tue, 11 Feb 2003 10:20:38 -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 4B03A9123D for ; Tue, 11 Feb 2003 10:20:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2DEE95DDFB; Tue, 11 Feb 2003 10:20:36 -0500 (EST) Delivered-To: idr@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id B0C365DDD1 for ; Tue, 11 Feb 2003 10:20:35 -0500 (EST) Received: from cisco.com (router.cisco.com [171.69.182.20]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1BFKQB6026500; Tue, 11 Feb 2003 07:20:26 -0800 (PST) Received: from [64.101.214.208] (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA28604; Tue, 11 Feb 2003 10:20:33 -0500 (EST) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <20030211140520.45651.qmail@web20310.mail.yahoo.com> References: <20030211140520.45651.qmail@web20310.mail.yahoo.com> Date: Tue, 11 Feb 2003 10:20:16 -0500 To: Mareline Sheldon From: "John G. Scudder" Subject: Re: Route Reflectors and IPv6 Cc: idr@merit.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idr@merit.edu Precedence: bulk At 6:05 AM -0800 2/11/03, Mareline Sheldon wrote: >Hello, >The standard says that if the remote router ID is not configured >then a router may include its IP address in sending the originator >id. It's not clear what the referent of "the standard" is here. I'm assuming RFC 1966, but RFC 1966 doesn't say anything about using your IP address as the originator ID, it says to use your router ID. With our new focus on correct use of terminology, this would more accurately be "BGP Identifier." >What will happen in case when i have peering using >IPv6? In that case i will not be having an IPv4 address to fill. draft-ietf-idr-bgp-identifier-01.txt >Has any thought gone on this? > >Regards, >Mareline S. > >__________________________________________________ >Do you Yahoo!? I do not Yahoo. --John From owner-idr@merit.edu Wed Feb 12 08:33:58 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02205 for ; Wed, 12 Feb 2003 08:33:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EDBFD91221; Wed, 12 Feb 2003 08:37:30 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B595B91229; Wed, 12 Feb 2003 08:37: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 9D65191221 for ; Wed, 12 Feb 2003 08:37:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 830C35DE6D; Wed, 12 Feb 2003 08:37:29 -0500 (EST) Delivered-To: idr@merit.edu Received: from web20302.mail.yahoo.com (web20302.mail.yahoo.com [216.136.226.83]) by segue.merit.edu (Postfix) with SMTP id D5CA95DDA4 for ; Wed, 12 Feb 2003 08:37:28 -0500 (EST) Message-ID: <20030212133726.87383.qmail@web20302.mail.yahoo.com> Received: from [203.200.20.226] by web20302.mail.yahoo.com via HTTP; Wed, 12 Feb 2003 05:37:26 PST Date: Wed, 12 Feb 2003 05:37:26 -0800 (PST) From: Mareline Sheldon Subject: Re: Route Reflectors and IPv6 To: "John G. Scudder" Cc: idr@merit.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk okay .. so then it becomes mandatory for everyone to explicitly configure a BGP ID which needs to be unique in an AS! This is somewhat problematic coz till now we were not necessarily explicitly configuring BGP IDs for if none was given then it would automatically pick out one from its interfaces. This will not be possible in an IPv6 network now coz all the interfaces will be assigned IPv6 addresses. Mareline S. --- "John G. Scudder" wrote: > At 6:05 AM -0800 2/11/03, Mareline Sheldon wrote: > >Hello, > >The standard says that if the remote router ID is not configured > >then a router may include its IP address in sending the originator > >id. > > It's not clear what the referent of "the standard" is here. I'm > assuming RFC 1966, but RFC 1966 doesn't say anything about using your > IP address as the originator ID, it says to use your router ID. With > our new focus on correct use of terminology, this would more > accurately be "BGP Identifier." > > >What will happen in case when i have peering using > >IPv6? In that case i will not be having an IPv4 address to fill. > > draft-ietf-idr-bgp-identifier-01.txt > > >Has any thought gone on this? > > > >Regards, > >Mareline S. > > > >__________________________________________________ > >Do you Yahoo!? > > I do not Yahoo. > > --John __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com From owner-idr@merit.edu Wed Feb 12 10:58:10 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07239 for ; Wed, 12 Feb 2003 10:58:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DA5E591235; Wed, 12 Feb 2003 11:01:47 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7FB0A91236; Wed, 12 Feb 2003 11:01: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 64C4691235 for ; Wed, 12 Feb 2003 11:01:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id E2E3C5DDAA; Wed, 12 Feb 2003 11:01:43 -0500 (EST) Delivered-To: idr@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id 6BAFF5DD96 for ; Wed, 12 Feb 2003 11:01:43 -0500 (EST) Received: from cisco.com (sjc-vpn4-18.cisco.com [10.21.80.18]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1CG1XB6025799; Wed, 12 Feb 2003 08:01:33 -0800 (PST) Date: Wed, 12 Feb 2003 10:01:47 -0600 Subject: Re: Route Reflectors and IPv6 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "John G. Scudder" , idr@merit.edu To: Mareline Sheldon From: Micah Bartell In-Reply-To: <20030212133726.87383.qmail@web20302.mail.yahoo.com> Message-Id: <4A280A7E-3EA3-11D7-A673-000A95765246@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I would think that explicitly configuring BGP IDs is a good best practice. I know that having the router automatically use one of the IPv4 addresses on the router could result in problems such as when anycast RP is used for multicast. In the case of IPv6 only, there is no way to guarantee that any 32-bit integer generated based on internal information is unique in the domain. I think in the long run, separating the BGP ID from the actual addressing is beneficial with BGP being used in a multiprotocol fashion. /mpb On Wednesday, Feb 12, 2003, at 07:37 US/Central, Mareline Sheldon wrote: > okay .. so then it becomes mandatory for everyone to explicitly > configure a BGP ID which needs > to be unique in an AS! This is somewhat problematic coz till now we > were not necessarily > explicitly configuring BGP IDs for if none was given then it would > automatically pick out one > from its interfaces. > > This will not be possible in an IPv6 network now coz all the > interfaces will be assigned IPv6 > addresses. > > Mareline S. > --- "John G. Scudder" wrote: >> At 6:05 AM -0800 2/11/03, Mareline Sheldon wrote: >>> Hello, >>> The standard says that if the remote router ID is not configured >>> then a router may include its IP address in sending the originator >>> id. >> >> It's not clear what the referent of "the standard" is here. I'm >> assuming RFC 1966, but RFC 1966 doesn't say anything about using your >> IP address as the originator ID, it says to use your router ID. With >> our new focus on correct use of terminology, this would more >> accurately be "BGP Identifier." >> >>> What will happen in case when i have peering using >>> IPv6? In that case i will not be having an IPv4 address to fill. >> >> draft-ietf-idr-bgp-identifier-01.txt >> >>> Has any thought gone on this? >>> >>> Regards, >>> Mareline S. >>> >>> __________________________________________________ >>> Do you Yahoo!? >> >> I do not Yahoo. >> >> --John > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Shopping - Send Flowers for Valentine's Day > http://shopping.yahoo.com > From owner-idr@merit.edu Wed Feb 12 12:00:52 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08757 for ; Wed, 12 Feb 2003 12:00:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2C06691240; Wed, 12 Feb 2003 12:04:27 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E66291242; Wed, 12 Feb 2003 12:04: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 E2EB391240 for ; Wed, 12 Feb 2003 12:02:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id B7D2C5DED4; Wed, 12 Feb 2003 12:02:33 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 298F95DE39 for ; Wed, 12 Feb 2003 12:02:33 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1CH2Be56347; Wed, 12 Feb 2003 12:02:11 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) 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 h1CH25C56336; Wed, 12 Feb 2003 12:02:05 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h1CH25R19658; Wed, 12 Feb 2003 12:02:05 -0500 (EST) Date: Wed, 12 Feb 2003 12:02:05 -0500 From: Jeffrey Haas To: Micah Bartell Cc: Mareline Sheldon , "John G. Scudder" , idr@merit.edu Subject: Re: Route Reflectors and IPv6 Message-ID: <20030212120205.A19313@nexthop.com> References: <20030212133726.87383.qmail@web20302.mail.yahoo.com> <4A280A7E-3EA3-11D7-A673-000A95765246@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4A280A7E-3EA3-11D7-A673-000A95765246@cisco.com>; from mbartell@cisco.com on Wed, Feb 12, 2003 at 10:01:47AM -0600 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Wed, Feb 12, 2003 at 10:01:47AM -0600, Micah Bartell wrote: > I would think that explicitly configuring BGP IDs is a good best > practice. I haven't had the time nor the data to analyze a live network. However, I have a large suspicion that on a router with a reasonable number of external peering sessions that the tie-breaking will get down to routerid in a significant number of cases. This means that choosing a router-id intelligently may seriously affect route selection. This is a gentle reminder to implementors that having some way to extra at what point a route was selected in the tie-breaking process would be a damned handy thing to have in your CLI. > /mpb -- Jeff Haas NextHop Technologies From owner-idr@merit.edu Thu Feb 13 04:03:32 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07493 for ; Thu, 13 Feb 2003 04:03:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6F53F91214; Thu, 13 Feb 2003 04:07:07 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B30991216; Thu, 13 Feb 2003 04: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 D5EB691214 for ; Thu, 13 Feb 2003 04:07:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id BC4C05DF43; Thu, 13 Feb 2003 04:07:05 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailout3.samsung.com (unknown [203.254.224.33]) by segue.merit.edu (Postfix) with ESMTP id 6D86D5DF36 for ; Thu, 13 Feb 2003 04:07:05 -0500 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HA800001PA2QF@mailout3.samsung.com> for idr@merit.edu; Thu, 13 Feb 2003 18:06:02 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HA800KY5PA20I@mailout3.samsung.com> for idr@merit.edu; Thu, 13 Feb 2003 18:06:02 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HA8004PHPWFH8@mmp2.samsung.com> for idr@merit.edu; Thu, 13 Feb 2003 18:19:29 +0900 (KST) Date: Thu, 13 Feb 2003 14:36:19 +0530 From: Manav Bhatia Subject: Next-Hop in IPv6 only environment To: idr@merit.edu Reply-To: Manav Bhatia Message-id: <053501c2d33f$2d5d8820$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT Hello, I have a very basic doubt in implementing BGP extensions for IPv6 Inter-Domain Routing. Consider two routers (not running dual stack) as shown in the figure. ----------- -------------- | | | | | peer 1 | IPv6 | peer2 | | | ------------ | | | | | | ----------- --------------- 3ffe :: aa 3ffe :: bb They are peered up using IPv6 addresses using TCP over IPv6. Which is then the IPv4 next-hop which shall be used in all the BGP UPDATE messages. Does it need to be explicitly configured or is one of the global/local IPv6 addresses converted into IPv4 and used. How is it done? In case of dual stack one can look into the interface over which the peering takes place and use that IP address as the next-hop. But what happens in case of IPv6 only? Regards, Manav From owner-idr@merit.edu Thu Feb 13 07:46:10 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11009 for ; Thu, 13 Feb 2003 07:46:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4CCA791273; Thu, 13 Feb 2003 07:49:45 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8A349126F; Thu, 13 Feb 2003 07:49:44 -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 908C49127C for ; Thu, 13 Feb 2003 07:49:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6BAFB5DF66; Thu, 13 Feb 2003 07:49:04 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailout1.samsung.com (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 1C5D85DF65 for ; Thu, 13 Feb 2003 07:49:04 -0500 (EST) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HA800901ZKEL8@mailout1.samsung.com> for idr@merit.edu; Thu, 13 Feb 2003 21:48:14 +0900 (KST) Received: from ep_mmp2 ([127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HA80062HZKENG@mailout1.samsung.com> for idr@merit.edu; Thu, 13 Feb 2003 21:48:14 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HA900F4G06CK4@mmp2.samsung.com> for idr@merit.edu; Thu, 13 Feb 2003 22:01:27 +0900 (KST) Date: Thu, 13 Feb 2003 18:18:17 +0530 From: Manav Bhatia Subject: Re: Next-Hop in IPv6 only environment To: idr@merit.edu Reply-To: Manav Bhatia Message-id: <09e401c2d35e$2fbf7be0$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <053501c2d33f$2d5d8820$b4036c6b@sisodomain.com> Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT Hi, I guess in case of IPv6 only environment then one necessarily needs to configure a Router ID which will be filled in the mandatory fields. But then if the Router ID is non-routable then one cant advertise IPv4 reachability information using that peering !!! Is this correct? Regards, Manav ----- Original Message ----- From: "Manav Bhatia" To: Sent: Thursday, February 13, 2003 2:36 PM Subject: Next-Hop in IPv6 only environment > Hello, > I have a very basic doubt in implementing BGP extensions for IPv6 > Inter-Domain Routing. > > Consider two routers (not running dual stack) as shown in the figure. > > ----------- -------------- > | | | | > | peer 1 | IPv6 | peer2 | > | | ------------ | | > | | | | > ----------- --------------- > 3ffe :: aa 3ffe :: bb > > They are peered up using IPv6 addresses using TCP over IPv6. Which is then > the IPv4 next-hop which shall be used in all the BGP UPDATE messages. Does > it need to be explicitly configured or is one of the global/local IPv6 > addresses converted into IPv4 and used. How is it done? > > In case of dual stack one can look into the interface over which the > peering takes place and use that IP address as the next-hop. But what > happens in case of IPv6 only? > > Regards, > Manav > > From owner-idr@merit.edu Thu Feb 13 09:56:43 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14031 for ; Thu, 13 Feb 2003 09:56:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8A0B991281; Thu, 13 Feb 2003 10:00:09 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1586C91296; Thu, 13 Feb 2003 10:00:08 -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 78D2091281 for ; Thu, 13 Feb 2003 10:00:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id CBE735DF74; Thu, 13 Feb 2003 10:00:04 -0500 (EST) Delivered-To: idr@merit.edu Received: from web20310.mail.yahoo.com (web20310.mail.yahoo.com [216.136.226.91]) by segue.merit.edu (Postfix) with SMTP id F31E15DD8E for ; Thu, 13 Feb 2003 10:00:03 -0500 (EST) Message-ID: <20030213145959.86191.qmail@web20310.mail.yahoo.com> Received: from [203.200.20.226] by web20310.mail.yahoo.com via HTTP; Thu, 13 Feb 2003 06:59:59 PST Date: Thu, 13 Feb 2003 06:59:59 -0800 (PST) From: Mareline Sheldon Subject: Re: Next-Hop in IPv6 only environment To: idr@merit.edu In-Reply-To: <09e401c2d35e$2fbf7be0$b4036c6b@sisodomain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Exactly. If your network is IPv6 only then you must somehow give some IPv4 address which this router may use as the next-hop when advertising BGP UPDATE messages. One way could be through CLI. Mareline S. --- Manav Bhatia wrote: > Hi, > I guess in case of IPv6 only environment then one necessarily needs to > configure a Router ID which will be filled in the mandatory fields. But > then if the Router ID is non-routable then one cant advertise IPv4 > reachability information using that peering !!! > > Is this correct? > > Regards, > Manav > > ----- Original Message ----- > From: "Manav Bhatia" > To: > Sent: Thursday, February 13, 2003 2:36 PM > Subject: Next-Hop in IPv6 only environment > > > > Hello, > > I have a very basic doubt in implementing BGP extensions for IPv6 > > Inter-Domain Routing. > > > > Consider two routers (not running dual stack) as shown in the figure. > > > > ----------- -------------- > > | | | | > > | peer 1 | IPv6 | peer2 | > > | | ------------ | | > > | | | | > > ----------- --------------- > > 3ffe :: aa 3ffe :: bb > > > > They are peered up using IPv6 addresses using TCP over IPv6. Which is > then > > the IPv4 next-hop which shall be used in all the BGP UPDATE messages. > Does > > it need to be explicitly configured or is one of the global/local IPv6 > > addresses converted into IPv4 and used. How is it done? > > > > In case of dual stack one can look into the interface over which the > > peering takes place and use that IP address as the next-hop. But what > > happens in case of IPv6 only? > > > > Regards, > > Manav > > > > > __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com From owner-idr@merit.edu Thu Feb 13 13:09:38 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20569 for ; Thu, 13 Feb 2003 13:09:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D58AD9127C; Thu, 13 Feb 2003 13:13:10 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A7511912B0; Thu, 13 Feb 2003 13:13: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 8AFE79127C for ; Thu, 13 Feb 2003 13:13:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 65E5F5DE41; Thu, 13 Feb 2003 13:13:09 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id C30F85DE2F for ; Thu, 13 Feb 2003 13:13:08 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1DID6M82246; Thu, 13 Feb 2003 13:13:06 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) 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 h1DID3C82239; Thu, 13 Feb 2003 13:13:03 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h1DID3Q25171; Thu, 13 Feb 2003 13:13:03 -0500 (EST) Date: Thu, 13 Feb 2003 13:13:03 -0500 From: Jeffrey Haas To: Mareline Sheldon Cc: idr@merit.edu Subject: Re: Next-Hop in IPv6 only environment Message-ID: <20030213131303.A24336@nexthop.com> References: <09e401c2d35e$2fbf7be0$b4036c6b@sisodomain.com> <20030213145959.86191.qmail@web20310.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030213145959.86191.qmail@web20310.mail.yahoo.com>; from marelines@yahoo.com on Thu, Feb 13, 2003 at 06:59:59AM -0800 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Thu, Feb 13, 2003 at 06:59:59AM -0800, Mareline Sheldon wrote: > If your network is IPv6 only then you must somehow give some IPv4 address which this router > may use as the next-hop when advertising BGP UPDATE messages. One way could be through CLI. If the boxes, as shown below, are NOT running dual stack, then an IPv4 nexthop is nonsense. IPv4 reachability should be discarded. > Mareline S. > > --- Manav Bhatia wrote: > > Hi, > > I guess in case of IPv6 only environment then one necessarily needs to > > configure a Router ID which will be filled in the mandatory fields. But > > then if the Router ID is non-routable then one cant advertise IPv4 > > reachability information using that peering !!! > > > > Is this correct? > > > > Regards, > > Manav > > > > ----- Original Message ----- > > From: "Manav Bhatia" > > To: > > Sent: Thursday, February 13, 2003 2:36 PM > > Subject: Next-Hop in IPv6 only environment > > > > > > > Hello, > > > I have a very basic doubt in implementing BGP extensions for IPv6 > > > Inter-Domain Routing. > > > > > > Consider two routers (not running dual stack) as shown in the figure. > > > > > > ----------- -------------- > > > | | | | > > > | peer 1 | IPv6 | peer2 | > > > | | ------------ | | > > > | | | | > > > ----------- --------------- > > > 3ffe :: aa 3ffe :: bb > > > > > > They are peered up using IPv6 addresses using TCP over IPv6. Which is > > then > > > the IPv4 next-hop which shall be used in all the BGP UPDATE messages. > > Does > > > it need to be explicitly configured or is one of the global/local IPv6 > > > addresses converted into IPv4 and used. How is it done? > > > > > > In case of dual stack one can look into the interface over which the > > > peering takes place and use that IP address as the next-hop. But what > > > happens in case of IPv6 only? > > > > > > Regards, > > > Manav -- Jeff Haas NextHop Technologies From owner-idr@merit.edu Thu Feb 13 21:57:40 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27516 for ; Thu, 13 Feb 2003 21:57:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8D82D912AA; Thu, 13 Feb 2003 22:01:09 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 269E5912B1; Thu, 13 Feb 2003 22:01: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 245BD912AA for ; Thu, 13 Feb 2003 22:00:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id ABCDF5E032; Thu, 13 Feb 2003 22:00:31 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailout3.samsung.com (unknown [203.254.224.33]) by segue.merit.edu (Postfix) with ESMTP id E835E5DE8C for ; Thu, 13 Feb 2003 22:00:30 -0500 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HAA001052Z9TN@mailout3.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 11:59:33 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HAA000DL2Z87X@mailout3.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 11:59:33 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HAA00FDM3LJK4@mmp2.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 12:13:01 +0900 (KST) Date: Fri, 14 Feb 2003 08:29:44 +0530 From: Manav Bhatia Subject: Re: Next-Hop in IPv6 only environment To: Jeffrey Haas , Mareline Sheldon Cc: idr@merit.edu Reply-To: Manav Bhatia Message-id: <0ab901c2d3d5$2417ceb0$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <09e401c2d35e$2fbf7be0$b4036c6b@sisodomain.com> <20030213145959.86191.qmail@web20310.mail.yahoo.com> <20030213131303.A24336@nexthop.com> Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT Jeff, If you are not running a dual stack you still need an IPv4 address as a next-hop (even though it wont be used) which will be used as a mandatory path attribute along with the ORIGIN and AS-PATH. -- Manav ----- Original Message ----- From: "Jeffrey Haas" To: "Mareline Sheldon" Cc: Sent: Thursday, February 13, 2003 11:43 PM Subject: Re: Next-Hop in IPv6 only environment > On Thu, Feb 13, 2003 at 06:59:59AM -0800, Mareline Sheldon wrote: > > If your network is IPv6 only then you must somehow give some IPv4 address which this router > > may use as the next-hop when advertising BGP UPDATE messages. One way could be through CLI. > > If the boxes, as shown below, are NOT running dual stack, then an > IPv4 nexthop is nonsense. IPv4 reachability should be discarded. > > > Mareline S. > > > > --- Manav Bhatia wrote: > > > Hi, > > > I guess in case of IPv6 only environment then one necessarily needs to > > > configure a Router ID which will be filled in the mandatory fields. But > > > then if the Router ID is non-routable then one cant advertise IPv4 > > > reachability information using that peering !!! > > > > > > Is this correct? > > > > > > Regards, > > > Manav > > > > > > ----- Original Message ----- > > > From: "Manav Bhatia" > > > To: > > > Sent: Thursday, February 13, 2003 2:36 PM > > > Subject: Next-Hop in IPv6 only environment > > > > > > > > > > Hello, > > > > I have a very basic doubt in implementing BGP extensions for IPv6 > > > > Inter-Domain Routing. > > > > > > > > Consider two routers (not running dual stack) as shown in the figure. > > > > > > > > ----------- -------------- > > > > | | | | > > > > | peer 1 | IPv6 | peer2 | > > > > | | ------------ | | > > > > | | | | > > > > ----------- --------------- > > > > 3ffe :: aa 3ffe :: bb > > > > > > > > They are peered up using IPv6 addresses using TCP over IPv6. Which is > > > then > > > > the IPv4 next-hop which shall be used in all the BGP UPDATE messages. > > > Does > > > > it need to be explicitly configured or is one of the global/local IPv6 > > > > addresses converted into IPv4 and used. How is it done? > > > > > > > > In case of dual stack one can look into the interface over which the > > > > peering takes place and use that IP address as the next-hop. But what > > > > happens in case of IPv6 only? > > > > > > > > Regards, > > > > Manav > > -- > Jeff Haas > NextHop Technologies > From owner-idr@merit.edu Thu Feb 13 22:09:48 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27873 for ; Thu, 13 Feb 2003 22:09:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8F362912B1; Thu, 13 Feb 2003 22:13:23 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CC33912B3; Thu, 13 Feb 2003 22:13:23 -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 346C8912B1 for ; Thu, 13 Feb 2003 22:13:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1C99C5DFA4; Thu, 13 Feb 2003 22:13:22 -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 CD01A5DE3A for ; Thu, 13 Feb 2003 22:13:21 -0500 (EST) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 0AD43A8906; Thu, 13 Feb 2003 19:13:21 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id A6CD615D3C1; Thu, 13 Feb 2003 19:13:10 -0800 (PST) To: Manav Bhatia Cc: Jeffrey Haas , enke@redback.com, Mareline Sheldon , idr@merit.edu Subject: Re: Next-Hop in IPv6 only environment In-Reply-To: Message from Manav Bhatia of "Fri, 14 Feb 2003 08:29:44 +0530." <0ab901c2d3d5$2417ceb0$b4036c6b@sisodomain.com> Date: Thu, 13 Feb 2003 19:13:10 -0800 From: Enke Chen Message-Id: <20030214031310.A6CD615D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Manav: > Date: Fri, 14 Feb 2003 08:29:44 +0530 > From: Manav Bhatia > Subject: Re: Next-Hop in IPv6 only environment > To: Jeffrey Haas , > Mareline Sheldon > Cc: idr@merit.edu > Reply-To: Manav Bhatia > Message-id: <0ab901c2d3d5$2417ceb0$b4036c6b@sisodomain.com> > > Jeff, > If you are not running a dual stack you still need an IPv4 address as a > next-hop (even though it wont be used) which will be used as a mandatory > path attribute along with the ORIGIN and AS-PATH. This is not correct. As the nexthop value is carried in the MP_REACH_NLRI filed, the NEXTHOP attribute is not needed at all. Please See the following text from RFC 2858: ------------------------------------------------------------------- 2. Multiprotocol Reachable NLRI - MP_REACH_NLRI (Type Code 14): An UPDATE message that carries the MP_REACH_NLRI must also carry the ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP exchanges). Moreover, in IBGP exchanges such a message must also carry the LOCAL_PREF attribute. If such a message is received from an external peer, the local system shall check whether the leftmost AS in the AS_PATH attribute is equal to the autonomous system number of the peer than sent the message. If that is not the case, the local system shall send the NOTIFICATION message with Error Code UPDATE Message Error, and the Error Subcode set to Malformed AS_PATH. --------------------------------------------------------------------- -- Enke > > -- > Manav > > ----- Original Message ----- > From: "Jeffrey Haas" > To: "Mareline Sheldon" > Cc: > Sent: Thursday, February 13, 2003 11:43 PM > Subject: Re: Next-Hop in IPv6 only environment > > > > On Thu, Feb 13, 2003 at 06:59:59AM -0800, Mareline Sheldon wrote: > > > If your network is IPv6 only then you must somehow give some IPv4 > address which this router > > > may use as the next-hop when advertising BGP UPDATE messages. One way > could be through CLI. > > > > If the boxes, as shown below, are NOT running dual stack, then an > > IPv4 nexthop is nonsense. IPv4 reachability should be discarded. > > > > > Mareline S. > > > > > > --- Manav Bhatia wrote: > > > > Hi, > > > > I guess in case of IPv6 only environment then one necessarily needs > to > > > > configure a Router ID which will be filled in the mandatory fields. > But > > > > then if the Router ID is non-routable then one cant advertise IPv4 > > > > reachability information using that peering !!! > > > > > > > > Is this correct? > > > > > > > > Regards, > > > > Manav > > > > > > > > ----- Original Message ----- > > > > From: "Manav Bhatia" > > > > To: > > > > Sent: Thursday, February 13, 2003 2:36 PM > > > > Subject: Next-Hop in IPv6 only environment > > > > > > > > > > > > > Hello, > > > > > I have a very basic doubt in implementing BGP extensions for IPv6 > > > > > Inter-Domain Routing. > > > > > > > > > > Consider two routers (not running dual stack) as shown in the > figure. > > > > > > > > > > ----------- -------------- > > > > > | | | | > > > > > | peer 1 | IPv6 | peer2 | > > > > > | | ------------ | | > > > > > | | | | > > > > > ----------- --------------- > > > > > 3ffe :: aa 3ffe :: bb > > > > > > > > > > They are peered up using IPv6 addresses using TCP over IPv6. Which > is > > > > then > > > > > the IPv4 next-hop which shall be used in all the BGP UPDATE > messages. > > > > Does > > > > > it need to be explicitly configured or is one of the global/local > IPv6 > > > > > addresses converted into IPv4 and used. How is it done? > > > > > > > > > > In case of dual stack one can look into the interface over which > the > > > > > peering takes place and use that IP address as the next-hop. But > what > > > > > happens in case of IPv6 only? > > > > > > > > > > Regards, > > > > > Manav > > > > -- > > Jeff Haas > > NextHop Technologies > > > From owner-idr@merit.edu Thu Feb 13 22:21:59 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28020 for ; Thu, 13 Feb 2003 22:21:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 338E2912B3; Thu, 13 Feb 2003 22:25:35 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 052A1912B6; Thu, 13 Feb 2003 22:25:34 -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 8A2A8912B3 for ; Thu, 13 Feb 2003 22:25:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7825C5DFAD; Thu, 13 Feb 2003 22:25:33 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailout1.samsung.com (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 2710E5DFA4 for ; Thu, 13 Feb 2003 22:25:33 -0500 (EST) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HAA00H0145EHZ@mailout1.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 12:24:50 +0900 (KST) Received: from ep_mmp2 ([127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HAA00D3Y45D77@mailout1.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 12:24:49 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HAA00GBM4RD1F@mmp2.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 12:38:03 +0900 (KST) Date: Fri, 14 Feb 2003 08:54:45 +0530 From: Manav Bhatia Subject: Re: Next-Hop in IPv6 only environment To: Enke Chen Cc: Jeffrey Haas , idr@merit.edu Reply-To: Manav Bhatia Message-id: <0aec01c2d3d8$a3996150$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20030214031310.A6CD615D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT Enke, Then why does the draft-ietf-idr-bgp4-18.txt still mention the NEXT_HOP field as a well-known mandatory attribute. If it isn't required for some extensions then i believe we must mention it somewhere. Moreover, i have never come across any implementation which doesn't look for this attribute when it receives an UPDATE message! Regards, Manav ----- Original Message ----- From: "Enke Chen" To: "Manav Bhatia" Cc: "Jeffrey Haas" ; ; "Mareline Sheldon" ; Sent: Friday, February 14, 2003 8:43 AM Subject: Re: Next-Hop in IPv6 only environment > Hi, Manav: > > > Date: Fri, 14 Feb 2003 08:29:44 +0530 > > From: Manav Bhatia > > Subject: Re: Next-Hop in IPv6 only environment > > To: Jeffrey Haas , > > Mareline Sheldon > > Cc: idr@merit.edu > > Reply-To: Manav Bhatia > > Message-id: <0ab901c2d3d5$2417ceb0$b4036c6b@sisodomain.com> > > > > Jeff, > > If you are not running a dual stack you still need an IPv4 address as a > > next-hop (even though it wont be used) which will be used as a mandatory > > path attribute along with the ORIGIN and AS-PATH. > > This is not correct. As the nexthop value is carried in the MP_REACH_NLRI > filed, the NEXTHOP attribute is not needed at all. Please See the following > text from RFC 2858: > > ------------------------------------------------------------------- > 2. Multiprotocol Reachable NLRI - MP_REACH_NLRI (Type Code 14): > > An UPDATE message that carries the MP_REACH_NLRI must also carry the > ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP > exchanges). Moreover, in IBGP exchanges such a message must also > carry the LOCAL_PREF attribute. If such a message is received from an > external peer, the local system shall check whether the leftmost AS > in the AS_PATH attribute is equal to the autonomous system number of > the peer than sent the message. If that is not the case, the local > system shall send the NOTIFICATION message with Error Code UPDATE > Message Error, and the Error Subcode set to Malformed AS_PATH. > --------------------------------------------------------------------- > > -- Enke > > > > > -- > > Manav > > > > ----- Original Message ----- > > From: "Jeffrey Haas" > > To: "Mareline Sheldon" > > Cc: > > Sent: Thursday, February 13, 2003 11:43 PM > > Subject: Re: Next-Hop in IPv6 only environment > > > > > > > On Thu, Feb 13, 2003 at 06:59:59AM -0800, Mareline Sheldon wrote: > > > > If your network is IPv6 only then you must somehow give some IPv4 > > address which this router > > > > may use as the next-hop when advertising BGP UPDATE messages. One way > > could be through CLI. > > > > > > If the boxes, as shown below, are NOT running dual stack, then an > > > IPv4 nexthop is nonsense. IPv4 reachability should be discarded. > > > > > > > Mareline S. > > > > > > > > --- Manav Bhatia wrote: > > > > > Hi, > > > > > I guess in case of IPv6 only environment then one necessarily needs > > to > > > > > configure a Router ID which will be filled in the mandatory fields. > > But > > > > > then if the Router ID is non-routable then one cant advertise IPv4 > > > > > reachability information using that peering !!! > > > > > > > > > > Is this correct? > > > > > > > > > > Regards, > > > > > Manav > > > > > > > > > > ----- Original Message ----- > > > > > From: "Manav Bhatia" > > > > > To: > > > > > Sent: Thursday, February 13, 2003 2:36 PM > > > > > Subject: Next-Hop in IPv6 only environment > > > > > > > > > > > > > > > > Hello, > > > > > > I have a very basic doubt in implementing BGP extensions for IPv6 > > > > > > Inter-Domain Routing. > > > > > > > > > > > > Consider two routers (not running dual stack) as shown in the > > figure. > > > > > > > > > > > > ----------- -------------- > > > > > > | | | | > > > > > > | peer 1 | IPv6 | peer2 | > > > > > > | | ------------ | | > > > > > > | | | | > > > > > > ----------- --------------- > > > > > > 3ffe :: aa 3ffe :: bb > > > > > > > > > > > > They are peered up using IPv6 addresses using TCP over IPv6. Which > > is > > > > > then > > > > > > the IPv4 next-hop which shall be used in all the BGP UPDATE > > messages. > > > > > Does > > > > > > it need to be explicitly configured or is one of the global/local > > IPv6 > > > > > > addresses converted into IPv4 and used. How is it done? > > > > > > > > > > > > In case of dual stack one can look into the interface over which > > the > > > > > > peering takes place and use that IP address as the next-hop. But > > what > > > > > > happens in case of IPv6 only? > > > > > > > > > > > > Regards, > > > > > > Manav > > > > > > -- > > > Jeff Haas > > > NextHop Technologies > > > > > > > From owner-idr@merit.edu Thu Feb 13 22:34:00 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28493 for ; Thu, 13 Feb 2003 22:33:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5DCF89120D; Thu, 13 Feb 2003 22:37:36 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2FC9E91212; Thu, 13 Feb 2003 22:37: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 278F39120D for ; Thu, 13 Feb 2003 22:37:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0F4CA5DFAD; Thu, 13 Feb 2003 22:37:35 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id A2C725DE5B for ; Thu, 13 Feb 2003 22:37:34 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1E3bTr93385; Thu, 13 Feb 2003 22:37:29 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) 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 h1E3bQC93378; Thu, 13 Feb 2003 22:37:26 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h1E3bQR27217; Thu, 13 Feb 2003 22:37:26 -0500 (EST) Date: Thu, 13 Feb 2003 22:37:26 -0500 From: Jeffrey Haas To: Manav Bhatia Cc: Enke Chen , idr@merit.edu Subject: Re: Next-Hop in IPv6 only environment Message-ID: <20030213223726.A27200@nexthop.com> References: <20030214031310.A6CD615D3C1@popserv1.redback.com> <0aec01c2d3d8$a3996150$b4036c6b@sisodomain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0aec01c2d3d8$a3996150$b4036c6b@sisodomain.com>; from manav@samsung.com on Fri, Feb 14, 2003 at 08:54:45AM +0530 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Fri, Feb 14, 2003 at 08:54:45AM +0530, Manav Bhatia wrote: > Then why does the draft-ietf-idr-bgp4-18.txt still mention the NEXT_HOP > field as a well-known mandatory attribute. If it isn't required for some > extensions then i believe we must mention it somewhere. The general idea is that this is the basic specification. The extensions alter the base specification. I'm not fond of our current mechanism for doing this since it will lead potentially to a base specification with a higher RFC number than the extensions which would lead to similar confusion that you are having. However, I'm also not fond of the idea of trying to do all of the extensions and the base spec in one document. If I suggested such a thing, I expect that Yakov would nail my hide to an IBM DASD chassis as a warning to all others and Sue would gleefully seize all of my office supplies. -- Jeff Haas NextHop Technologies From owner-idr@merit.edu Thu Feb 13 22:45:20 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28701 for ; Thu, 13 Feb 2003 22:45:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8BBFC91212; Thu, 13 Feb 2003 22:48:56 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25C4F91216; Thu, 13 Feb 2003 22:48: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 4300191212 for ; Thu, 13 Feb 2003 22:47:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1980F5DE5B; Thu, 13 Feb 2003 22:47:14 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailout2.samsung.com (unknown [203.254.224.25]) by segue.merit.edu (Postfix) with ESMTP id BC2445DE12 for ; Thu, 13 Feb 2003 22:47:13 -0500 (EST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HAA00I0154P23@mailout2.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 12:46:01 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HAA0042954OMM@mailout2.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 12:46:01 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HAA00F6M5RIK4@mmp2.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 12:59:44 +0900 (KST) Date: Fri, 14 Feb 2003 09:16:31 +0530 From: Manav Bhatia Subject: Re: Next-Hop in IPv6 only environment To: Jeffrey Haas Cc: idr@merit.edu Reply-To: Manav Bhatia Message-id: <0b1d01c2d3db$aaf5f6e0$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20030214031310.A6CD615D3C1@popserv1.redback.com> <0aec01c2d3d8$a3996150$b4036c6b@sisodomain.com> <20030213223726.A27200@nexthop.com> Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT Jeff, > I'm not fond of our current mechanism for doing this since it will > lead potentially to a base specification with a higher RFC number than > the extensions which would lead to similar confusion that you are having. I believe that adding a small pointer in the base spec is much better than having others spend cycles trying to understand the apparent contradiction in the base spec and the extensions. A small note saying that this is not necessarily true anymore or something like that can very easily be accomodated for greater clarity and perspecuity of the RFC. > > However, I'm also not fond of the idea of trying to do all of the > extensions and the base spec in one document. I agree. > If I suggested such a > thing, I expect that Yakov would nail my hide to an IBM DASD chassis > as a warning to all others and Sue would gleefully seize all of my > office supplies. And the IDR community will also loose a very good reviewer :-) Regards -- Manav Bhatia Samsung Electronics. From owner-idr@merit.edu Thu Feb 13 23:00:41 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28919 for ; Thu, 13 Feb 2003 23:00:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E442A91225; Thu, 13 Feb 2003 23:04:17 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7301D9121E; Thu, 13 Feb 2003 23:04: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 8AD279129C for ; Thu, 13 Feb 2003 23:01:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 59B2F5E045; Thu, 13 Feb 2003 23:01:45 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailout3.samsung.com (unknown [203.254.224.33]) by segue.merit.edu (Postfix) with ESMTP id 05A235DF5C for ; Thu, 13 Feb 2003 23:01:45 -0500 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HAA003015TB5Y@mailout3.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 13:00:47 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HAA00MZ85TBUZ@mailout3.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 13:00:47 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HAA00G5M6FQ1F@mmp2.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 13:14:16 +0900 (KST) Date: Fri, 14 Feb 2003 09:31:03 +0530 From: Manav Bhatia Subject: BGP Identifier in draft-ietf-idr-bgp4-18.txt To: idr@merit.edu Reply-To: Manav Bhatia Message-id: <0b2901c2d3dd$b256eeb0$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT Hi, draft-ietf-idr-bgp4-18.txt explains the BGP Identifier as : " A 4-octet unsigned integer indicating the BGP Identifier of the sender of BGP messages. A given BGP speaker sets the value of its BGP Identifier to an IP address assigned to that BGP speaker. The value of the BGP Identifier is determined on startup and is the same for every local interface and every BGP peer." I think that the current definition is a little ambiguous and can be re-worded. BGP Identifier is generally taken as the Loopback address and not necessarily the "IP address assigned to that BGP speaker". I could have two interfaces 1.1.1.1/24 and 1.1.2.1/24 and i could have BGP peerings over these two interfaces. For one peer the IP address assigned to this BGP speaker is 1.1.1.1 while for the other one it is 1.1.2.1. So by the current definition the BGP ID wouldn't be the same for every local interface and every BGP peer. We need to stress more on the fact that it needs to be unique and same for all the peers on every local interface. Regards, Manav ---- Senior Software Engineer Samsung India Software Operations Bangalore - 560 001 +91-80-5550555/6 (1120) From owner-idr@merit.edu Thu Feb 13 23:39:52 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29927 for ; Thu, 13 Feb 2003 23:39:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B35069121A; Thu, 13 Feb 2003 23:43:28 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B54C9121E; Thu, 13 Feb 2003 23:43: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 877EA9121A for ; Thu, 13 Feb 2003 23:43:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 750A85DF39; Thu, 13 Feb 2003 23:43:27 -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 3C5D35DDE7 for ; Thu, 13 Feb 2003 23:43:27 -0500 (EST) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id A4461263681; Thu, 13 Feb 2003 20:43:26 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv2.redback.com (Postfix) with ESMTP id AE3E7979C1; Thu, 13 Feb 2003 20:43:24 -0800 (PST) To: Manav Bhatia Cc: Jeffrey Haas , idr@merit.edu, enke@redback.com Subject: Re: Next-Hop in IPv6 only environment In-Reply-To: Message from Manav Bhatia of "Fri, 14 Feb 2003 09:16:31 +0530." <0b1d01c2d3db$aaf5f6e0$b4036c6b@sisodomain.com> Date: Thu, 13 Feb 2003 20:43:24 -0800 From: Enke Chen Message-Id: <20030214044325.AE3E7979C1@popserv2.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Manav, > Date: Fri, 14 Feb 2003 09:16:31 +0530 > From: Manav Bhatia > Subject: Re: Next-Hop in IPv6 only environment > To: Jeffrey Haas > Cc: idr@merit.edu > Reply-To: Manav Bhatia > Message-id: <0b1d01c2d3db$aaf5f6e0$b4036c6b@sisodomain.com> > > Jeff, > > > I'm not fond of our current mechanism for doing this since it will > > lead potentially to a base specification with a higher RFC number than > > the extensions which would lead to similar confusion that you are having. > > I believe that adding a small pointer in the base spec is much better than > having others spend cycles trying to understand the apparent contradiction > in the base spec and the extensions. A small note saying that this is not > necessarily true anymore or something like that can very easily be > accomodated for greater clarity and perspecuity of the RFC. Reading RFC 2858 again, it actually has the explicit text on the NEXT_HOP attribute: An UPDATE message that carries no NLRI, other than the one encoded in the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute. If such a message contains the NEXT_HOP attribute, the BGP speaker that receives the message should ignore this attribute. -- Enke > > > > > However, I'm also not fond of the idea of trying to do all of the > > extensions and the base spec in one document. > > I agree. > > > If I suggested such a > > thing, I expect that Yakov would nail my hide to an IBM DASD chassis > > as a warning to all others and Sue would gleefully seize all of my > > office supplies. > > And the IDR community will also loose a very good reviewer :-) > > Regards > -- > Manav Bhatia > Samsung Electronics. > > From owner-idr@merit.edu Thu Feb 13 23:56:05 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00271 for ; Thu, 13 Feb 2003 23:56:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4F5D69121E; Thu, 13 Feb 2003 23:59:40 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1CEB091222; Thu, 13 Feb 2003 23:59: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 B1A189121E for ; Thu, 13 Feb 2003 23:59:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8C1025DFAD; Thu, 13 Feb 2003 23:59:38 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailout1.samsung.com (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 3B7835DDC0 for ; Thu, 13 Feb 2003 23:59:38 -0500 (EST) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HAA00L058I88B@mailout1.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 13:58:56 +0900 (KST) Received: from ep_mmp2 ([127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HAA00D3T8I777@mailout1.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 13:58:55 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HAA001NT946GE@mmp2.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 14:12:09 +0900 (KST) Date: Fri, 14 Feb 2003 10:28:55 +0530 From: Manav Bhatia Subject: Re: Next-Hop in IPv6 only environment To: Enke Chen Cc: Jeffrey Haas , mjh@icir.org, idr@merit.edu Reply-To: Manav Bhatia Message-id: <0c0701c2d3e5$c8bbd640$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20030214044325.AE3E7979C1@popserv2.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT Enke, > An UPDATE message that carries no NLRI, other than the one encoded in > the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute. > If such a message contains the NEXT_HOP attribute, the BGP speaker > that receives the message should ignore this attribute. Yes it indeed is. However it would be really nice if a similar thing is mentioned somewhere in the base spec too OR once again, a pointer to the fact that NEXT_HOP attribute is not always *mandatory* is mentioned to remove any later confusions amongst the implementers. I have a gut feeling that this issue will crop up again some time later down the line. The confusion will be all the more aggravated when your base spec RFC is greater than your extensions RFC nos. Thanks, Manav P.S. Once again, the issue isn't that RFC 2858 isn't clear .. its just that it defies what the base spec mandates any implementation to do! It just gets all the more skewed when the base spec is more recent than the extensions draft/RFC! :-) From owner-idr@merit.edu Fri Feb 14 11:09:00 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25769 for ; Fri, 14 Feb 2003 11:08:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E7BC49121B; Fri, 14 Feb 2003 11:12:35 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A153D9122F; Fri, 14 Feb 2003 11:12:35 -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 4E0369121B for ; Fri, 14 Feb 2003 11:12:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 342DA5DED1; Fri, 14 Feb 2003 11:12:34 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id C8E5F5DE43 for ; Fri, 14 Feb 2003 11:12:33 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1EGCUk04339; Fri, 14 Feb 2003 11:12:30 -0500 (EST) (envelope-from mrr@mrichardson.nexthop.com) 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 h1EGCQC04332; Fri, 14 Feb 2003 11:12:26 -0500 (EST) (envelope-from mrr@mrichardson.nexthop.com) Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id h1EGCQ015095; Fri, 14 Feb 2003 11:12:26 -0500 (EST) Date: Fri, 14 Feb 2003 11:12:26 -0500 From: Mathew Richardson To: Manav Bhatia Cc: idr@merit.edu Subject: Re: BGP Identifier in draft-ietf-idr-bgp4-18.txt Message-ID: <20030214161226.GA27013@nexthop.com> References: <0b2901c2d3dd$b256eeb0$b4036c6b@sisodomain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0b2901c2d3dd$b256eeb0$b4036c6b@sisodomain.com> User-Agent: Mutt/1.4i X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk > Manav Bhatia [Fri, Feb 14, 2003 at 09:31:03AM +0530]: >Hi, >draft-ietf-idr-bgp4-18.txt explains the BGP Identifier as : > >" A 4-octet unsigned integer indicating the BGP Identifier of the > sender of BGP messages. A given BGP speaker sets the value of its > BGP Identifier to an IP address assigned to that BGP speaker. The > value of the BGP Identifier is determined on startup and is the > same for every local interface and every BGP peer." > >I think that the current definition is a little ambiguous and can be >re-worded. > >BGP Identifier is generally taken as the Loopback address and not >necessarily the "IP address assigned to that BGP speaker". It says "_an_ IP address assigned to that BGP speaker", not _the_. > I could have two >interfaces 1.1.1.1/24 and 1.1.2.1/24 and i could have BGP peerings over >these two interfaces. For one peer the IP address assigned to this BGP >speaker is 1.1.1.1 while for the other one it is 1.1.2.1. > >So by the current definition the BGP ID wouldn't be the same for every >local interface and every BGP peer. No. If those were the only two IP addresses assigned to the BGP speaker then the BGP Identifier would be one of those. It would be determined on startup, and be the same for every local interface and every BGP peer. >We need to stress more on the fact that it needs to be unique and same for >all the peers on every local interface. From the text that you quoted: "The value of the BGP Identifier is determined on startup and is the same for every local interface and every BGP peer." I don't think it's possible to get much clearer than that. mrr From owner-idr@merit.edu Fri Feb 14 11:11:43 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25808 for ; Fri, 14 Feb 2003 11:11:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8BDFA9122F; Fri, 14 Feb 2003 11:15:07 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 07EDC91233; Fri, 14 Feb 2003 11:15: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 DF1F69122F for ; Fri, 14 Feb 2003 11:15:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C7865DE43; Fri, 14 Feb 2003 11:15:04 -0500 (EST) Delivered-To: idr@merit.edu Received: from nomad.tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by segue.merit.edu (Postfix) with ESMTP id 62B7F5DE0D for ; Fri, 14 Feb 2003 11:15:03 -0500 (EST) Received: by nomad.tcb.net (Postfix, from userid 500) id 91F5955F62; Fri, 14 Feb 2003 09:15:55 -0700 (MST) Received: from nomad.tcb.net (localhost [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id 6C7603E83 for ; Fri, 14 Feb 2003 09:15:55 -0700 (MST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: BGP Identifier in draft-ietf-idr-bgp4-18.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Feb 2003 09:15:50 -0700 Message-Id: <20030214161555.91F5955F62@nomad.tcb.net> Sender: owner-idr@merit.edu Precedence: bulk > > I don't think it's possible to get much clearer than that. > > mrr I agree, I think the current text is more than sufficient. -danny From owner-idr@merit.edu Fri Feb 14 11:21:10 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26000 for ; Fri, 14 Feb 2003 11:21:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1E0DC91233; Fri, 14 Feb 2003 11:24:47 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D390D91239; Fri, 14 Feb 2003 11:24: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 C553991233 for ; Fri, 14 Feb 2003 11:24:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id AD2F55E058; Fri, 14 Feb 2003 11:24:45 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 145CA5E055 for ; Fri, 14 Feb 2003 11:24:45 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA02908; Fri, 14 Feb 2003 11:24:42 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA02060; Fri, 14 Feb 2003 11:24:43 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Feb 2003 11:24:43 -0500 Message-ID: <313680C9A886D511A06000204840E1CF3EA3EE@whq-msgusr-02.pit.comms.marconi.com> From: "Krishnan, Vijay G." To: "'Mathew Richardson'" , Manav Bhatia Cc: idr@merit.edu Subject: RE: BGP Identifier in draft-ietf-idr-bgp4-18.txt Date: Fri, 14 Feb 2003 11:24:41 -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 From the text that you quoted: "The value of the BGP Identifier is determined on startup and is the same for every local interface and every BGP peer." Is this true for a BGP/MPLS case, where each BGP peer will be attached to a VRF? Each VRF will have a Router_ID (used by IGPs like OSPF). Should the BGP Identfier be the same as this Router ID. This would mean that we should have different BGP Identifier for each VRF and one for the internet VRF. -Vijay From owner-idr@merit.edu Fri Feb 14 11:25:43 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26092 for ; Fri, 14 Feb 2003 11:25:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 66C5F91239; Fri, 14 Feb 2003 11:29:20 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2E43F9123F; Fri, 14 Feb 2003 11:29: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 1A3AF91239 for ; Fri, 14 Feb 2003 11:29:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id EEDC55E058; Fri, 14 Feb 2003 11:29:18 -0500 (EST) Delivered-To: idr@merit.edu Received: from nomad.tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by segue.merit.edu (Postfix) with ESMTP id C2A305DE43 for ; Fri, 14 Feb 2003 11:29:18 -0500 (EST) Received: by nomad.tcb.net (Postfix, from userid 500) id 4BCC655F62; Fri, 14 Feb 2003 09:30:11 -0700 (MST) Received: from nomad.tcb.net (localhost [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id 48C3B3E83 for ; Fri, 14 Feb 2003 09:30:11 -0700 (MST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: BGP Identifier in draft-ietf-idr-bgp4-18.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Feb 2003 09:30:06 -0700 Message-Id: <20030214163011.4BCC655F62@nomad.tcb.net> Sender: owner-idr@merit.edu Precedence: bulk That's a "virtual router" sort of implementation issue, and shouldn't be addressed in the base BGP specification. -danny > > From the text that you quoted: "The value of the BGP Identifier is > determined on startup and is the same for every local interface and every > BGP peer." > > > Is this true for a BGP/MPLS case, where each BGP peer will be attached to a > VRF? Each VRF will have a Router_ID (used by IGPs like OSPF). Should the BGP > Identfier be the same as this Router ID. This would mean that we should have > different BGP Identifier for each VRF and one for the internet VRF. > > -Vijay > > From owner-idr@merit.edu Fri Feb 14 11:28:04 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26214 for ; Fri, 14 Feb 2003 11:28:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 04EB49123F; Fri, 14 Feb 2003 11:31:40 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2408A91242; Fri, 14 Feb 2003 11:31: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 99A509123F for ; Fri, 14 Feb 2003 11:31:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5BDCA5DED1; Fri, 14 Feb 2003 11:31:12 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id E8AC15DFE6 for ; Fri, 14 Feb 2003 11:31:11 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1EGUvV04815; Fri, 14 Feb 2003 11:30:57 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) 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 h1EGUsC04808; Fri, 14 Feb 2003 11:30:54 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h1EGUs729208; Fri, 14 Feb 2003 11:30:54 -0500 (EST) Date: Fri, 14 Feb 2003 11:30:53 -0500 From: Jeffrey Haas To: "Krishnan, Vijay G." Cc: "'Mathew Richardson'" , Manav Bhatia , idr@merit.edu Subject: Re: BGP Identifier in draft-ietf-idr-bgp4-18.txt Message-ID: <20030214113053.A28677@nexthop.com> References: <313680C9A886D511A06000204840E1CF3EA3EE@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <313680C9A886D511A06000204840E1CF3EA3EE@whq-msgusr-02.pit.comms.marconi.com>; from Vijay.G.Krishnan@marconi.com on Fri, Feb 14, 2003 at 11:24:41AM -0500 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Fri, Feb 14, 2003 at 11:24:41AM -0500, Krishnan, Vijay G. wrote: > Is this true for a BGP/MPLS case, where each BGP peer will be attached to a > VRF? This starts to be very edgy. > Each VRF will have a Router_ID (used by IGPs like OSPF). Should the BGP > Identfier be the same as this Router ID. This would mean that we should have > different BGP Identifier for each VRF and one for the internet VRF. IMO (and likely contradicted by some implementations), a given router will have a common router-id/bgp identifier which is applied to all VRF's for that router. In cases where you have a "virtual router" where resources are internally disjoint, you are likely to have more than one router-id/bgp identifier. > -Vijay -- Jeff Haas NextHop Technologies From owner-idr@merit.edu Thu Feb 20 10:59:42 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18900 for ; Thu, 20 Feb 2003 10:59:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B087591272; Thu, 20 Feb 2003 11:03:27 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F3A191278; Thu, 20 Feb 2003 11:03: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 500F291272 for ; Thu, 20 Feb 2003 11:03:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 288715DF24; Thu, 20 Feb 2003 11:03:24 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 807605DDBC for ; Thu, 20 Feb 2003 11:03:23 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1KG3Mw45591 for idr@merit.edu; Thu, 20 Feb 2003 11:03:22 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id h1KG3EC45570 for ; Thu, 20 Feb 2003 11:03:14 -0500 (EST) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: FSM issue 26 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 20 Feb 2003 11:03:14 -0500 Message-ID: Thread-Topic: Comments on FSM Issues Thread-Index: AcLSfg2oOgKuybpgSzG7lOaTKdj+4gGa7s+w From: "Susan Hares" To: "Sivananda Ramnath - CTD, Chennai." Cc: X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA18900 Siva: On your request to: > > a) Add 3 new events : 1) Manual start with bgp_stop flap option set > 2) Manual start with passive TCP establishment > and bgp_stop_flap option set > 3) Automatic start with passive TCP establishment > and bgp_stop_flap option set > Events 1 and 2: Let me clarify "not feasible": We have the following options 1) Delay Open flag 2) Automatic Start flag 3) Passive TCP Establishment Flag 4) BGP stop_peer_flap flag 5) automatic stop flag 6) Perform Collision detect in Established mode 7) Accept connections from un-configured peers If we create an Manual start event with all of these options, we will expand the state machine dramatically. The two specified options: 1) Manual start with no Passive TCP Establishment Flag set 2) Manual start with Passive TCP Establishment Flag Are you looking for a clarification of Event 1? If so, please confirm this text is acceptable to add to Event 1: "If the optional Passive TCP Establishment flag and the optional Event 4 is supported, the Passive TCP Establishment Flag should not be set in Event 1." Please confirm that this is sufficient for events 1 and 2. =========== Part 2: new-event 3: Automatic Start with Passive TCP Establishment and bgp_stop_flag flag set The Automatic start events are: Event 3: Automatic start 1) No passive flag set 2) No bgp stop_peer_flap flag set Event 5: Automatic start with Passive TCP Establishment state state 1) No bgp stop_peer_flap flag set Event 6: Automatic start & BGP stop_peer_flap flag set I will revise Event 6 and add a new Event 7 and rename all other events 1 down. Here's the new automatic start events: Event 3: Automatic start 1) Passive TCP Establishment flag is not set 2) BGP stop_peer_flap flag is not set Event 5: Automatic start iwth Passive TCP Establishment flag set 1) BGP stop_peer_flap flag is not set Event 6: Automatic start & BGP stop peer flap flag is set 1) Passive TCP Establishment flag is not set Event 7: Automatic start & BGP stop_peer_flap & passive TCP The following flags are set: 1) Perform automatic start flag 2) BGP stop_peer_flap flag is set 3) Passicve TCP establishment flag is set The current event 7 will be renumbered to Event 8. Event 8 will be Moved to event 13. Events 13-27 will be renumbered to 14-28. Please confirm that you agree to this change and that we have consensus at this point. Sue Hares Siva's comments: =========== > > a) Add 3 new events : 1) Manual start with bgp_stop flap option set > 2) Manual start with passive TCP establishment > and bgp_stop_flap option set > 3) Automatic start with passive TCP establishment > and bgp_stop_flap option set > -----Original Message----- From: Sivananda Ramnath - CTD, Chennai. [mailto:siva@ctd.hcltech.com] Sent: Wednesday, February 12, 2003 5:06 AM To: Susan Hares Cc: Sivananda Ramnath (E-mail) Subject: Comments on FSM Issues Hello, My comments on open issues as per 2.2 of issue list: ++ Issue 26 ++ > We already have > Event 3 - Automatic Start > Event 5 - Automatic start with bgp_stop_flap option set > To make things consistent, shouldn't we either > > a) Add 3 new events : 1) Manual start with bgp_stop flap option set > 2) Manual start with passive TCP establishment > and bgp_stop_flap option set > 3) Automatic start with passive TCP establishment > and bgp_stop_flap option set > > or > > b) Remove Event 6, and rely on a flag to tell us whether peer flap damping > is to be performed for the session or not. > > Sue said she preferred option A. And stated that #1 & #2 are infeasible, > but that we need to add #3. I don't understand why #1 and #2 are unfeasible. Also, because we have the stop_flap as an optional session attribute, I think we are better of reducing the number of events. If that is unacceptable, I am OK with adding the events. However, I do think #1 and #2 need to be incorporated in some fashion. From owner-idr@merit.edu Thu Feb 20 11:15:05 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19824 for ; Thu, 20 Feb 2003 11:15:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DBC2F91278; Thu, 20 Feb 2003 11:18:50 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A144991279; Thu, 20 Feb 2003 11:18: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 503DF91278 for ; Thu, 20 Feb 2003 11:18:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3BC3A5DECD; Thu, 20 Feb 2003 11:18:49 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 8ADE75DDBC for ; Thu, 20 Feb 2003 11:18:48 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1KGIlb46065 for idr@merit.edu; Thu, 20 Feb 2003 11:18:47 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id h1KGIfC46051 for ; Thu, 20 Feb 2003 11:18:41 -0500 (EST) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Issue 33 - Clarification X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 20 Feb 2003 11:18:41 -0500 Message-ID: Thread-Topic: Issue 33 - Clarification Thread-Index: AcLY+7syroC6pgynRHCMqI10EYgiLQ== From: "Susan Hares" To: "Sivananda Ramnath - CTD, Chennai." Cc: X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA19824 Siva: I would like to keep the current text of "Should" in the following text "BGP's destination port SHOULD be port 179 as defined by IANA." Should indicates that it normally should be 179. If an implementation allows for an alternative TCP port, it is still valid as the "MUST" is not indicated. Sue Siva's comment ========================= ++ Issue 33 ++ > I propose that we remove any mention of valid destination TCP port. > > Since BGP will not be listening on this 'invalid' port on which the > connection request was received, it will be handled by the system's > TCP stack, and not communicated as an event to BGP. That was my last comment on this issue. Is this OK, or am I missing something here ? From owner-idr@merit.edu Thu Feb 20 12:33:03 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22286 for ; Thu, 20 Feb 2003 12:33:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2772091253; Thu, 20 Feb 2003 12:36:45 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E326D9127E; Thu, 20 Feb 2003 12:36:44 -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 89FA691253 for ; Thu, 20 Feb 2003 12:36:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 71A0C5DF77; Thu, 20 Feb 2003 12:36:43 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id CAD285DF32 for ; Thu, 20 Feb 2003 12:36:42 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1KHafb49654 for idr@merit.edu; Thu, 20 Feb 2003 12:36:41 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id h1KHaZC49640 for ; Thu, 20 Feb 2003 12:36:35 -0500 (EST) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Issue 24 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 20 Feb 2003 12:36:35 -0500 Message-ID: Thread-Topic: Issue 24 Thread-Index: AcLZBp2c8XuTGTVLSna74g5sxw+uIw== From: "Susan Hares" To: "Sivananda Ramnath - CTD, Chennai." Cc: X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA22286 Siva: Issue 24 was holding on some comments from the mail group on adding examples to events 3,4 and 6. I'm going to leave the examples out of events 3, 4, 6 since I've not heard any strong input on the mail list **and** I had strong comments on prior versions of the draft. I'd like to declare that issue 24 has consensus. Will you agree to this? Sue From owner-idr@merit.edu Thu Feb 20 12:40:17 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22503 for ; Thu, 20 Feb 2003 12:40:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C1EEB9127E; Thu, 20 Feb 2003 12:43:58 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 97AD491280; Thu, 20 Feb 2003 12:43:58 -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 4CBED9127E for ; Thu, 20 Feb 2003 12:43:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2A0885DDFC; Thu, 20 Feb 2003 12:43:57 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 737EE5DDAE for ; Thu, 20 Feb 2003 12:43:56 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1KHhta49950 for idr@merit.edu; Thu, 20 Feb 2003 12:43:55 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id h1KHhgC49913 for ; Thu, 20 Feb 2003 12:43:42 -0500 (EST) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Issue 41 - consensus reached X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 20 Feb 2003 12:43:42 -0500 Message-ID: Thread-Topic: Issue 41 - consensus reached Thread-Index: AcLZB5uedFO6BtIcSKuK1oOlBHY7UA== From: "Susan Hares" To: "Sivananda Ramnath - CTD, Chennai." Cc: , , X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA22503 Siva: thanks for the note on issue 41. We'll consider it closed Sue ============ Siva's note: ++ Issue 41 ++ > Sue proposed: > > My resolution: Let event 14 be optional. > Not all BGP implementations support it. This issue is still marked as open. What you are saying is fine, so I guess we can move this to consensus. From owner-idr@merit.edu Thu Feb 20 13:26:09 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24318 for ; Thu, 20 Feb 2003 13:26:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9415B91282; Thu, 20 Feb 2003 13:29:55 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F99F91285; Thu, 20 Feb 2003 13:29:55 -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 0891191282 for ; Thu, 20 Feb 2003 13:29:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id E0F4F5E069; Thu, 20 Feb 2003 13:29:53 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 6EB765DDA6 for ; Thu, 20 Feb 2003 13:29:53 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1KITqO51797 for idr@merit.edu; Thu, 20 Feb 2003 13:29:52 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id h1KITgC51772 for ; Thu, 20 Feb 2003 13:29:42 -0500 (EST) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Issue 42 - Siva's comments X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 20 Feb 2003 13:29:42 -0500 Message-ID: Thread-Topic: Issue 42 - Siva's comments Thread-Index: AcLZDgi2iCdu8SFIRb+ueJFmDizeFQ== From: "Susan Hares" To: "Sivananda Ramnath - CTD, Chennai." Cc: "Tom Petch" , , X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA24318 Tom and Siva: Here's the comments from Siva on issue 42. I'll send comments next. siva's comments. ============= ++ Issue 42 ++ Issue I am unclear as to what is the way to proceed here. Is there consensus that a NOTIFICATION message does need to be sent ? ++ Issue 42 ++ > The issue is what if Connect state occurs and there is not > a TCP connection. Should an OPEN with wrong version > be accepted? If the Open Delay flag is off, the connection > state should not be getting an Open. The "D" action below > works for "open delay flag off". > > The "y" action you suggest can occur if the open delay > timer is on. > > If this is the issue, please confirm. > We could say: if open delay flag is on -> y action > if open delay flag is off -> D action Yes, this is the issue, and the text you have suggested looks good. If this is OK, can we close the issue ? Sivanand (siva@ctd.hcltech.com) From owner-idr@merit.edu Sat Feb 22 18:28:05 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17292 for ; Sat, 22 Feb 2003 18:28:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 507549121D; Sat, 22 Feb 2003 18:31:23 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 47EE0912C6; Sat, 22 Feb 2003 18:31:22 -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 079529121D for ; Sat, 22 Feb 2003 18:31:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id AD2AF5DFBF; Sat, 22 Feb 2003 18:31:17 -0500 (EST) Delivered-To: idr@merit.edu Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 40D675DF83 for ; Sat, 22 Feb 2003 18:31:17 -0500 (EST) Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id PAA21533; Sat, 22 Feb 2003 15:28:04 -0800 (PST) Date: Sat, 22 Feb 2003 15:28:04 -0800 From: andrewl@xix-w.bengi.exodus.net To: Manav Bhatia Cc: Enke Chen , Jeffrey Haas , mjh@icir.org, idr@merit.edu Subject: Re: Next-Hop in IPv6 only environment Message-ID: <20030222152804.B5760@demiurge.exodus.net> References: <20030214044325.AE3E7979C1@popserv2.redback.com> <0c0701c2d3e5$c8bbd640$b4036c6b@sisodomain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0c0701c2d3e5$c8bbd640$b4036c6b@sisodomain.com>; from manav@samsung.com on Fri, Feb 14, 2003 at 10:28:55AM +0530 Sender: owner-idr@merit.edu Precedence: bulk Going through the entire base spec and adding a caveat in every place where an extention document modifies it, is almost as much work as documenting all the varriant behavior in the base spec. If there is confusion on this issue, I would suggest we add a statement like this: This document specifies the base behavior of the BGP protocol. This behavior can and is modified by extention specifications. When the protocol is extended the new behavior is fully documented in the extention specifications. to the beginning of the document somewhere. Andrew On Fri, Feb 14, 2003 at 10:28:55AM +0530, Manav Bhatia wrote: > Delivered-To: idr-outgoing@trapdoor.merit.edu > Delivered-To: idr@trapdoor.merit.edu > Delivered-To: idr@merit.edu > Date: Fri, 14 Feb 2003 10:28:55 +0530 > From: Manav Bhatia > Subject: Re: Next-Hop in IPv6 only environment > To: Enke Chen > Cc: Jeffrey Haas , mjh@icir.org, idr@merit.edu > Reply-To: Manav Bhatia > X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 > X-Mailer: Microsoft Outlook Express 6.00.2720.3000 > X-Priority: 3 > X-MSMail-priority: Normal > Precedence: bulk > X-Spam-Status: No, hits=0.1 required=5.0 > tests=AWL,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, > USER_AGENT_OE > version=2.43 > X-OriginalArrivalTime: 14 Feb 2003 04:59:52.0087 (UTC) FILETIME=[E876DA70:01C2D3E5] > > Enke, > > > An UPDATE message that carries no NLRI, other than the one encoded in > > the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute. > > If such a message contains the NEXT_HOP attribute, the BGP speaker > > that receives the message should ignore this attribute. > > Yes it indeed is. > > However it would be really nice if a similar thing is mentioned somewhere > in the base spec too OR once again, a pointer to the fact that NEXT_HOP > attribute is not always *mandatory* is mentioned to remove any later > confusions amongst the implementers. > > I have a gut feeling that this issue will crop up again some time later > down the line. The confusion will be all the more aggravated when your base > spec RFC is greater than your extensions RFC nos. > > Thanks, > Manav > > P.S. > Once again, the issue isn't that RFC 2858 isn't clear .. its just that it > defies what the base spec mandates any implementation to do! > > It just gets all the more skewed when the base spec is more recent than the > extensions draft/RFC! > :-) From owner-idr@merit.edu Sun Feb 23 22:00:51 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19140 for ; Sun, 23 Feb 2003 22:00:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F40FC91203; Sun, 23 Feb 2003 22:04:38 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9CD891206; Sun, 23 Feb 2003 22:04: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 2FB7891203 for ; Sun, 23 Feb 2003 22:04:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 034975DF63; Sun, 23 Feb 2003 22:04:36 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailout1.samsung.com (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 9BE745DF5F for ; Sun, 23 Feb 2003 22:04:35 -0500 (EST) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HAS00I01LU6ZB@mailout1.samsung.com> for idr@merit.edu; Mon, 24 Feb 2003 12:03:42 +0900 (KST) Received: from ep_mmp2 ([127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HAS00FU2LU6HW@mailout1.samsung.com> for idr@merit.edu; Mon, 24 Feb 2003 12:03:42 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HAS00ITEMH7KV@mmp2.samsung.com> for idr@merit.edu; Mon, 24 Feb 2003 12:17:34 +0900 (KST) Date: Mon, 24 Feb 2003 08:33:31 +0530 From: Manav Bhatia Subject: Re: Next-Hop in IPv6 only environment To: andrewl@xix-w.bengi.exodus.net Cc: Enke Chen , Jeffrey Haas , mjh@icir.org, idr@merit.edu Reply-To: Manav Bhatia Message-id: <00d601c2dbb1$519e5320$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20030214044325.AE3E7979C1@popserv2.redback.com> <0c0701c2d3e5$c8bbd640$b4036c6b@sisodomain.com> <20030222152804.B5760@demiurge.exodus.net> Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT Yes .. this sounds nice .. and takes care of whatever extensions we might put in some time later .. Manav ----- Original Message ----- From: To: "Manav Bhatia" Cc: "Enke Chen" ; "Jeffrey Haas" ; ; Sent: Sunday, February 23, 2003 4:58 AM Subject: Re: Next-Hop in IPv6 only environment > Going through the entire base spec and adding a caveat in every place where > an extention document modifies it, is almost as much work as documenting all the > varriant behavior in the base spec. > > If there is confusion on this issue, I would suggest we add a statement > like this: > > This document specifies the base behavior of the BGP protocol. This > behavior can and is modified by extention specifications. When the > protocol is extended the new behavior is fully documented in the > extention specifications. > > to the beginning of the document somewhere. > > Andrew > > On Fri, Feb 14, 2003 at 10:28:55AM +0530, Manav Bhatia wrote: > > Delivered-To: idr-outgoing@trapdoor.merit.edu > > Delivered-To: idr@trapdoor.merit.edu > > Delivered-To: idr@merit.edu > > Date: Fri, 14 Feb 2003 10:28:55 +0530 > > From: Manav Bhatia > > Subject: Re: Next-Hop in IPv6 only environment > > To: Enke Chen > > Cc: Jeffrey Haas , mjh@icir.org, idr@merit.edu > > Reply-To: Manav Bhatia > > X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 > > X-Mailer: Microsoft Outlook Express 6.00.2720.3000 > > X-Priority: 3 > > X-MSMail-priority: Normal > > Precedence: bulk > > X-Spam-Status: No, hits=0.1 required=5.0 > > tests=AWL,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, > > USER_AGENT_OE > > version=2.43 > > X-OriginalArrivalTime: 14 Feb 2003 04:59:52.0087 (UTC) FILETIME=[E876DA70:01C2D3E5] > > > > Enke, > > > > > An UPDATE message that carries no NLRI, other than the one encoded in > > > the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute. > > > If such a message contains the NEXT_HOP attribute, the BGP speaker > > > that receives the message should ignore this attribute. > > > > Yes it indeed is. > > > > However it would be really nice if a similar thing is mentioned somewhere > > in the base spec too OR once again, a pointer to the fact that NEXT_HOP > > attribute is not always *mandatory* is mentioned to remove any later > > confusions amongst the implementers. > > > > I have a gut feeling that this issue will crop up again some time later > > down the line. The confusion will be all the more aggravated when your base > > spec RFC is greater than your extensions RFC nos. > > > > Thanks, > > Manav > > > > P.S. > > Once again, the issue isn't that RFC 2858 isn't clear .. its just that it > > defies what the base spec mandates any implementation to do! > > > > It just gets all the more skewed when the base spec is more recent than the > > extensions draft/RFC! > > :-) > From owner-idr@merit.edu Mon Feb 24 00:54:11 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22051 for ; Mon, 24 Feb 2003 00:54:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E2A3491226; Mon, 24 Feb 2003 00:50:28 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 295F691302; Mon, 24 Feb 2003 00:50:08 -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 C5DCC91304 for ; Mon, 24 Feb 2003 00:48:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id B68D35DF34; Mon, 24 Feb 2003 00:48:10 -0500 (EST) Delivered-To: idr@merit.edu Received: from web20309.mail.yahoo.com (web20309.mail.yahoo.com [216.136.226.90]) by segue.merit.edu (Postfix) with SMTP id EA3565DF00 for ; Mon, 24 Feb 2003 00:48:09 -0500 (EST) Message-ID: <20030224054809.26568.qmail@web20309.mail.yahoo.com> Received: from [203.200.20.226] by web20309.mail.yahoo.com via HTTP; Sun, 23 Feb 2003 21:48:09 PST Date: Sun, 23 Feb 2003 21:48:09 -0800 (PST) From: Mareline Sheldon Subject: MED in practise To: idr@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Hello, I want to know if this is a general practise followed by the ISPs to advertise in their MED thier internal IGP costs to reach the destination to their upstream peers. If this is done then the ISP which is connected to two other ISPs can decide amongst the better one by choosing the lower MED advertised by both and sending all the traffic through it! On the other hand, if we have the option to compare MEDs only from the same AS then i can use MED to choose a lesser congested link. Is this how MED is set or is some other logic followed? And finally why is MED considered so fatal and there were talks sometime back to get rid of it. And help in this regard will be appreciated. Thanks, Mareline S. __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-idr@merit.edu Mon Feb 24 02:08:30 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03427 for ; Mon, 24 Feb 2003 02:08:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 751E59120C; Mon, 24 Feb 2003 02:12:13 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D1A291227; Mon, 24 Feb 2003 02:12: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 EDFD99120C for ; Mon, 24 Feb 2003 02:12:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id CFB965DEFF; Mon, 24 Feb 2003 02:12:11 -0500 (EST) Delivered-To: idr@merit.edu Received: from fsnt.future.futsoft.com (unknown [203.197.140.35]) by segue.merit.edu (Postfix) with ESMTP id 0697F5DDA4 for ; Mon, 24 Feb 2003 02:12:10 -0500 (EST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 24 Feb 2003 12:48:34 +0530 Received: from anandn (anandn.future.futsoft.com [10.6.4.34]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h1O79cxj005020 for ; Mon, 24 Feb 2003 12:39:38 +0530 Reply-To: From: "Anand Nagarajan" To: Subject: ORIGINATOR_ID in Route Reflectors Date: Mon, 24 Feb 2003 12:39:32 +0530 Message-Id: <002c01c2dbd3$aef6fdc0$2204060a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit If a RR Client sends an UPDATE without an ORIGINATOR_ID attribute, what is the value of the ORIGINATOR_ID that the RR should use, before advertising the UPDATE to its RR peers? Should it be its own Router ID or the RR client's (which sent the UPDATE) Router ID? TIA - Anand Nagarajan -- Say what you do and Do what you say -- *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-idr@merit.edu Mon Feb 24 02:15:56 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03542 for ; Mon, 24 Feb 2003 02:15:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4A0CF9122B; Mon, 24 Feb 2003 02:19:44 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 910B891235; Mon, 24 Feb 2003 02:19: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 58B1A9122B for ; Mon, 24 Feb 2003 02:19:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4512C5DDF2; Mon, 24 Feb 2003 02:19:39 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailout3.samsung.com (unknown [203.254.224.33]) by segue.merit.edu (Postfix) with ESMTP id E78015DDA4 for ; Mon, 24 Feb 2003 02:19:38 -0500 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HAS00E01XMVDQ@mailout3.samsung.com> for idr@merit.edu; Mon, 24 Feb 2003 16:18:31 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HAS0060CXMV6M@mailout3.samsung.com> for idr@merit.edu; Mon, 24 Feb 2003 16:18:31 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HAS00IV2YADKV@mmp2.samsung.com> for idr@merit.edu; Mon, 24 Feb 2003 16:32:40 +0900 (KST) Date: Mon, 24 Feb 2003 12:48:36 +0530 From: Manav Bhatia Subject: Re: ORIGINATOR_ID in Route Reflectors To: anandn@future.futsoft.com, idr@merit.edu Reply-To: Manav Bhatia Message-id: <033d01c2dbd4$f3bf37a0$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <002c01c2dbd3$aef6fdc0$2204060a@future.futsoft.com> Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT Anand, The RR should use the RID of the client which sent the UPDATE. - Manav ----- Original Message ----- From: "Anand Nagarajan" To: Sent: Monday, February 24, 2003 12:39 PM Subject: ORIGINATOR_ID in Route Reflectors > > If a RR Client sends an UPDATE without an ORIGINATOR_ID attribute, what is > the value of the ORIGINATOR_ID that the RR should use, before advertising > the UPDATE to its RR peers? Should it be its own Router ID or the RR > client's (which sent the UPDATE) Router ID? > > TIA > - Anand Nagarajan > -- Say what you do and Do what you say -- > From owner-idr@merit.edu Mon Feb 24 04:34:50 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05956 for ; Mon, 24 Feb 2003 04:34:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 57DC291221; Mon, 24 Feb 2003 04:38:35 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1DA2E91237; Mon, 24 Feb 2003 04:38:35 -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 BE74D91221 for ; Mon, 24 Feb 2003 04:38:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9F8DC5DF78; Mon, 24 Feb 2003 04:38:33 -0500 (EST) Delivered-To: idr@merit.edu Received: from ganesh.ctd.hctech.com (Ganesh.hcltech.com [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id 495F25DE0F for ; Mon, 24 Feb 2003 04:38:32 -0500 (EST) Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Feb 2003 15:08:29 +0530 Message-ID: <60F922ABE8BE9C428E806F43C0EC7368066BA9@HARITHA> From: "Sivananda Ramnath - CTD, Chennai." To: Susan Hares Cc: idr@merit.edu Subject: RE: Issue 24 Date: Mon, 24 Feb 2003 15:08:25 +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 Hello, Agreed. We can consider this issue closed without any changes to the text. Siva (siva@ctd.hcltech.com) > -----Original Message----- > From: Susan Hares [mailto:shares@nexthop.com] > Sent: Thursday, February 20, 2003 11:07 PM > To: Sivananda Ramnath - CTD, Chennai. > Cc: idr@merit.edu > Subject: Issue 24 > > > Siva: > > Issue 24 was holding on some comments from the mail > group on adding examples to events 3,4 and 6. > > I'm going to leave the examples out of events 3, 4, 6 since > I've not heard any strong input on the mail list **and** > I had strong comments on prior versions of the draft. > > I'd like to declare that issue 24 has consensus. > Will you agree to this? > > Sue > From owner-idr@merit.edu Mon Feb 24 09:34:39 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15362 for ; Mon, 24 Feb 2003 09:34:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8BADD9123E; Mon, 24 Feb 2003 09:38:23 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5570791240; Mon, 24 Feb 2003 09:38:23 -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 577179123E for ; Mon, 24 Feb 2003 09:38:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3DD775DFB4; Mon, 24 Feb 2003 09:38:22 -0500 (EST) Delivered-To: idr@merit.edu Received: from nomad.tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by segue.merit.edu (Postfix) with ESMTP id 10A0A5DE4E for ; Mon, 24 Feb 2003 09:38:22 -0500 (EST) Received: by nomad.tcb.net (Postfix, from userid 500) id 74E4755F62; Mon, 24 Feb 2003 07:38:53 -0700 (MST) Received: from nomad.tcb.net (localhost [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id 73FE23E83 for ; Mon, 24 Feb 2003 07:38:53 -0700 (MST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: ORIGINATOR_ID in Route Reflectors Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Feb 2003 07:38:48 -0700 Message-Id: <20030224143853.74E4755F62@nomad.tcb.net> Sender: owner-idr@merit.edu Precedence: bulk > If a RR Client sends an UPDATE without an ORIGINATOR_ID attribute, what is > the value of the ORIGINATOR_ID that the RR should use, before advertising > the UPDATE to its RR peers? Should it be its own Router ID or the RR > client's (which sent the UPDATE) Router ID? Note that an RR client does NOT add the ORIGINATOR_ID attribute, it's added by the route reflector and set to the ROTUER_ID of the client. This initially provided the ability for deployments where a client didn't need to know it was a client. However, RFC 2796 changed things slightly (perhaps in order to accommodate implementations where for performance purposes the RR reflected routes learned from a client back to that client) by requiring that clients "ignore" received routes if the ORIGINATOR_ID is equal to the local ROUTER_ID. In addition to adding the ORIGINATOR_ID attribute to the route, the RR also creates a CLUSTER_LIST and places the local CLUSTER_ID value (which is by default usually the RR's ROUTER_ID or otherwise some explicitly configured value) in the list. RFC 2796 is clear about these behaviors. -danny From owner-idr@merit.edu Mon Feb 24 10:02:05 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16020 for ; Mon, 24 Feb 2003 10:02:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3E77791248; Mon, 24 Feb 2003 10:05:50 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B787391244; Mon, 24 Feb 2003 10:05: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 0118A91247 for ; Mon, 24 Feb 2003 10:05:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id DF1745DFC1; Mon, 24 Feb 2003 10:05:43 -0500 (EST) Delivered-To: idr@merit.edu Received: from nomad.tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by segue.merit.edu (Postfix) with ESMTP id A3EC75DFB4 for ; Mon, 24 Feb 2003 10:05:43 -0500 (EST) Received: by nomad.tcb.net (Postfix, from userid 500) id 6FBD855F62; Mon, 24 Feb 2003 08:06:05 -0700 (MST) Received: from nomad.tcb.net (localhost [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id 6B6493E83 for ; Mon, 24 Feb 2003 08:06:05 -0700 (MST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: MED in practise Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Feb 2003 08:06:00 -0700 Message-Id: <20030224150605.6FBD855F62@nomad.tcb.net> Sender: owner-idr@merit.edu Precedence: bulk > I want to know if this is a general practise followed by the > ISPs to advertise in their MED thier internal IGP costs to reach > the destination to their upstream peers. If you replace "destination" with NEXT_HOP, sure... > If this is done then the ISP which is connected to two other ISPs > can decide amongst the better one by choosing the lower MED advertised > by both and sending all the traffic through it! Sure, and thereby always selecting the ISP with the metric allocation policy that results in lower values for IGP metrics. Or, perhaps always selecting the ISP with the IGP that provides a smaller range of available metrics (e.g., IS-IS pre-deployment/"wide metrics"). > On the other hand, if we have the option to compare MEDs only from the > same AS then i can use MED to choose a lesser congested link. Sure, as with many other BGP attributes, if you manually configure MEDs or employ some dynamic router configuration technique (to configure MEDs). > Is this how MED is set or is some other logic followed? And finally > why is MED considered so fatal and there were talks sometime back to > get rid of it. I've seen MEDs work as prescribed in many scenarios. However, be wary: o aggregation breaks MEDs o comparing MEDs between different ASs with different policies isn't typically a good idea o MEDs are a primary trigger of route oscillation o MEDs often result in superfluous route advertisements per IGP link/node/cost changes o Most notably, accepting MEDs from peers can have a visible impact on the economics of carrying bits, depending on which network is carrying traffic, how far, etc.. Also note that while many service providers send (often by request only) and accept MEDs from customers, they typically reset MEDs to some fixed value on routes learned from peers. -danny From owner-idr@merit.edu Mon Feb 24 14:00:28 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22668 for ; Mon, 24 Feb 2003 14:00:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B7E7291238; Mon, 24 Feb 2003 14:01:54 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7380591239; Mon, 24 Feb 2003 14:01: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 D483291238 for ; Mon, 24 Feb 2003 14:01:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3DBE35DFB6; Mon, 24 Feb 2003 14:01:36 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 6AFCE5DDA5 for ; Mon, 24 Feb 2003 14:01:31 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1OJ1Sj38069 for idr@merit.edu; Mon, 24 Feb 2003 14:01:28 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id h1OJ1EC38031 for ; Mon, 24 Feb 2003 14:01:14 -0500 (EST) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Next-Hop in IPv6 only environment X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 24 Feb 2003 14:01:14 -0500 Message-ID: Thread-Topic: Next-Hop in IPv6 only environment Thread-Index: AcLayu40m+zK+fM2QZi3lCnF4s0QuABa+S3w From: "Susan Hares" To: , "Manav Bhatia" Cc: "Enke Chen" , "Jeffrey Haas" , , X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA22668 Andrew: My understanding from the ADs is that we are completing the Base specification first without any additions. After we have completed the 1st version of the base specification, I believe the ADs will re-open the charter to these additions. It is my understanding that we will deal with IPv6 issues after this point. Yakov, Bill and Alex - am I correct? Sue Hares -----Original Message----- From: andrewl@xix-w.bengi.exodus.net [mailto:andrewl@xix-w.bengi.exodus.net] Sent: Saturday, February 22, 2003 6:28 PM To: Manav Bhatia Cc: Enke Chen; Jeffrey Haas; mjh@icir.org; idr@merit.edu Subject: Re: Next-Hop in IPv6 only environment Going through the entire base spec and adding a caveat in every place where an extention document modifies it, is almost as much work as documenting all the varriant behavior in the base spec. If there is confusion on this issue, I would suggest we add a statement like this: This document specifies the base behavior of the BGP protocol. This behavior can and is modified by extention specifications. When the protocol is extended the new behavior is fully documented in the extention specifications. to the beginning of the document somewhere. Andrew On Fri, Feb 14, 2003 at 10:28:55AM +0530, Manav Bhatia wrote: > Delivered-To: idr-outgoing@trapdoor.merit.edu > Delivered-To: idr@trapdoor.merit.edu > Delivered-To: idr@merit.edu > Date: Fri, 14 Feb 2003 10:28:55 +0530 > From: Manav Bhatia > Subject: Re: Next-Hop in IPv6 only environment > To: Enke Chen > Cc: Jeffrey Haas , mjh@icir.org, idr@merit.edu > Reply-To: Manav Bhatia > X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 > X-Mailer: Microsoft Outlook Express 6.00.2720.3000 > X-Priority: 3 > X-MSMail-priority: Normal > Precedence: bulk > X-Spam-Status: No, hits=0.1 required=5.0 > tests=AWL,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, > USER_AGENT_OE > version=2.43 > X-OriginalArrivalTime: 14 Feb 2003 04:59:52.0087 (UTC) FILETIME=[E876DA70:01C2D3E5] > > Enke, > > > An UPDATE message that carries no NLRI, other than the one encoded in > > the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute. > > If such a message contains the NEXT_HOP attribute, the BGP speaker > > that receives the message should ignore this attribute. > > Yes it indeed is. > > However it would be really nice if a similar thing is mentioned somewhere > in the base spec too OR once again, a pointer to the fact that NEXT_HOP > attribute is not always *mandatory* is mentioned to remove any later > confusions amongst the implementers. > > I have a gut feeling that this issue will crop up again some time later > down the line. The confusion will be all the more aggravated when your base > spec RFC is greater than your extensions RFC nos. > > Thanks, > Manav > > P.S. > Once again, the issue isn't that RFC 2858 isn't clear .. its just that it > defies what the base spec mandates any implementation to do! > > It just gets all the more skewed when the base spec is more recent than the > extensions draft/RFC! > :-) From owner-idr@merit.edu Mon Feb 24 15:42:35 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25974 for ; Mon, 24 Feb 2003 15:42:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 86AF29124B; Mon, 24 Feb 2003 15:46:20 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 39EDA9124F; Mon, 24 Feb 2003 15:46: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 B94C09124B for ; Mon, 24 Feb 2003 15:46:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 17DCF5E00F; Mon, 24 Feb 2003 15:46:01 -0500 (EST) Delivered-To: idr@merit.edu Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id AA76B5DE5B for ; Mon, 24 Feb 2003 15:45:57 -0500 (EST) Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id MAA24068; Mon, 24 Feb 2003 12:42:40 -0800 (PST) Date: Mon, 24 Feb 2003 12:42:40 -0800 From: andrewl@xix-w.bengi.exodus.net To: Susan Hares Cc: Manav Bhatia , Enke Chen , Jeffrey Haas , mjh@icir.org, idr@merit.edu Subject: Re: Next-Hop in IPv6 only environment Message-ID: <20030224124240.E5760@demiurge.exodus.net> 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 shares@nexthop.com on Mon, Feb 24, 2003 at 02:01:14PM -0500 Sender: owner-idr@merit.edu Precedence: bulk Sue, The paragaph below would be part of the base spec. I don't think it would violate the charter, since it would basically say "if you are interested in bgp foo, look in the bgp foo document, since bgp foo is beyond the scope of this document". However, I certainly do NOT want to hold up the process. I proposed that text because there was some indication on the list that it was not clear how the BGP specifications interrelated. I was trying to take the view of someone who was not a list veteren and was reading the BGP documents for the first time. If you, as the document editor, feel that this is not necessary, I'm happy to defer to your editorial judgement on this. Andrew > Andrew: > > My understanding from the ADs is that > we are completing the Base specification > first without any additions. > > After we have completed the 1st version of > the base specification, I believe the ADs > will re-open the charter to these additions. > It is my understanding that we will deal > with IPv6 issues after this point. > > Yakov, Bill and Alex - am I correct? > > Sue Hares > > -----Original Message----- > From: andrewl@xix-w.bengi.exodus.net > [mailto:andrewl@xix-w.bengi.exodus.net] > Sent: Saturday, February 22, 2003 6:28 PM > To: Manav Bhatia > Cc: Enke Chen; Jeffrey Haas; mjh@icir.org; idr@merit.edu > Subject: Re: Next-Hop in IPv6 only environment > > > Going through the entire base spec and adding a caveat in every place where > an extention document modifies it, is almost as much work as documenting all the > varriant behavior in the base spec. > > If there is confusion on this issue, I would suggest we add a statement > like this: > > This document specifies the base behavior of the BGP protocol. This > behavior can and is modified by extention specifications. When the > protocol is extended the new behavior is fully documented in the > extention specifications. > > to the beginning of the document somewhere. > > Andrew > > On Fri, Feb 14, 2003 at 10:28:55AM +0530, Manav Bhatia wrote: > > Delivered-To: idr-outgoing@trapdoor.merit.edu > > Delivered-To: idr@trapdoor.merit.edu > > Delivered-To: idr@merit.edu > > Date: Fri, 14 Feb 2003 10:28:55 +0530 > > From: Manav Bhatia > > Subject: Re: Next-Hop in IPv6 only environment > > To: Enke Chen > > Cc: Jeffrey Haas , mjh@icir.org, idr@merit.edu > > Reply-To: Manav Bhatia > > X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 > > X-Mailer: Microsoft Outlook Express 6.00.2720.3000 > > X-Priority: 3 > > X-MSMail-priority: Normal > > Precedence: bulk > > X-Spam-Status: No, hits=0.1 required=5.0 > > tests=AWL,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, > > USER_AGENT_OE > > version=2.43 > > X-OriginalArrivalTime: 14 Feb 2003 04:59:52.0087 (UTC) FILETIME=[E876DA70:01C2D3E5] > > > > Enke, > > > > > An UPDATE message that carries no NLRI, other than the one encoded in > > > the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute. > > > If such a message contains the NEXT_HOP attribute, the BGP speaker > > > that receives the message should ignore this attribute. > > > > Yes it indeed is. > > > > However it would be really nice if a similar thing is mentioned somewhere > > in the base spec too OR once again, a pointer to the fact that NEXT_HOP > > attribute is not always *mandatory* is mentioned to remove any later > > confusions amongst the implementers. > > > > I have a gut feeling that this issue will crop up again some time later > > down the line. The confusion will be all the more aggravated when your base > > spec RFC is greater than your extensions RFC nos. > > > > Thanks, > > Manav > > > > P.S. > > Once again, the issue isn't that RFC 2858 isn't clear .. its just that it > > defies what the base spec mandates any implementation to do! > > > > It just gets all the more skewed when the base spec is more recent than the > > extensions draft/RFC! > > :-) From owner-idr@merit.edu Tue Feb 25 09:18:51 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01724 for ; Tue, 25 Feb 2003 09:18:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2EFAC91249; Tue, 25 Feb 2003 09:22:35 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EAA0A9124D; Tue, 25 Feb 2003 09:22:34 -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 BC28391249 for ; Tue, 25 Feb 2003 09:22:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8F7AE5DFA5; Tue, 25 Feb 2003 09:22:33 -0500 (EST) Delivered-To: idr@merit.edu Received: from web20309.mail.yahoo.com (web20309.mail.yahoo.com [216.136.226.90]) by segue.merit.edu (Postfix) with SMTP id F35805DF4A for ; Tue, 25 Feb 2003 09:22:32 -0500 (EST) Message-ID: <20030225142232.50072.qmail@web20309.mail.yahoo.com> Received: from [203.200.20.226] by web20309.mail.yahoo.com via HTTP; Tue, 25 Feb 2003 06:22:32 PST Date: Tue, 25 Feb 2003 06:22:32 -0800 (PST) From: Mareline Sheldon Subject: Re: MED in practise To: idr@merit.edu Cc: danny@tcb.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Danny, > If you replace "destination" with NEXT_HOP, sure... I'm sorry .. that is what i had meant ! > > > If this is done then the ISP which is connected to two other ISPs > > can decide amongst the better one by choosing the lower MED advertised > > by both and sending all the traffic through it! > > Sure, and thereby always selecting the ISP with the metric allocation > policy that results in lower values for IGP metrics. Or, perhaps always > selecting the ISP with the IGP that provides a smaller range of available > metrics (e.g., IS-IS pre-deployment/"wide metrics"). This is a little unclear to me ... AFAIK till some time IS-IS would only support narrow metrics (the WIDE metrics extensions just came about some time back!). This way the MED advertised by an AS running IS-IS would always be smaller than one running OSPF .. which would cause the upstream ISP to always select the AS running IS-IS. This is rather unfair for an ISP running OSPF in its network !!! (Atleast in theory!) > I've seen MEDs work as prescribed in many scenarios. However, be wary: > > o aggregation breaks MEDs How? Can you give me one example? > o comparing MEDs between different ASs with different policies > isn't typically a good idea > o MEDs are a primary trigger of route oscillation > o MEDs often result in superfluous route advertisements per > IGP link/node/cost changes Is this coz some IGP cost would change and we would re-advertise our BGP Updates with that new MED i.e. if we are directly importing IGP costs into BGP as MED! Isnt it? > o Most notably, accepting MEDs from peers can have a visible impact on the > economics of carrying bits, depending on which network is carrying traffic, > how far, etc.. > > Also note that while many service providers send (often by request only) and > accept MEDs from customers, they typically reset MEDs to some fixed value on > routes learned from peers. This would solve most of the problems !! Thanks a lot! Mareline S. __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-idr@merit.edu Tue Feb 25 11:04:10 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04643 for ; Tue, 25 Feb 2003 11:04:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F0AB09125E; Tue, 25 Feb 2003 11:07:54 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE5A791262; Tue, 25 Feb 2003 11:07: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 50DE39125E for ; Tue, 25 Feb 2003 11:07:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C73A5DE0D; Tue, 25 Feb 2003 11:07:52 -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 BF4E85DDA7 for ; Tue, 25 Feb 2003 11:07:51 -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 h1PG7WS85809; Tue, 25 Feb 2003 08:07:32 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200302251607.h1PG7WS85809@merlot.juniper.net> To: "Susan Hares" Cc: andrewl@xix-w.bengi.exodus.net, "Manav Bhatia" , "Enke Chen" , "Jeffrey Haas" , mjh@icir.org, idr@merit.edu Subject: Re: Next-Hop in IPv6 only environment In-Reply-To: Your message of "Mon, 24 Feb 2003 14:01:14 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22419.1046189252.1@juniper.net> Date: Tue, 25 Feb 2003 08:07:32 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Sue, > Andrew: > > My understanding from the ADs is that > we are completing the Base specification > first without any additions. > > After we have completed the 1st version of > the base specification, I believe the ADs > will re-open the charter to these additions. > It is my understanding that we will deal > with IPv6 issues after this point. > > Yakov, Bill and Alex - am I correct? I think that adding the text suggested by Andrew would be fine. Yakov. > > Sue Hares > > -----Original Message----- > From: andrewl@xix-w.bengi.exodus.net > [mailto:andrewl@xix-w.bengi.exodus.net] > Sent: Saturday, February 22, 2003 6:28 PM > To: Manav Bhatia > Cc: Enke Chen; Jeffrey Haas; mjh@icir.org; idr@merit.edu > Subject: Re: Next-Hop in IPv6 only environment > > > Going through the entire base spec and adding a caveat in every place where > an extention document modifies it, is almost as much work as documenting all the > varriant behavior in the base spec. > > If there is confusion on this issue, I would suggest we add a statement > like this: > > This document specifies the base behavior of the BGP protocol. This > behavior can and is modified by extention specifications. When the > protocol is extended the new behavior is fully documented in the > extention specifications. > > to the beginning of the document somewhere. > > Andrew > > On Fri, Feb 14, 2003 at 10:28:55AM +0530, Manav Bhatia wrote: > > Delivered-To: idr-outgoing@trapdoor.merit.edu > > Delivered-To: idr@trapdoor.merit.edu > > Delivered-To: idr@merit.edu > > Date: Fri, 14 Feb 2003 10:28:55 +0530 > > From: Manav Bhatia > > Subject: Re: Next-Hop in IPv6 only environment > > To: Enke Chen > > Cc: Jeffrey Haas , mjh@icir.org, idr@merit.edu > > Reply-To: Manav Bhatia > > X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 > > X-Mailer: Microsoft Outlook Express 6.00.2720.3000 > > X-Priority: 3 > > X-MSMail-priority: Normal > > Precedence: bulk > > X-Spam-Status: No, hits=0.1 required=5.0 > > tests=AWL,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, > > USER_AGENT_OE > > version=2.43 > > X-OriginalArrivalTime: 14 Feb 2003 04:59:52.0087 (UTC) FILETIME=[E876DA70:0 1C2D3E5] > > > > Enke, > > > > > An UPDATE message that carries no NLRI, other than the one encoded in > > > the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute. > > > If such a message contains the NEXT_HOP attribute, the BGP speaker > > > that receives the message should ignore this attribute. > > > > Yes it indeed is. > > > > However it would be really nice if a similar thing is mentioned somewhere > > in the base spec too OR once again, a pointer to the fact that NEXT_HOP > > attribute is not always *mandatory* is mentioned to remove any later > > confusions amongst the implementers. > > > > I have a gut feeling that this issue will crop up again some time later > > down the line. The confusion will be all the more aggravated when your base > > spec RFC is greater than your extensions RFC nos. > > > > Thanks, > > Manav > > > > P.S. > > Once again, the issue isn't that RFC 2858 isn't clear .. its just that it > > defies what the base spec mandates any implementation to do! > > > > It just gets all the more skewed when the base spec is more recent than the > > extensions draft/RFC! > > :-) From owner-idr@merit.edu Tue Feb 25 11:26:07 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05357 for ; Tue, 25 Feb 2003 11:26:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 727DD91262; Tue, 25 Feb 2003 11:29:51 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4026591267; Tue, 25 Feb 2003 11:29: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 29FBF91262 for ; Tue, 25 Feb 2003 11:29:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0416F5E1F4; Tue, 25 Feb 2003 11:29:50 -0500 (EST) Delivered-To: idr@merit.edu Received: from nomad.tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by segue.merit.edu (Postfix) with ESMTP id C93585DD9D for ; Tue, 25 Feb 2003 11:29:49 -0500 (EST) Received: by nomad.tcb.net (Postfix, from userid 500) id C0D1155F62; Tue, 25 Feb 2003 09:30:22 -0700 (MST) Received: from nomad.tcb.net (localhost [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id BE1E23E83 for ; Tue, 25 Feb 2003 09:30:22 -0700 (MST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: MED in practise Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Feb 2003 09:30:17 -0700 Message-Id: <20030225163022.C0D1155F62@nomad.tcb.net> Sender: owner-idr@merit.edu Precedence: bulk > This is a little unclear to me ... AFAIK till some time IS-IS would > only support narrow metrics (the WIDE metrics extensions just came about > some time back!). This way the MED advertised by an AS running IS-IS > would always be smaller than one running OSPF .. which would > cause the upstream ISP to always select the AS running IS-IS. > > This is rather unfair for an ISP running OSPF in its network !!! > (Atleast in theory!) Indeed. Of benefit or unfair, depending on where you sit. > > I've seen MEDs work as prescribed in many scenarios. However, be wary: > > > > o aggregation breaks MEDs > > How? Can you give me one example? Many service providers only announce their aggregates from redundantly- connected core routers in order to avoid blackholing traffic (e.g., if an edge were announcing them and became isolated). The announcements for the aggregates are often sourced from many (or even all) core routers, so the metric that's used to derive the MED value is the IGP cost from the edge to the local core router, and is often a fixed value between all edge-core connections. Peers then employ the MED associated with the aggregate to reach some specific network within the aggregate. This can result in making bad routing decisions that without MED would have been much more optimal. It'd work OK if the more specifics and MEDs associated associated with internal NEXT_HOPS were made available to the peer, but this isn't a viable alternative. > Is this coz some IGP cost would change and we would re-advertise > our BGP Updates with that new MED i.e. if we are directly importing > IGP costs into BGP as MED! Isnt it? Yes, so link flaps, new metrics, etc.. that would otherwise remain internal now result in new external BGP updates, per "dynamically derived" MEDs. -danny From owner-idr@merit.edu Tue Feb 25 11:51:20 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06218 for ; Tue, 25 Feb 2003 11:51:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B525E91267; Tue, 25 Feb 2003 11:55:04 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C66B91269; Tue, 25 Feb 2003 11:55: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 1968391267 for ; Tue, 25 Feb 2003 11:55:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1C8B85DE6F; Tue, 25 Feb 2003 11:55:02 -0500 (EST) Delivered-To: idr@merit.edu Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 6AE6F5DDBC for ; Tue, 25 Feb 2003 11:55:00 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA14107; Tue, 25 Feb 2003 11:54:02 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302251654.LAA14107@workhorse.fictitious.org> To: Yakov Rekhter Cc: "Susan Hares" , andrewl@xix-w.bengi.exodus.net, "Manav Bhatia" , "Enke Chen" , "Jeffrey Haas" , mjh@icir.org, idr@merit.edu Reply-To: curtis@fictitious.org Subject: Re: Next-Hop in IPv6 only environment In-reply-to: Your message of "Tue, 25 Feb 2003 08:07:32 PST." <200302251607.h1PG7WS85809@merlot.juniper.net> Date: Tue, 25 Feb 2003 11:54:02 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <200302251607.h1PG7WS85809@merlot.juniper.net>, Yakov Rekhter writes : > > > > My understanding from the ADs is that > > we are completing the Base specification > > first without any additions. > > > > After we have completed the 1st version of > > the base specification, I believe the ADs > > will re-open the charter to these additions. > > It is my understanding that we will deal > > with IPv6 issues after this point. > > > > Yakov, Bill and Alex - am I correct? > > I think that adding the text suggested by Andrew would be fine. > > Yakov. A worthwhile clarification since it keeps coming up on the list. I agree that it is worth adding Andrew's text either to the front or as an additional "Protocol Extensions" appendix at the very end. Curtis > > If there is confusion on this issue, I would suggest we add a statement > > like this: > > > > This document specifies the base behavior of the BGP protocol. This > > behavior can and is modified by extention specifications. When the > > protocol is extended the new behavior is fully documented in the > > extention specifications. > > > > to the beginning of the document somewhere. > > > > Andrew From owner-idr@merit.edu Tue Feb 25 12:06:34 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06597 for ; Tue, 25 Feb 2003 12:06:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DDE6291269; Tue, 25 Feb 2003 12:10:18 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D54C9126A; Tue, 25 Feb 2003 12:10: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 54F9F91269 for ; Tue, 25 Feb 2003 12:10:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 33D005DDBC; Tue, 25 Feb 2003 12:10:16 -0500 (EST) Delivered-To: idr@merit.edu Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id E8BAF5DD9D for ; Tue, 25 Feb 2003 12:10:15 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18niaj-000PA4-00; Tue, 25 Feb 2003 09:10:05 -0800 Date: Tue, 25 Feb 2003 09:09:41 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <92128389073.20030225090941@psg.com> To: Curtis Villamizar Cc: Yakov Rekhter , "Susan Hares" , andrewl@xix-w.bengi.exodus.net, "Manav Bhatia" , "Enke Chen" , "Jeffrey Haas" , , Subject: Re: Next-Hop in IPv6 only environment In-Reply-To: <200302251654.LAA14107@workhorse.fictitious.org> References: <200302251654.LAA14107@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit While something like this definitely wouldn't harm the spec, I don't think it is really required--a situation where the base spec is more recent than the extensions is absolutely normal and happens quite often. A higher number of the base RFC does not mean it obsoletes the extension spec, whatever RFC number that is. Example: OSPFv2 spec: RFC2328; the demand circuit extension to it suppressing Hello's on a link: RFC1793... and no disclaimers that extensions may modify the described behavior, and no confusion :) Then again, it's a minor question. If you guys believe it's a good idea to have something like this in the text--sure. -- Alex Tuesday, February 25, 2003, 8:54:02 AM, Curtis Villamizar wrote: > In message <200302251607.h1PG7WS85809@merlot.juniper.net>, Yakov Rekhter writes > : >> > >> > My understanding from the ADs is that >> > we are completing the Base specification >> > first without any additions. >> > >> > After we have completed the 1st version of >> > the base specification, I believe the ADs >> > will re-open the charter to these additions. >> > It is my understanding that we will deal >> > with IPv6 issues after this point. >> > >> > Yakov, Bill and Alex - am I correct? >> >> I think that adding the text suggested by Andrew would be fine. >> >> Yakov. > A worthwhile clarification since it keeps coming up on the list. I > agree that it is worth adding Andrew's text either to the front or as > an additional "Protocol Extensions" appendix at the very end. > Curtis >> > If there is confusion on this issue, I would suggest we add a statement >> > like this: >> > >> > This document specifies the base behavior of the BGP protocol. This >> > behavior can and is modified by extention specifications. When the >> > protocol is extended the new behavior is fully documented in the >> > extention specifications. >> > >> > to the beginning of the document somewhere. >> > >> > Andrew From owner-idr@merit.edu Tue Feb 25 17:55:08 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20629 for ; Tue, 25 Feb 2003 17:55:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 13ECA91272; Tue, 25 Feb 2003 17:58:53 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF99891273; Tue, 25 Feb 2003 17:58:52 -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 4BD9991272 for ; Tue, 25 Feb 2003 17:58:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 273075DEF4; Tue, 25 Feb 2003 17:58:51 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 7D13A5DED8 for ; Tue, 25 Feb 2003 17:58:50 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.11.3/8.11.1) id h1PMwnL81282 for idr@merit.edu; Tue, 25 Feb 2003 17:58:49 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.nexthop.com (8.11.3/8.11.1) with ESMTP id h1PMwh581269 for ; Tue, 25 Feb 2003 17:58:43 -0500 (EST) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Open FSM issues X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 25 Feb 2003 17:58:43 -0500 Message-ID: Thread-Topic: Open FSM issues Thread-Index: AcLdIXGj2wgW12mJQxqxWp03eFh4ug== From: "Susan Hares" To: Cc: X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA20629 Here's the current open issues (please check Andrew): - 24 - consensus, no change (Siva agrees) - 26 - consensus, I added a new event per Siva request, see text below - 33 - Yakov and Sue declare consensus, stay with current text - 41 - Old event 14 is now optional based on the Track TCP flag - 42 - I accept Tom's text with the additions to make send the Notification based on a new optional attribute in Connect and Open Sent - 44 - Now event 24 (due to issue 26) I accept Tom's solution and I'll put the text in Connect and Open Sent - 45 - Event 18 (due to issue 26) in Connect State - I accept Tom's solution and I'll put the text below in connect state. - 52 - Yakov and Sue declare consensus, no changes - 54 - consensus, I'll accept Tom's comments and put in comment below in section 8.1.3 Please consider these items closed. Sue Hares =============== Event 26 Event 7: Automatic start with bgp_stop flap option set and passive TCP establishment option set Definition: Local system automatically starts the BGP peer connection with peer oscillation damping enabled and passive TCP establishment enabled. The exact method of damping persistent peer oscillations is left up to the implementation, and is outside the scope of this document. Status: Optional, used only if the bgp peer has enabled bgp peer oscillation damping with following optional flags settings below. Optional attributes: 1) Perform automatic start flag SHOULD be set 2) BGP stop_peer_flap flag SHOULD be set I've re-ordered the Timer events to keep the text changes down to a minimum. action 9 - connect retry timer action 10 - Hold Timer expires action 11 - Keepalive timer expires action 13 - Open Delay timer expires action 14 - Idle Hold timer expires All other events are incremented by 1 ================== Issue 42 New text in optional section: Next text in If BGP message header checking detects an error [Event 21] or Open message checking detects an error [Event 22] (see section 6.2), the local system: - (optionally) If the Notification without OPen flag is set and sends a NOTIFICATION message with the appropriate error code, - resets the connect retry timer (sets to zero), - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, - [optionally] performs peer oscillation damping, - and goes to Idle. =========== Issue 44 If a NOTIFICATION message is received with a version error[Event24], the local system checks the Open Delay timer. If the Open Delay timer is running, the local system: - resets the connect retry timer (sets to zero), - stops and reset the Open Delay timer (sets to zero, - releases all BGP resources, - drops the TCP connection, - changes its state to Idle. If the Open Delay timer is not running, the local system: - resets the connect retry timer (sets to zero), - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, - optionally performs peer oscillation damping, and - changes its state to Idle. ------------ issue 45 text If the TCP connection fails [Event18], the local system checks the Open Delay Timer. If the Open Delay timer is running, the local system: - restarts the connect retry timer, - stops the Open Delay timer and resets value to zero, - continues to listen for a connection that may be initiated by the remote BGP peer, and - changes its state to Active. If the open Delay timer is not running, the locla system: - resets the connect retry timer (sets to zero), and - Drops the TCP connection, - Releases all BGP resources, - and goes to Idle State. issue 52 -------- 8.2.1.3 FSM and Optional Attributes .sp .in4 Optional Attributes specify either flags that augment the normal processing of the BGP FSM, or optional timers. If a Optional attribute can be set on a system, the Events and the BGP FSM actions must be support. For example, if the following options can be set in a BGP implementation: AutoStart and Passive TCP connection Establishment flag, then the events 3, 4 and 5 must be supported. .sp .in 4 If an Optional attribute is cannot be set (that is declared always off logically), the events supporting that set of options do not have to be supported. From owner-idr@merit.edu Wed Feb 26 00:40:09 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29600 for ; Wed, 26 Feb 2003 00:40:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 29C629127E; Wed, 26 Feb 2003 00:43:54 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB98E9127F; Wed, 26 Feb 2003 00:43: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 B8FC29127E for ; Wed, 26 Feb 2003 00:43:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8B5665DEAA; Wed, 26 Feb 2003 00:43:52 -0500 (EST) Delivered-To: idr@merit.edu Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 2FAB95DD91 for ; Wed, 26 Feb 2003 00:43:52 -0500 (EST) Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id VAA17797; Tue, 25 Feb 2003 21:40:52 -0800 (PST) Date: Tue, 25 Feb 2003 21:40:52 -0800 From: andrewl@xix-w.bengi.exodus.net To: Susan Hares Cc: idr@merit.edu, yakov@juniper.net Subject: Re: Open FSM issues Message-ID: <20030225214052.K5760@demiurge.exodus.net> 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 shares@nexthop.com on Tue, Feb 25, 2003 at 05:58:43PM -0500 Sender: owner-idr@merit.edu Precedence: bulk Sue, I've updated the issues' list and what is below generally jives with what I have, exceptions are noted below: > Here's the current open issues (please check Andrew): > > - 24 - consensus, no change (Siva agrees) > - 26 - consensus, I added a new event per Siva request, see text below > - 33 - Yakov and Sue declare consensus, stay with current text > - 41 - Old event 14 is now optional based on the Track TCP flag > - 42 - I accept Tom's text with the additions to make > send the Notification based on a new optional attribute > in Connect and Open Sent > > - 44 - Now event 24 (due to issue 26) I accept Tom's solution and > I'll put the text in Connect and Open Sent I assume, you mean Siva's solution? I didn't see Tom's comments in the issue log, although I could have missed something. The issue has been updated as at consensus, with the text you've supplied below. > - 45 - Event 18 (due to issue 26) in Connect State - I accept Tom's solution and > I'll put the text below in connect state. > > - 52 - Yakov and Sue declare consensus, no changes I added the text you have below, section 8.2.1.3 to the issues list. I'm not sure that this completely resolves the original issue, which focused on when we need to start the Keepalive timer, however, since there have been a lot of changes to the FSM, let's call it at consensus, and we if a problem remains we can address it then. Also, with this issue, am I correct to assume that the text that issue 12 produced with regard to keepalive timers, which is also quoted here will remain in the document? Specifically this text is: Change 1: new text Active state - event 19 If an Open is received with the Open Delay timer is running [Event 19], the local system - clears the connect retry timer (cleared to zero), - stops and clears the Open Delay timer - completes the BGP initialization, - stops and clears the Open Delay timer - sends an OPEN message, - send a Keepalive message, - if the hold timer value is non-zero, - starts the keepalive timer to initial value, - resets the hold timer to the negotiated value, else if the hold timer is zero - resets the keepalive timer (set to zero), - resets the hold timer to zero. - changes its state to OpenConfirm. If the value of the autonomous system field is the same as the local Autonomous System number, set the connection status to an internal connection; otherwise it is "external". > - 54 - consensus, I'll accept Tom's comments and put in comment below > in section 8.1.3 Also, here I don't have Tom's comments in the log. Do we have text for this? > Please consider these items closed. > << snipped >> > issue 52 > -------- > > 8.2.1.3 FSM and Optional Attributes > .sp > .in4 > Optional Attributes specify either flags that augment the normal > processing of the BGP FSM, or optional timers. If a Optional > attribute can be set on a system, the Events and the BGP FSM actions > must be support. For example, if the following options can > be set in a BGP implementation: AutoStart and Passive TCP connection > Establishment flag, then the events 3, 4 and 5 must be supported. > .sp > .in 4 > If an Optional attribute is cannot be set (that is declared always off ^^ --> typo?? Updated the issue, without the "is" above. > logically), the events supporting that set of options do not > have to be supported. Andrew From owner-idr@merit.edu Wed Feb 26 04:46:39 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29293 for ; Wed, 26 Feb 2003 04:46:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3BB1C91234; Wed, 26 Feb 2003 04:50:24 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F17CB9123A; Wed, 26 Feb 2003 04:50:23 -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 9A2E091234 for ; Wed, 26 Feb 2003 04:50:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 866E85DDD0; Wed, 26 Feb 2003 04:50:22 -0500 (EST) Delivered-To: idr@merit.edu Received: from pengo.systems.pipex.net (pengo.systems.pipex.net [62.241.160.193]) by segue.merit.edu (Postfix) with ESMTP id 2F0745DDC8 for ; Wed, 26 Feb 2003 04:50:22 -0500 (EST) Received: from tom3 (userbm66.uk.uudial.com [62.188.145.18]) by pengo.systems.pipex.net (Postfix) with SMTP id DA4334C0032B; Wed, 26 Feb 2003 09:50:18 +0000 (GMT) Message-ID: <00a301c2dd7c$29d1e560$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: , "Susan Hares" Cc: , Subject: Re: Open FSM issues Date: Wed, 26 Feb 2003 09:47:15 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I still have open issues with next states. Connect state event 14 has no next state; the discussion became one of what action to take (issue13.2) with proposals for going to Active or staying in Connect and I am not clear from the issue list what the answer is. Likewise Active state events 13 and14, the discussion became (Issue 13.4) should the events be optional? Don't care but whether they are or are not optional, the fsm needs a next state and I do not see it in the issue list. Tom Petch nwnetworks@dial.pipex.com -----Original Message----- From: andrewl@xix-w.bengi.exodus.net To: Susan Hares Cc: idr@merit.edu ; yakov@juniper.net Date: 26 February 2003 05:44 Subject: Re: Open FSM issues >Sue, > >I've updated the issues' list and what is below generally jives with what >I have, exceptions are noted below: > >> Here's the current open issues (please check Andrew): >> >> - 24 - consensus, no change (Siva agrees) >> - 26 - consensus, I added a new event per Siva request, see text below >> - 33 - Yakov and Sue declare consensus, stay with current text >> - 41 - Old event 14 is now optional based on the Track TCP flag >> - 42 - I accept Tom's text with the additions to make >> send the Notification based on a new optional attribute >> in Connect and Open Sent >> >> - 44 - Now event 24 (due to issue 26) I accept Tom's solution and >> I'll put the text in Connect and Open Sent > >I assume, you mean Siva's solution? I didn't see Tom's comments in the >issue log, although I could have missed something. The issue has been updated >as at consensus, with the text you've supplied below. > >> - 45 - Event 18 (due to issue 26) in Connect State - I accept Tom's solution and >> I'll put the text below in connect state. >> >> - 52 - Yakov and Sue declare consensus, no changes > >I added the text you have below, section 8.2.1.3 to the issues list. I'm >not sure that this completely resolves the original issue, which focused >on when we need to start the Keepalive timer, however, since there have been >a lot of changes to the FSM, let's call it at consensus, and we if a problem >remains we can address it then. > >Also, with this issue, am I correct to assume that the text that issue 12 >produced with regard to keepalive timers, which is also quoted here will >remain in the document? Specifically this text is: > > Change 1: new text > > Active state - event 19 > > If an Open is received with the Open Delay timer is > running [Event 19], the local system > - clears the connect retry timer (cleared to zero), > - stops and clears the Open Delay timer > - completes the BGP initialization, > - stops and clears the Open Delay timer > - sends an OPEN message, > - send a Keepalive message, > - if the hold timer value is non-zero, > - starts the keepalive timer to initial value, > - resets the hold timer to the negotiated value, > else if the hold timer is zero > - resets the keepalive timer (set to zero), > - resets the hold timer to zero. > > - changes its state to OpenConfirm. > > If the value of the autonomous system field is the same as the local > Autonomous System number, set the connection status to an internal > connection; otherwise it is "external". > >> - 54 - consensus, I'll accept Tom's comments and put in comment below >> in section 8.1.3 > >Also, here I don't have Tom's comments in the log. Do we have text for this? > >> Please consider these items closed. >> > ><< snipped >> > >> issue 52 >> -------- >> >> 8.2.1.3 FSM and Optional Attributes >> .sp >> .in4 >> Optional Attributes specify either flags that augment the normal >> processing of the BGP FSM, or optional timers. If a Optional >> attribute can be set on a system, the Events and the BGP FSM actions >> must be support. For example, if the following options can >> be set in a BGP implementation: AutoStart and Passive TCP connection >> Establishment flag, then the events 3, 4 and 5 must be supported. >> .sp >> .in 4 >> If an Optional attribute is cannot be set (that is declared always off > ^^ --> typo?? > >Updated the issue, without the "is" above. > >> logically), the events supporting that set of options do not >> have to be supported. > >Andrew From owner-idr@merit.edu Wed Feb 26 08:12:31 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03346 for ; Wed, 26 Feb 2003 08:12:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C5E069126B; Wed, 26 Feb 2003 08:16:01 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 873EC91274; Wed, 26 Feb 2003 08:16: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 D71449126B for ; Wed, 26 Feb 2003 08:15:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id B3BC05DF91; Wed, 26 Feb 2003 08:15:54 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id C73F15DE76 for ; Wed, 26 Feb 2003 08:15:53 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.11.3/8.11.1) id h1QDFrC95141 for idr@merit.edu; Wed, 26 Feb 2003 08:15:53 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.nexthop.com (8.11.3/8.11.1) with ESMTP id h1QDFl595124 for ; Wed, 26 Feb 2003 08:15:47 -0500 (EST) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: FW: Open FSM issues X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 26 Feb 2003 08:15:46 -0500 Message-ID: Thread-Topic: Open FSM issues Thread-Index: AcLdIXGj2wgW12mJQxqxWp03eFh4ugAd1ZkA From: "Susan Hares" To: Cc: X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA03346 Andrew: Please note that issue 54 was included below, but mis-numbered as 52. I will be sending the draft FSM text to Yakov once I get your final list. Sue Hares > -----Original Message----- > From: Susan Hares > Sent: Tuesday, February 25, 2003 5:59 PM > To: 'idr@merit.edu' > Cc: 'yakov@juniper.net' > Subject: Open FSM issues > > > Here's the current open issues (please check Andrew): > > - 24 - consensus, no change (Siva agrees) > - 26 - consensus, I added a new event per Siva request, see text below > - 33 - Yakov and Sue declare consensus, stay with current text > - 41 - Old event 14 is now optional based on the Track TCP flag > - 42 - I accept Tom's text with the additions to make > send the Notification based on a new optional attribute > in Connect and Open Sent > > - 44 - Now event 24 (due to issue 26) I accept Tom's solution and > I'll put the text in Connect and Open Sent > > - 45 - Event 18 (due to issue 26) in Connect State - I accept Tom's solution and > I'll put the text below in connect state. > > - 52 - Yakov and Sue declare consensus, no changes > - 54 - consensus, I'll accept Tom's comments and put in comment below > in section 8.1.3 > > Please consider these items closed. > > Sue Hares > > =============== > Event 26 > > > > Event 7: Automatic start with bgp_stop flap option set and passive > TCP establishment option set > > Definition: Local system automatically starts the > BGP peer connection with peer oscillation > damping enabled and passive TCP establishment > enabled. The exact method of damping > persistent peer oscillations is left up to the > implementation, and is outside the scope of > this document. > > Status: Optional, used only if the bgp peer has enabled > bgp peer oscillation damping with following optional flags > settings below. > > Optional > attributes: 1) Perform automatic start flag SHOULD be set > 2) BGP stop_peer_flap flag SHOULD be set > > I've re-ordered the Timer events to keep the text changes down > to a minimum. > > action 9 - connect retry timer > action 10 - Hold Timer expires > action 11 - Keepalive timer expires > action 13 - Open Delay timer expires > action 14 - Idle Hold timer expires > > All other events are incremented by 1 > > ================== > > Issue 42 > > New text in optional section: > > Next text in > > If BGP message header checking detects an error [Event 21] or Open message > checking detects an error [Event 22] (see section 6.2), the > local system: > - (optionally) If the Notification without OPen flag is set > and sends a NOTIFICATION message with the appropriate error code, > - resets the connect retry timer (sets to zero), > - releases all BGP resources, > - drops the TCP connection, > - increments the ConnectRetryCnt (connect retry count) by 1, > - [optionally] performs peer oscillation damping, > - and goes to Idle. > > =========== > Issue 44 > > If a NOTIFICATION message is received with a version > error[Event24], the local system checks the Open Delay timer. > If the Open Delay timer is running, the local system: > - resets the connect retry timer (sets to zero), > - stops and reset the Open Delay timer (sets to zero, > - releases all BGP resources, > - drops the TCP connection, > - changes its state to Idle. > If the Open Delay timer is not running, the local system: > - resets the connect retry timer (sets to zero), > - releases all BGP resources, > - drops the TCP connection, > - increments the ConnectRetryCnt (connect retry count) by 1, > - optionally performs peer oscillation damping, and > - changes its state to Idle.> > > ------------ > issue 45 text > > If the TCP connection fails [Event18], the local system checks > the Open Delay Timer. If the Open Delay timer is running, > the local system: > - restarts the connect retry timer, > - stops the Open Delay timer and resets value to zero, > - continues to listen for a connection that may be > initiated by the remote BGP peer, and > - changes its state to Active. > If the open Delay timer is not running, the locla system: > - resets the connect retry timer (sets to zero), and > - Drops the TCP connection, > - Releases all BGP resources, > - and goes to Idle State. > > > issue [Susan Hares] 54 > -------- > > 8.2.1.3 FSM and Optional Attributes > .sp > .in4 > Optional Attributes specify either flags that augment the normal > processing of the BGP FSM, or optional timers. If a Optional > attribute can be set on a system, the Events and the BGP FSM actions > must be support. For example, if the following options can > be set in a BGP implementation: AutoStart and Passive TCP connection > Establishment flag, then the events 3, 4 and 5 must be supported. > .sp > .in 4 > If an Optional attribute is cannot be set (that is declared always off > logically), the events supporting that set of options do not > have to be supported. From owner-idr@merit.edu Wed Feb 26 12:48:58 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17697 for ; Wed, 26 Feb 2003 12:48:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4688D9128E; Wed, 26 Feb 2003 12:52:44 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0FF6E9128F; Wed, 26 Feb 2003 12:52:43 -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 BFA969128E for ; Wed, 26 Feb 2003 12:52:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9685B5E13E; Wed, 26 Feb 2003 12:52:42 -0500 (EST) Delivered-To: idr@merit.edu Received: from ganesh.ctd.hctech.com (Ganesh.hcltech.com [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id 4569B5DF30 for ; Wed, 26 Feb 2003 12:52:41 -0500 (EST) Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Feb 2003 23:22:34 +0530 Message-ID: <60F922ABE8BE9C428E806F43C0EC73680B40E1@HARITHA> From: "Sivananda Ramnath - CTD, Chennai." To: idr@merit.edu Cc: Susan Hares Subject: RE: Open FSM issues Date: Wed, 26 Feb 2003 23:22:32 +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 Hello, > - 42 - I accept Tom's text with the additions to make > send the Notification based on a new > optional attribute > in Connect and Open Sent I don't think this should be optional. When we are in the Connect/Open Sent state with OpenDelay timer running and we identify problems with the OPEN message tat is received, a NOTIFICATION must be sent to the peer to indicate the problem. Failing this may cause connect loops in some circumstances such as version errors. Siva (siva@ctd.hcltech.com) From owner-idr@merit.edu Wed Feb 26 15:41:14 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24337 for ; Wed, 26 Feb 2003 15:40:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D2E2991216; Wed, 26 Feb 2003 15:44:39 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7008E91231; Wed, 26 Feb 2003 15:44: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 09BDF91216 for ; Wed, 26 Feb 2003 15:44:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id CD1705DE91; Wed, 26 Feb 2003 15:44:31 -0500 (EST) Delivered-To: idr@merit.edu Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id A2BE55DDC8 for ; Wed, 26 Feb 2003 15:44:29 -0500 (EST) Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id MAA28591; Wed, 26 Feb 2003 12:41:32 -0800 (PST) Date: Wed, 26 Feb 2003 12:41:32 -0800 From: andrewl@xix-w.bengi.exodus.net To: idr@merit.edu Cc: andrewl@xix-w.bengi.exodus.net Subject: BGP Base Draft - Issue List v2.3 (Draft-19) Message-ID: <20030226124132.N5760@demiurge.exodus.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Izn7cH1Com+I3R9J" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-idr@merit.edu Precedence: bulk --Izn7cH1Com+I3R9J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Greetings, Attached is v2.3 of the issues list, and the associated changelog. As of this moment, all of the issues are at consensus. However, I do know that there are some concerns still extant, and that may result in either issues being reopened, or new issues being added. Andrew --Izn7cH1Com+I3R9J Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="Issue_List-v2.3.txt" 2003-02-26 v2.3 This is version 2.3 of this list. All the 2.x versions pertain to draft-ietf-idr-bgp4-18.txt. The revisions discussed here are targeted to be incorporated into the -19 version of this document. Since late August 2002, there has been a push to get any and all issues with the base spec. resolved so the IDR group can move this draft forward to the IESG. This is a list of the issues that have been brought up regarding the base draft, and the current working group consensus on them. All mistakes are mine, please email me at andrewl@cw.net with corrections. Please include the number and the title of the issue in the subject lines of email discussing that issue. It will help in keeping track. N.B. There is no rhyme or reason to the numbering scheme other than unique tags to address the issues. ============================================================================ Table of Contents ============================================================================ 1) Reference to RFC 1772 2) MUST/SHOULD Capitalization 3) Fix Update Error Subcode 7 -- accidently removed. 4) Section 5.1.4 - Editoral Comment 5) Section 9.1 - Change "all peers" to "peers" 6) AS Loop Detection & Implicit Withdraws 7) Standardize FSM Timer Descriptions 8) FSM MIB enumerations 9) Make "delete routes" language consistant 10) Correct OpenSent and OpenConfirm delete wording 11) Incorrect next state when the delay open timer expires. 12) Entering OpenConfirm / Adding "Stop OpenDelay" action 13) FSM Missing Next States 13.1) FSM Missing Next States - Event 15 or 16 (Connect State) 13.2) FSM Missing Next States - Event 14 (Connect State) 13.3) FSM Missing Next States - Event 15 or 16 (Active State) 13.4) FSM Missing Next States - Event 13-17 (TCP Connection) 13.5) FSM Missing Next States - Event 17 (Connect State) 13.6) FSM Missing Next States - Event 18 (Open Confirm) 14) FSM - Peer Oscillation Damping 15) FSM - Consistant FSM Event Names 16) Many Editorial Comments 17) Section 3, Page 8, Paragraph 3 - Obsolete? 18) MED Removal Text 19) Security Considerations 20) Peer Oscillation Damping 21) Session Attributes - IdleHold Timer 22) Specify New Attributes (Accept Connections/Peer Oscillation Damping) 23) Event1/Event2 Clean Up 24) Events 3, 5, 6 & 7 Give Examples 25) Event 4 & 5 Session Initiation Text 26) Event 4 & 5 - bgp_stop_flap option 27) Event 5 Clarification 28) Timer Events Definition - Make Consistant 29) Event 8 - Clean Up 30) Hold Timer - Split? 31) OpenDelay Timer Definition 32) Definition of TCP Connection Accept (Event 13) 33) Event 13 & 14 - Valid Addresses & Ports 34) Event 17 - TCP Connection Fails to TCP Connection Termination 35) Making Definition Style Consistant 36) Event 19 - Definition Cleanup 37) Event 22 - Cleanup 38) FSM Description - ConnectRetry Count 39) Handling Event 7 (Auto Stop) to Idle State processing 40) Clearing the Connection Retry Timer 41) Handling of Event 14 in the Connect State 42) Handling events 20, 21 in the Connect State and Active State 43) Handling the default events in the Connect state 44) Handling Event 23 in Connect and OpenSent 45) Event 17 in the Connect state 46) Handling of Event 17 in Active state 47) Handling of Event 19 in Active state 48) Handling of Event 2 in Active state 49) Default Event handling in Active state 50) Clearing Hold timer in OpenSent, OpenConfirm and Established State 51) Clearing Keepalive timer in OpenConfirm and Established State 52) Handling Event 18 in the OpenSent state (Keepalive Timer) 53) Established State MIB 54) State impact of not supporting Optional Events 55) New DelayOpen State 56) Clarify what is covered in the base document. ============================================================================ Issues with Consensus ============================================================================ 1) Reference to RFC 1772 2) MUST/SHOULD Capitalization 3) Fix Update Error Subcode 7 -- accidently removed. 4) Section 5.1.4 - Editoral Comment 5) Section 9.1 - Change "all peers" to "peers" 6) AS Loop Detection & Implicit Withdraws 7) Standardize FSM Timer Descriptions 8) FSM MIB enumerations 9) Make "delete routes" language consistant 10) Correct OpenSent and OpenConfirm delete wording 11) Incorrect next state when the delay open timer expires. 12) Entering OpenConfirm / Adding "Stop OpenDelay" action 13) FSM Missing Next States 13.1) FSM Missing Next States - Event 15 or 16 (Connect State) 13.2) FSM Missing Next States - Event 14 (Connect State) 13.3) FSM Missing Next States - Event 15 or 16 (Active State) 13.4) FSM Missing Next States - Event 13-17 (TCP Connection) 13.5) FSM Missing Next States - Event 17 (Connect State) 13.6) FSM Missing Next States - Event 18 (Open Confirm) 14) FSM - Peer Oscillation Damping 15) FSM - Consistent FSM Event Names 16) Many Editorial Comments 17) Section 3, Page 8, Paragraph 3 - Obsolete? 18) MED Removal Text 19) Security Considerations 20) Peer Oscillation Damping 21) Session Attributes - IdleHold Timer 22) Specify New Attributes (Accept Connections/Peer Oscillation Damping) 23) Event1/Event2 Clean Up 24) Events 3, 5, 6 & 7 Give Examples 25) Event 4 & 5 Session Initiation Text 26) Event 4 & 5 - bgp_stop_flap option 27) Event 5 Clarification 28) Timer Events Definition - Make Consistant 29) Event 8 - Clean Up 30) Hold Timer - Split? 31) OpenDelay Timer Definition 32) Definition of TCP Connection Accept (Event 13) 33) Event 13 & 14 - Valid Addresses & Ports 34) Event 17 - TCP Connection Fails to TCP Connection Termination 35) Making Definition Style Consistant 36) Event 19 - Definition Cleanup 37) Event 22 - Cleanup 38) FSM Description - ConnectRetry Count 39) Handling Event 7 (Auto Stop) to Idle State processing 40) Clearing the Connection Retry Timer 41) Handling of Event 14 in the Connect State 42) Handling events 20, 21 in the Connect State and Active State 43) Handling the default events in the Connect state 44) Handling Event 23 in Connect and OpenSent 45) Event 17 in the Connect state 46) Handling of Event 17 in Active state 47) Handling of Event 19 in Active state 48) Handling of Event 2 in Active state 49) Default Event handling in Active state 50) Clearing Hold timer in OpenSent, OpenConfirm and Established State 51) Clearing Keepalive timer in OpenConfirm and Established State 52) Handling Event 18 in the OpenSent state (Keepalive Timer) 53) Established State MIB 54) State impact of not supporting Optional Events 55) New DelayOpen State 56) Clarify what is covered in the base document. ============================================================================ Issues WITHOUT Consensus ============================================================================ ** NONE ** ---------------------------------------------------------------------------- 1) Reference to RFC 1772 ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: Proposed changing RFC 1772 reference, since that document should be updated. Discussion: Jeff proposed that we reconsider referencing RFC 1772, since that document should be updated. Yakov pointed out that this is a non-normative reference and can just be left as is. Jeff agreed that this wasn't a big deal. We are at consensus to leave things as they are. This was discussed in the "-18 last call comments" thread. ---------------------------------------------------------------------------- 2) MUST/SHOULD Capitalization ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Capitalize MUST/SHOULD where appropate. Discussion: Jeff brought this up, and Yakov reponded asking that he point out specific instances where this is needed. Jeff said he would do so, given some time. Yakov later replied that this would be fixed in the -19 version. Jeff replied with a master diff showing the MUST/SHOULDs, for the entire document please see the beginning of the thread entitled: "Issues list, #2: MUST/SHOULD Capitalization" This was discussed in the "18 last call comments" thread. This was also brought up in the "proxy: comments on draft -18" thread. ---------------------------------------------------------------------------- 3) Fix Update Error Subcode 7 -- accidently removed. ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Add error subcode 7 back in, it looks like it was inadvertently removed. Add deprication text to Open Message Error subcode 5. Discussion: Jeff supplied: Update message error subcode 7 is removed. Especially in -18, it looks like an editing mistake based on where it would fall in the editing.. Yakov mentioned that this is addressed in Appendix A. Jeff replied: What I would like to see is something like this: 6 - Invalid ORIGIN Attribute 7 - [Deprecated - See Appendix A] 8 - Invalid NEXT_HOP Attribute As it stands, 7 lies on a page boundary and looks like it got clipped by the roff. Yakov agreed, and also said he would add similar text for Open Message Error subcode 5. This was discussed in the "18 last call comments" thread. ---------------------------------------------------------------------------- 4) Section 5.1.4 - Editoral Comment ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Fix "restricts" to "RESTRICTIONS" Discussion: Jeff proposed an editorial fix. This is agreed to. This was discussed in the "-18 last call comments" thread. ---------------------------------------------------------------------------- 5) Section 9.1 - Change "all peers" to "peers" ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Section 9.1 - Change "all peers" to "peers" Discussion: Jeff proposed: 9.1: The output of the Decision Process is the set of routes that will be advertised to (delete all) peers; the selected routes will be stored in the local speaker's Adj-RIB-Out according to policy. The previous wording implied that routes in the LocRib MUST be placed in the adj-rib-out. Yakov agreed, this fix will be in the next revision. This was discussed in the "-18 last call comments" thread. ---------------------------------------------------------------------------- 6) AS Loop Detection & Implicit Withdraws ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Update the text to reflect the AS Loop detection should be done in the BGP decision process. Discussion: John brought this up, and suggested: I have one further comment just in case it's not perfectly obvious to everyone, which is that "ignore the UPDATE" is not strictly the action you take when receiving a looped update. Rather, you treat it as an implicit withdraw, i.e. you process it as any other update but treat the contained NLRI as unfeasible. I was going to write that this is sufficiently clear from the spec, but I regret to say that it isn't. Here is the fourth paragraph of section 9: The information carried by the AS_PATH attribute is checked for AS loops. AS loop detection is done by scanning the full AS path (as specified in the AS_PATH attribute), and checking that the autonomous system number of the local system does not appear in the AS path. If the autonomous system number appears in the AS path the route may be stored in the Adj-RIB-In, but unless the router is configured to accept routes with its own autonomous system in the AS path, the route shall not be passed to the BGP Decision Process. Operations of a router that is configured to accept routes with its own autonomous system number in the AS path are outside the scope of this document. I don't think this is quite right -- the decision process needs to be run if the looped routes had previously been advertised feasibly on the same session. This could be fixed by hacking the quoted paragraph, but it seems more straightforward to do it by removing the quoted paragraph and making the fix in 9.1.2 Phase 2 instead. This could be done by inserting the following between the third and fourth paragraphs of 9.1.2 Phase 2: If the AS_PATH attribute of a BGP route contains an AS loop, the BGP route should be excluded from the Phase 2 decision function. AS loop detection is done by scanning the full AS path (as specified in the AS_PATH attribute), and checking that the autonomous system number of the local system does not appear in the AS path. Operations of a router that is configured to accept routes with its own autonomous system number in the AS path are outside the scope of this document. Section 9.3, first bullet, also addresses this topic, but I don't think it's sufficient. Yakov agreed that this was a change for the better and will include this in the next revision. We are at consensus on this issue. This is discussed in the "-18 last call comments" thread. ---------------------------------------------------------------------------- 7) Standardize FSM Timer Descriptions ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Standardize the state descriptions on those listed in the discussion section of this issue. Discussion: Tom proposed: I think a standard description would serve us better instead of using the following different ways (which I take all to refer to the same entity): delayBGP open timer BGP delay open timer BGP open delay timer delay open timer BGP delay timer I suggest Open Delay timer (with those capitals) I believe that the corresponding flag is consistently referred to (apart from the capitalisation) as Delay Open flag Yakov agreed with this suggestion, no one else disagreed, we are at consensus. This was discussed in the "BGP18-FSM-terminology" thread. ---------------------------------------------------------------------------- 8) FSM MIB enumerations ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Move MIB references from the base spec into the MIB document. Discussion: Tom pointed out that: The FSM makes several references to putting values into MIB objects and while some of the values are defined, eg FSM error or Hold Timer expired, I can find no definition of the following in any of the BGP documents, MIB or otherwise. connect retry expired TCP disconnect administrative down collision detect closure Call Collision cease collision detected and dump connection Administrative stop I believe an implementation needs to be told these values somewhere and that there should be a reference to that place in bgp18. Jeff replied that to make things easier, the MIB references will be removed from the base spec, and into the MIB document. This was discussed in the "WG Last Call FSM MIB enumeration" thread, and the "bgp18 WG Last Call fsm MIB objects" thread. ---------------------------------------------------------------------------- 9) Make "delete routes" language consistant ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Replace a variety of wording with "deletes all routes associated with this connection,". Discussion: Tom pointed out that we use a variety of language to say how we are going to delete routes in the FSM. He proposed that we instead use: - deletes all routes associated with this connection, This met with agreement, and will be reflected in the next version. This was discussed in the "bgp18 WG Last Call fsm delete action" thread. ---------------------------------------------------------------------------- 10) Correct OpenSent and OpenConfirm delete wording ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Remove delete wording from OpenSent and OpenConfirm states. Discussion: Venu asked why there was delete wording in the OpenSent and OpenConfirm states when a BGP speaker cannot recieve routes in these states. Jeff acknowledged that this was an error. Yakov agreed to fix the next version. This was discussed in the "bgp18 WG Last Call fsm delete action" thread. ---------------------------------------------------------------------------- 11) Incorrect next state when the delay open timer expires. ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Fix the next state. Discussion: Tom pointed out that: I believe that there is an incorrect next state when the delay open timer expires [event 12] in the Active state. The next state should be OpenSent and not OpenConfirm. OpenConfirm is for KeepAlive processing when Open messages have been sent and received. OpenSent is for Open sent and not yet received. The corresponding section in Connect state I believe is correct. Yakov agreed, and will fix this in the next revision. This was discussed in the "bgp18 WG Last CAll fsm incorrect next state" ---------------------------------------------------------------------------- 12) Entering OpenConfirm / Adding "Stop OpenDelay" action ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Add this text: Change 2 - Connect state event 17 (currently defined as going to Active) event 9 (stays in Connect state) new Text: In response to the connect retry timer expires event [Event 9], the local system: - drops the TCP connection, - restarts the connect retry timer, - stops the Open Delay timer and resets the timer to zero, - initiates a TCP connection to the other BGP peer, - continues to listen for a connection that may be initiated by the remote BGP peer, and - stays in Connect state. If the TCP connection fails [Event17], the local system: - restarts the connect retry timer, - stops the Open Delay timer and resets value to zero, - continues to listen for a connection that may be initiated by the remote BGP peer, and - changes its state to Active. Further discussion on Keepalives has been moved to issue 52. Discussion: This discussion began with Tom outlining these two points: When the OpenConfirm state is entered from OpenSent with the receipt of a valid open [Event 18], then a KeepAlive message is sent and the timer is started. When the OpenConfirm state is entered from Active or Connect on receipt of a valid open [Event 19], no message is sent, no timer is started. I believe this inconsistency is an error and should be corrected by adding these two actions in those two places. Sue replied: Just to clarify this comment: Event 19 = valid open with delay timer running Active = 1) awaiting TCP connection, or 2) TCP connection completed and awaiting the TCP connection with delay timer running Case 1: - should not see Event 19 In transition from Active to Open Confirm, the connection must have a TCP connection completed. Case 1 does not have this occurring, so the transition must be avoided. Case 2: - should see Event 19 - Open, Keepalive should be sent. Previous text: (Action H from FSM document) If an Open is received with the BGP Delay Open timer running, [Event 19], the local system: - clears the connect retry timer [cleared to zero), - completes the BGP initialization, - stop and clears the BGP Open Delay timer, - Sends an Open Message, - sets the hold timer to a large value (4 minutes), and - changes its state to an Open Confirm. New text: [a New Action - N-2 : N + BGP keepalive sent] If an Open is received with the BGP Delay Open Timer running [Event 19], the local system: - clear the connect retry timer [cleared to zero], - completes the BGP initialization, - stops and clears the BGP Open Delay timer, - Send an Open message, - Sends a Keepalive message, - If hold timer value is non-zero, - set keepalive timer - hold timer reset to negotiated value else if hold timer is zero, - reset the keepalive timer, and - reset the hold timer. - If the value of the autonomous system field is the same as the local Autonomous system number, set the connection status to a internal connection; otherwise it is "external". Tom and Sue discussed the OpenDelay state, and recalled that this was excluded a number of months ago as not reflecting current practice. By way of clarification, Sue added: 1) Agree, this can occur in the Active state as well as the Connect state. Will you accept the earlier text below to be inserted both places? Background: The state machine for Event 19 is: Idle Connect Active Open Open Estb Sent Confirm =============================================== Event 19 | | | | | | | next state |Idle | Open | Open | Open |Idle | Idle | | | confirm| confirm| Confirm| | | =============================================== action | V | N-2 | N-2 | N | E-1 | E | =============================================== Per the State Machine. Action v - FSM Error Action E - FSM Error, drop connection - etc, drop routes Action E-1 - FSM Error, drop connection (lots of Action N-2 (text below) Action N (text below, without sending Open) 2) Do you think that Event 19 is possible in the Open Sent state? Please answer this separately. Tom replied that: 1) yes I think the same text in both Active and Connect states is a good resolution 2) complicated. As the fsm text stands, Event 19, along with a host of others, takes us back from Open Sent to Idle (I assume on the grounds this is an error condition) which seems very reasonable. But ...in quite a few places, such as Connect state events 2, 7,8,9,10,11, 17, 18, 20 thru 27, we do not stop the OpenDelay timer when going to Idle or Active so we could then go from eg Idle with Manual start [event 1] to Connect to Open Sent all before the OpenDelay timer expires in which case event 19 can occur validly in Open Sent - obscure but possible. (This is also true with Active state and events 2, 17 and the default list at the end). But I think this is an error, and that when exiting Connect state or Active state as listed above, we should have an additional action to stop the OpenDelay timer in which case event 19 in Open Sent becomes an error condition (again). But but but as ever, I cannot speak with authority for implementations and so if implementations do not stop the OpenDelay timer when exiting as above, then Event 19 is valid in Open Sent state - obscure but possible (again). My wish is to add the extra action, stop OpenDelay timer, for the events listed above in Active and Connect states in the expectation that that is what people have or should have implemented. Tom added a reponse to Sue after some other threads have been discussed: You asked if event 19 (Open with OpenDelay timer running) was possible in OpenSent state; I gave a lengthy reply (below) to the effect yes it could because the OpenDelay timer did not always get stopped but the timer should be stopped in which case the event would not happen. Reading your responses to Siva , I see you include stopping the Open Delay timer in the action 'release all BGP resources' when going to Idle (which I missed seeing earlier in the year). That eliminates most but not all of the possibilities I mentioned. I now believe we would need to add the action 'stop OpenDelay timer' for Connect state event 17 (currently defined as going to Active) event 9 (stays in Connect state) in order to stop event 19 in Open Sent Sue replied that, she thought this was at consensus, and provided the new text, which is: Change 1: new text Active state - event 19 If an Open is received with the Open Delay timer is running [Event 19], the local system - clears the connect retry timer (cleared to zero), - stops and clears the Open Delay timer - completes the BGP initialization, - stops and clears the Open Delay timer - sends an OPEN message, - send a Keepalive message, - if the hold timer value is non-zero, - starts the keepalive timer to initial value, - resets the hold timer to the negotiated value, else if the hold timer is zero - resets the keepalive timer (set to zero), - resets the hold timer to zero. - changes its state to OpenConfirm. If the value of the autonomous system field is the same as the local Autonomous System number, set the connection status to an internal connection; otherwise it is "external". Change 2 - Connect state event 17 (currently defined as going to Active) event 9 (stays in Connect state) new Text: In response to the connect retry timer expires event [Event 9], the local system: - drops the TCP connection, - restarts the connect retry timer, - stops the Open Delay timer and resets the timer to zero, - initiates a TCP connection to the other BGP peer, - continues to listen for a connection that may be initiated by the remote BGP peer, and - stays in Connect state. If the TCP connection fails [Event17], the local system: - restarts the connect retry timer, - stops the Open Delay timer and resets value to zero, - continues to listen for a connection that may be initiated by the remote BGP peer, and - changes its state to Active. Tom replied that: Change 2, stop Open Delay timer in Connect state events 9 and 17, fine; that is what I understand to be the real issue 12. Change 1, event 19 in Active state, is IMHO issues 47 and 52. This is tangled because the initial paragraphs of Issue 12 in the issue list are nothing to to with stopping Open Delay timer and everything to to with sending a Keepalive message before entering Open Confirm state from Active or Connect state on event 19; which I raised and see as issue 52. Issue 47 was Siva's issue 28 and relates to a different action for Active state event 19. I agree with change 1 in that it adds in the sending of Keepalive which I believe essential; I think Siva needs to respond concerning issue 47. (nb the stop Open Delay action is duplicated) I wonder if we should use a different character for the bullet points under the if and else clauses to make it clear where they end ie - if the hold timer .... + do this + and this else if ... + do the other + and this But I still have an issue for Connect state event 19 where I believe, as for Active state event 19, we should send a Keepalive and start the Keepalive timer. I will pursue this as part of issue 52 if that suits you. I think the text will be the same as whatever we agree for Active state event 19. This was discussed in the "bgp 18 WG Last Call fsm missing keepalive" thread. And also in the "Event 19 in Open Sent state was Re: bgp18 WG Last Call fsm missing keepalive" thread. This also came up in the "issues 12 - consensus & two changes - 2nd message" thread. ---------------------------------------------------------------------------- 13) FSM Missing Next States ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Seven sub-issues spawned to resolve each of the next-state questions. See each sub-issue for specifics. Discussion: This began with Tom pointing out 7 places where the next state was not clear. Interlaced with his comments below is the proposed text to fix the problems and the status of the issue. All sub-issues are at consensus. This conversation was started in the "bgp18 WG Last Call fsm missing next state" thread. ---------------------------------------------------------------------------- 13.1) FSM Missing Next States - Event 15 or 16 (Connect State) ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Add next state of Connect. Discussion: Tom pointed out that: Connect State: If the TCP connection succeeds [Event 15 or Event 16], the local system checks the "Delay Open Flag". If the delay Open flag is set, the local system: **enters what state Sue proposed these changes: 1) Connect State - Event 15 or Event 16 [consensus, editorial] note: The delay retry timer is utilized instead of the connect retry timer for the next two changes. Previous text: If the TCP connection succeeds [Event 15 or Event 16], local system checks the "Delay Open Flag". If the delay open flag is set, the local system: - clears the connect retry timer, - sets the BGP open delay timer to initial value If the Delay Open flag is not set, the local system: - clears the connect retry timer, - clear BGP Open Delay timer (set to zero), - completes the BGP initialization, - send an Open message to its peer, - sets hold timer to a large value, and - change the state to Open Sent. New text: If the TCP connection succeeds [Event 15 or Event 16], local system checks the Delay Open flag prior to processing: If the Delay Open flag is set, the local system: - clears the connect retry timer, - sets the BGP open delay timer to initial value, and - stays in the Connect state. If the Delay Open flag is not set, the local system: - clears the connect retry timer, - clears the BGP Delay timer (sets to zero), - completes the BGP initialization, - sends an Open message to its peer, - sets the hold timer to a large value, and - changes the state to Open Sent. Tom agreed that this was good, with the change to "Open Delay timer" as discussed in issue 7. This conversation was started in the "bgp18 WG Last Call fsm missing next state" thread. ---------------------------------------------------------------------------- 13.2) FSM Missing Next States - Event 14 (Connect State) ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: We selected option 2 from discussion as the correct text: 2) treat it as an invalid response, reject the connection and see if a valid configured one comes iwthin the connect timer's window. Discussion: Tom pointed out that: Connect State: If the TCP connection receives an indication that is invalid or unconfigured. [Event 14]: **enters what state Sue proposed these alternatives: 2)Connect State - Event 14 [no consensus] Current Text: If the TCP connection receives an indication that that is invalid or unconfigured [Event 14], - the TCP connection is rejected. At the very least this section needs more "word smithing", so I'd like to change it for more clarity at least. I'm not sure this represents the implementations. What I'd like to do is query the implementations to see what they do if they receive a valid TCP connection with an invalid or unconfigured peer. Two options: Alternative 1: Count it as a valid response New Text: If a TCP connection is received that has an invalid format, or an unconfigured host [Event 14], the local system: - rejects the TCP connection, - increments the connect retry counter, - performs bgp peer oscillation checks. If bgp peer oscillation checks allow for a new connection, the bgp peer - restarts the Connect retry timer with configured value, and - enters the Active state. FSM table: Idle Connect Active Open-Sent Open-Confirm Establish Event-14 ======================================================= Next state Idle | Active|Active|Open-Sent|Open-Confirm|Establish| ======================================================= action V | Y2 | L | Ignore | Ignore | Ignore | ======================================================= Alternative 2: Reject the connection and see if valid or configured one appears within the connect timer window. New Text: If a TCP connection is received that has an invalid format, or an unconfigured host [Event 14], the local system: - rejects the TCP connection, - and stays in the Connect state. FSM table: Idle Connect Active Open-Sent Open-Confirm Establish Event-14 ======================================================= Nxt state Idle |Connect|Active|Open-Sent|Open-Confirm|Establish| ======================================================= action V | L | L | Ignore | Ignore | Ignore | ======================================================= Sue then sent out a call to implementors to let the list know what they did with their FSMs. Tom replied that he agreed that we need to wait to see what the existing implementations do. He also suggested: **tp need a then clause here 'if bgp peer oscillation damping does not allow for a new connection, then the local system ???' be added before the FSM table in option 1 of the proposed text. Sue prodded the list saying that: Should the peer: 1) Treat it as a valid response, and enters the active state to watch for a another TCP connection with a valid peer. 2) treat it as an invalid response, reject the connection and see if a valid configured one comes iwthin the connect timer's window. Without further input, I will select option 2. Curtis replied that this was fine with him. There has been no further disagreement, we are at consensus on this. This conversation was started in the "bgp18 WG Last Call fsm missing next state" thread. It was also discussed in the "BGP draft-19 - FSM input needed from developers" thread. ---------------------------------------------------------------------------- 13.3) FSM Missing Next States - Event 15 or 16 (Active State) ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Add text listed in discussion. Discussion: Tom pointed out: Active State: A TCP connection succeeds [Event 15 or Event 16], the local system: process the TCP connection flags - If the BGP delay open flag is set: ** enters what state (I think this is an FSM error in TCP because it has not initiated a connection!) Sue proposed these changes: Previous text: A TCP connection succeeds [Event 15 or Event 16], the local system: process the TCP connection flags - If the BGP delay open flag is set: - clears the connect retry timer [through the following text: - and changes its state to Open Sent. New text: If the TCP connection succeeds [Event 15 or Event 16], local system checks the "Delay Open Flag" prior to processing: If the delay open flag is set, the local system: - clears the connect retry timer, - sets the BGP open delay timer to initial value, and - stays in the Active state. If the Delay Open flag is not set, the local system: - clears the connect retry timer, - clears the BGP Delay timer (sets to zero), - completes the BGP initialization, - sends an Open message to its peer, - sets the hold timer to a large value, and - changes the state to Open Sent. Tom agreeded with this. This conversation was started in the "bgp18 WG Last Call fsm missing next state" thread. ---------------------------------------------------------------------------- 13.4) FSM Missing Next States - Event 13-17 (TCP Connection) ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: We selected: Choice 2: Event 13 and Event 14 be optional, and Events 15 - 17 be mandatory. Discussion: Tom started this by saying that: If the local system receives a valid TCP Indication [Event 13], the local system processes the TCP connection flags. ** enters what state If the local system receives a TCP indication that is invalid for this connection [Event 14]: ** enters what state Sue proposed we move this to the "fsm missing next state - Events 13-17 and the TCP connection" thread. The response in this thread was: 4) Active State, Event 13 [no consensus] 5) Active State, Event 14 [no consensus] The problem with this state is it is difficult to exactly specify without discussing the TCP Messages that FSM document covers. I'll query if the implementors require all of events 13-17 as mandatory. Sue polled the implemtentors on the list with this query: These events are described in section 8.1.3. In our discussion in January through May of 2002, many implementers mapped their implementation onto the following TCP events list in 8.1.3. Events 13 - 17 Event 13 - TCP connection indication & valid remote peer Event 14 - TCP connection indication with invalid source or destination Event 15 - TCP connection request sent (by this peer) received an Acknowledgement [ local system sent a TCP SYN, Received a TCP SYN, ACK pair back, and Sent a TCP ACK] Event 16 - TCP connection confirmed [local system received a TCP SYN, sent a TCP SYN, ACK back, and received a TCP ACK] Event 17 - TCP connections Should we have all of these states? Which implementations support all of these Events? The full FSM text was snipped here for brevity. Sue prodded the list with: Do the implementors require Events 13 - 17 in the State machine ? Event 13 - TCP connection valid indication Event 14 - TCP connection invalid indication Event 15 - TCP connection request acknowedged Event 16 - TCP connection confirmed Event 17 - TCP connection fails Choice 1: Events 13 - 17 are mandatory Choice 2: Event 13 and Event 14 be optional, and Events 15 - 17 be mandatory. If no one objects, we will use Choice 2. Curtis said this was fine with him. There has been no further disagreement, we are at consensus on this. This was started in the "bgp18 WG Last Call fsm missing next state" thread. And continued in the "fsm missing next state - Events 13-17 and the TCP connection" thread. It was also discussed in the "BGP draft-19 - FSM input needed from developers" thread. ---------------------------------------------------------------------------- 13.5) FSM Missing Next States - Event 17 (Connect State) ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: Closed in favor of 13.4 Discussion: If the local system receives a TCP connection failed [Event 17] (timeout or receives connection disconnect), the local system will: ** enters what state Sue replied with this: comment: In the Active state, we may already have a connection and be awaiting the Open Delay timer. The TCP disconnect or timeout could occur in this state due to the "Open Delay Timer". If the TCP Disconnect is ignored, we could have some peer oscillation. If the we wait, then the connection retry timer needs to be kept running. The text below allows this timer. The real question is what is the status of the current implementations. I agree, the Active state and the connect state should match. Old Text: If the TCP connection fails (timeout or disconnection) [Event 17], the local system: - set TCP disconnect in the MIB reason code, - restart Connect retry timer (with initial value), - release all BGP resources, - Acknowledge the Drop of the TCP connection if TCP disconnect (FIN ACK), - Increment ConnectRetryCnt (connect retry count) by 1, and - performs the BGP peer oscillation damping process. Applicable FSM State table: FSM table old: Event 17 current: Idle Connect Active Open-Sent Open-Confirm Establish ========================================================= Next state Idle |Active |Idle |Active | Idle |Idle | | | | | | | ========================================================= action V | Y2 | G | Ignore| Track 2nd | Track 2nd | | | | | connection | connection| ========================================================= Alternative 1: FSM table new: Event 17 current: Idle Connect Active Open-Sent Open-Confirm Establish ========================================================= Next state Idle |Active |Active |Active | Idle |Idle | | | | | | | ========================================================= action V | G | G | Ignore| Track 2nd | Track 2nd | | | | | connection | connection| ========================================================= G: The local system: - restarts the connect retry timer (at intial value), - continues to listen for a connection that may be initiated by the remote peer, and - sets its next state to Active. New Text: (for Connect and Active state) If the TCP connection fails (timeout or disconnect) [Event 17], the local system: - restarts the connect retry timer, - continues to listen for a connection that may be initiated by the remote BGP peer, and - changes it state to Active. Alternative 2: FSM table new: Event 17 current: Idle Connect Active Open-Sent Open-Confirm Establish ========================================================= Next state Idle |Idle |Idle |Active | Idle |Idle | | | | | | | ========================================================= action V | Y2 | Y2 | Ignore| Track 2nd | Track 2nd | | | | | connection | connection| ========================================================= Next Text: If the location system receives a TCP connection failed [Event 17], the local system will: - increment the ConnectRetrycnt (connect retry count) by 1, - release all BGP resources associated with this connection, - perform BGP peer oscillation (if configured), and - go to Idle Y2 - is: The local system: 1) increments the ConnectRetryCnt (connect retry count) by 1, 2) releases all BGP resources associated with this connection, and 3) performs the BGP peer oscillation damping process if the damping process allows for a new connection, the local system - restarts the connect retry timer (with initial value, and - goes to Idle If the damping process does not allow for a new connection, the local system - set the flags to damp the creation of a new bgp connection until a manual start occurs, and - goes to Idle. Tom agreed with the options, and stated that he prefered option 2. Sue is also happy with option 2, if no one else chimes in. After the issues list came out Tom responded to this issue, saying: I think this issue SHOULD be administratively terminated. It relates to Connect state Event 17 (TCP connection fails) and I am credited with raising it; in fact, the issue I raised was missing next state for Active state event 17 and this has now been subsumed into 13.4 (but note that 13.4 does not explicitly say Active state - I know it should because I raised that issue too). I will ensure it does not get lost from any resolution of 13.4. And Connect state event 17 does appear as part of issue 45 which Siva raised so I think that either way, 13.5 can go. This conversation was started in the "bgp18 WG Last Call fsm missing next state" thread. ---------------------------------------------------------------------------- 13.6) FSM Missing Next States - Event 18 (Open Confirm) ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: This is the text: In the Open Confirm state, a valid Open message [Event 22] is received. The BGP Peer connection is check to ee if there is a collision per section 6.8. If this connection is to be dropped due to the call collision, the local system will drop the call by: - sending a NOTIFICATION with a CEASE, - resets the Connect timer (to zero), - releases all BGP resources (this includes stopping the Open Delay Timer and reseting it to zero), - increments the ConnectRetryCnt by 1 (connect retry +count), and - optionally performs a BGP peer oscilation damping processing, and - enters the Idle State. Discussion: Tom opened this with: Open Confirm State: If the Open messages is valid [Event 18], the collision detect function is processed per section 6.8. If this connection is to be dropped due to call collision, the local system: ** enters what state Sue replied with: Here's my proposed text. Please let me know what you think. I think this is an editorial change. Old text: If the open message is valid, the collision detect function is processed per section 6.8. If this connection is to be dropped due to call collision, the local system: - sends a Notification with a Cease - resets the Connect timer (to zero), - releases all BGP resources, - Drop the TCP connection (sends a TCP FIN), - increments the ConnectRetryCnt by 1 (connect retry count), and - performs an BGP peer oscillation damping process. New text: If the open message is valid, the BGP peer connection is check to detect a collision per section 6.8. If this connection is to be dropped due to call collision, the local system: - sends a Notification with a Cease - resets the Connect timer (to zero), - releases all BGP resources, - Drop the TCP connection (sends a TCP FIN), - increments the ConnectRetryCnt by 1 (connect retry count), and - performs an BGP peer oscillation damping processing, and - enters the Idle State. notes: Collision detect impacts Open Sent, Open Confirm, and Established states. Tom replied: I am still struggling with; we are in OpenConfirm so we already have received an Open from the remote peer and Event 18 is a second Open from the same peer. Perhaps my struggle is that I think in terms of two (or more) FSM for a given IP address pair so the Open Collision detection will occur when the/an- other FSM receives a valid Open in states Active/Connect/Open Sent and will generate Event 22 into this FSM so Event 18 cannot occur. But yes, if Event 18 can occur in this FSM and this connection is to be dumped, then Idle state it should be as you suggest. I have slotted in [optionally] in front of the peer oscillation damping in your text because I think it should be optional:-) Sue replied: this mechanism allows a single fsm to handle both. 2 fsm and 1 fsm BGP FSM seem to exist. (I queried implementors a few times on this one. So, I just put in this change to provide the flexibility. Collision detect tends to give scrambled brains for most people.. As Dennis Ferguson said 2 years ago, that's the hardest part of the FSM. Sue then stated that she would query implementors to see what is being done. Sue prodded the list with: In the Open Confirm state, a valid Open message [Event 22] is received. The BGP Peer connection is check to ee if there is a collision per section 6.8. If this connection is to be dropped due to the call collision, the local system will drop the call by: - sending a NOTIFICATION with a CEASE, - resets the Connect timer (to zero), - releases all BGP resources (this includes stopping the Open Delay Timer and reseting it to zero), - increments the ConnectRetryCnt by 1 (connect retry +count), and - optionally performs a BGP peer oscilation damping processing, and - enters the Idle State. Implementors need to verify if this text and the text for Event 22 allows all implementors to perform the necessary Call Collision actions. If no objects, we will use this text. Curtis said he had no problem with this. There has been no disagreement, we are at consensus with this. This conversation was started in the "bgp18 WG Last Call fsm missing next state" thread. It was also discussed in the "BGP draft-19 - FSM input needed from developers" thread. ---------------------------------------------------------------------------- 14) FSM - Peer Oscillation Damping ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Change references to peer oscillation damping to consistant phrase: "[optionally] performs peer oscillation damping". Also remove old reference to "BGP Peer Restart Backoff Mechanisms". Discussion: Tom suggested we use consistant terminology to refer to peer osillation damping. He also pointed out a stale reference. Yakov agreed to fix both of these. ---------------------------------------------------------------------------- 15) FSM - Consistent FSM Event Names ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Make FSM names consistent. Specifics are in the discssion section. Discussion: Tom proposed that: The event name used in the FSM show much variation to the point sometimes where I am not clear that it is always the same event (eg where the event name is qualified by a subset of the possible causes). Assuming that it is, I propose the following changes to make the wording consistent, clear and concise for event names. ** denotes changed text using the convention /'old text'/'new text'/ 8. BGP Finite State machine Event1: Manual start Event2: Manual stop Event3: Automatic start **Event4: Manual start with passive TCP /estabishment/flag/ **Event5: Automatic start with passive TCP /establishment/flag/ Event6: Automatic start with bgp_stop_flap option set **Event7: Auto//matic/ stop Event8: Idle hold timer expires Event9: Connect retry timer expires **Event10: Hold time//r/ expires Event11: Keepalive timer expires Event12: Open Delay timer expires **Event13: TCP connection valid indication **Event14: TCP connection invalid indication **Event15: TCP connection request /sent received an ACK/acknowledged/ Event16: TCP connection confirmed Event17: TCP connection fails Event18: BGPOpen Event19: BGPOpen with *Open Delay timer running Event20: BGPHeaderErr Event21: BGPOpenMsgErr Event22: Open collision dump Event23: NotifMsgVerErr Event24: NotifMsg Event25: KeepAliveMsg Event26: UpdateMsg Event27: UpdateMsgErr 8.2.2 Finite State Machine Connect State: If the BGP port receives a ** valid TCP connection indication [Event 13], If the TCP connection receives **an invalid indication [Event 14]: If the TCP connection fails **/(timeout or disconnect)// [Event17] Active State: If the local system receives a **valid TCP //indication/ [Event 13], If the local system receives a TCP connection failed [Event 17] **/(timeout or receives connection disconnect)//, Open Sent: If a connection in Open Sent is determined to be the connection that must be closed, an **/administrative collision detect/Open collision dump/ [Event 22] is signaled to the state machine. If such an **/administrative collision detect dump [Event 22]/event/ is If a TCP **//connection valid/ indication [Event 13] or TCP **//connection/ request **//acknowledged/ [Event 15] Open Confirm State: ... or receives a TCP **/Disconnect// connection fails/ [Event 17] from the In the event of **/TCP establishment//TCP connection valid indication /[Event 13] .... the local system will **/issue a call/generate an Open/ collision dump [Event 22]. When the local system receives a **/call/open/ collision dump event [Event 22]/such an event/, the Established State: **/disconnect from the underlying TCP/TCP connection fails/ [Event17], it: ... it will process **/a Call/an Open/ Collision dump event[Event 22]. Notes: Event 4 title brought in line with text Event 5 title brought in line with text Event 7 title brought in line with text Event 13 title shortened to be closer to text, text brought in line Event 14 title shortened to be closer to text, text brought in line Event 15 title brought in line with text Event 17 text brought in line with title (text often introduces qualifying conditions that are too restrictive) Event 22 text brought in line with title Sue replied: I will accept the text you proposed for the Event names. I will update the FSM text to include your changes. We'll consider issue 15 in consensus. I've fixed the text. So we are at consensus here. This is discussed in the thread: "bgp18 WG Last Call fsm event names." It was also discussed in the "Issue 15 - Consistent FSM Event Names" thread. ---------------------------------------------------------------------------- 16) Many Editorial Comments ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Many editorial suggestions, and what we are doing with them are listed below. Some issues have been broken out seperately where there is a longer discussion on them. Discussion: Alex began this by presenting comments from an anonymous reviewer, unless otherwise noted, responses are from Yakov: > Almost all of these are simple clarifications. > > Section 1, page 5: IGP definition - it's not clear from this > definition whether IBGP would be considered an IGP? any suggestion on how to improve the definition to clarify this issue would be appreciated. There was some further discussion on this and it was decided that people reading this document ought to know what an IGP is. > Section 3, page 7, para 4: Does RFC 1772 still represent the *planned* > use of BGP? Or the actual use? Or something different from actual > use? Perhaps we should just take out references to 1772. Further discussion seemed to indicate that this reference should stay. > Section 3, page 8, para 3 - "The hosts executing..." This paragraph > seems obsolete. I'll take it out. With regard to this, Siva asked if some route optimizaiton vendors rely on this. Since this wasn't resolved, it is discussed further in issue 17. > Section 4.1, page 11 - Length is in network byte order. all the encodings are in network byte order. This applies not just to the BGP spec, but to other protocols as well. This comment was made about a number of fields. It was later agreed that a reference would be made to this at the beginning of the document. > Section 4.2, page 12 - Hold Time - what does a value of zero indicate? if you read section 4.4 then you'll find that: If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent. > Section 4.2, page 13 - BGP Identifier - network byte order? > "IP address" -> "IPv4 address" I'll put at the beginning a sentence saying that in the context of this document the term "IP address" means an IP Version 4 address. > Section 4.3, Page 14, para1, sentence 2 - "path attribute" -> "path > attributes" fixed. > Section 4.3,Page 17, NEXT_HOP: "IP address" -> "IPv4 address" > Specify that this is 4 octets. > Reference here to multi-protocol extensions for IPv6 nexthop? no. > RFC 2283 is unclear whether NEXT_HOP should always be included > when using multiprotocol extensions. Clarify this here? It is already clarified in 2283bis. > Section 4.3, Page 17/18 - MED and LocalPref: > "non-negative" -> "unsigned" for consistency with elsewhere. > (non-negative might imply values > 2^31 cannot be used). fixed. > Section 4.3, Page 19 - Prefix: "IP address" -> "IPv4 address" > Prefix: "enough trailing bits to" -> "the minimum number of > trailing bits needed to" fixed. > Section 4.4, Page 20: - "BGP does not use any TCP-based keep-alive > mechanism to determine if peers are reachable". Is it worth noting > that TCP may still timeout the connection even if TCP keepalives are > turned off? the text is fine as it is. > Section 4.4, Page 20: > KEEPALIVE message consists" -> "A KEEPALIVE message consists" fixed. > Section 5, Page 23: "The same attribute can not appear more than once > with the Path Attributes field...". Does this mean the same attribute > type, or the same attribute type and value? the former (the same attribute type). > Section 5.1 "The usage of each BGP path attributes .." -> attribute fixed. > Section 5.1.3 "IP address" -> "IPv4 address" > > "A BGP speaker must never advertise an address of a peer to that peer > as a NEXT_HOP, for a route that the speaker is originating." > suggest replace this text with: > "A route originated by a BGP speaker must never be advertised to a > peer using an address of that peer as NEXT_HOP" fixed. > Section 5.1.4: "A BGP speaker MUST IMPLEMENT a mechanism ... which > allows the MULTI_EXIT_DISC to be removed from a route." Might want to > say that this is dangerous unless you received the route from an EBGP > peer? think we should keep the text as is. > Section 5.1.5: "If it [LOCAL_PREF] is contained in an UPDATE message > that is received from an external peer, then this attribute MUST be > ignored by the receiving speaker, except for the case of BGP > Confederations [RF3065]." > - "ignored" might be taken to mean that you don't process it for > decision, but that you propagate it to internal peers. I might > write "silently removed" or something similar. I think the text is ok as is. > Section 5.1.5, para 2. "set of AS" -> "set of ASs" fixed. > Section 6.3: wrt NEXT_HOP semantic correctness: should we check that a > NEXT_HOP is not a multicast or broadcast address? I'll add to the definition of NEXT_HOP that it is a unicast address. > Section 6.3, page 32, para 7: "peer than sent" -> "peer that sent" fixed. > Section 6.3: "if any attribute appears more than once" - does this > mean the same attribute type, or the same attribute type and value? the former. > Section 6.8 "Comparing BGP identifiers is done by treating them as > (4-octet-long) unsigned integers". Need to convert to host byte order > before comparing. fixed. > Section 6.8, item 2: "closes BGP connection" -> "closes the BGP connection" > "accepts BGP connection" -> "accepts the BGP connection". fixed. > Section 9.1.2.2: item (c): in the explanation of neighborAS(n), it is > unclear for IBGP connections how to determine "the neighbor AS from > which the other IBGP speaker learned the route". If this is really > the leftmost entry in the AS path (or the local AS if the path is > empty), the spec should explicitly say so. fixed. > Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC > attribute is removed before..." The first sentence is pretty nearly > incomprehensible. This topic has some more discussion surrounding what text we should use to clarify this issue. This is followed up in issue 18. > Section 9.1.2.2 (d) > "d) If at least one of the candidate routes was received from an > external peer in a neighboring autonomous system, remove from con- > sideration all routes which were received from internal peers." > For consistency with (c) and clarity, this might be reworded: > "d) If any of the candidate routes was learned via EBGP, remove > from consideration all routes which were learned by IBGP." fixed. > Section 9.1.2.2 (e) > "cost (n) is better than cost (m)" > Given the definition of cost, it might be clearer to say > "cost (n) is lower than cost (m)" fixed. > Section 9.1.2.2 (g) > "neighbor address" has not been defined. I'll replace "neighbor address" with "peer address". > Section 9.2.2.2, Page 70 (AGGREGATOR) - "All AGGREGATOR attributes of > all routes to be aggregated should be ignored." > > Perhaps "ignored" is ambiguous here, and it's not clear whether > should is a SHOULD. Suggest: > > "Any AGGREGATOR attributes from the routes to be aggregated MUST > NOT be included in the aggregated route." fixed. > Section 9.3 - shouldn't this subsection be moved to the discussion of > Phase 1 or Phase 2 of the decision process? Or at least move it > before Section 9.2. I think it is fine where it is now. > Appendix E, para 2: IP precedence has been deprecated. Delete this > paragraph, or replace with appropriate diffserv codepoint. deleted. > Security Considerations: > "BGP supports the ability to authenticate BGP messages by using BGP > authentication." > This sentence should be removed, and the Authentication Information > parameter has been deprecated. Please see the recent e-mail exchange on the Security Considerations See issue 19 for more on the Security Considerations section of the draft. These topics were discussed in the "proxy: more comments on the draft -18" thread. ---------------------------------------------------------------------------- 17) Section 3, Page 8, Paragraph 3 - Obsolete? ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Leave the current definition of BGP Speaker, and normalize the text to use "BGP Speaker" instead of router. Discussion: This issue was spawned from the discussions in issue 16, specifically: Anonymous reviwer: > Section 3, page 8, para 3 - "The hosts executing..." This paragraph > seems obsolete. Yakov: I'll take it out. With regard to this, Siva asked if some route optimizaiton vendors rely on this. Jeff replied: To provide context, this paragraph currently reads: : The hosts executing BGP need not be routers. A non-routing host : could exchange routing information with routers via EGP [RFC904] or : even an interior routing protocol. That non-routing host could then : use BGP to exchange routing information with a border router in : another Autonomous System. The implications and applications of this : architecture are for further study. There are several deployed entities that could be considered to "exploit" this paragraph. Route collectors, route servers, bandwidth shapers and other optimizers. However, the original text may be showing its age a little bit. Perhaps the following might be a bit more appropriate: "The hosts executing BGP need not be routers. A non-routing host may exchange routing information with a BGP speaker for reasons that are outside the scope of this document." I would also propose adding to the same paragraph (but could be persuaded to drop it since it is *logically* redundant): "These non-routing hosts should exercise great care not to insert themselves into the forwarding path if they re-announce BGP routes." Yakov replied: Since operations of non-routing host are outside the scope of the document, and since the document doesn't preclude non-routing hosts to run BGP, I would prefer just to take the following paragraph out, and not to add any new text. The hosts executing BGP need not be routers. A non-routing host could exchange routing information with routers via EGP [RFC904] or even an interior routing protocol. That non-routing host could then use BGP to exchange routing information with a border router in another Autonomous System. The implications and applications of this architecture are for further study. Jeff replied that this was ok, and instead suggested: At the beginning of the document, we define: BGP speaker A router that implements BGP. This (potentially) restricts a speaker to being a router. Additionally, several spots in the text where we probably should say "BGP speaker", we use router. Yakov agreed to add this definition. Jeff replied that there still was a problem with this definition being too limiting. The discussion meandered off list for a couple of exchanges and these additional definitions were proposed: First Jeff proposed this: "A router that implements the BGP protocol. Non-routing hosts that also implement BGP are out of scope of this document." Then Andrew replied, that we should make sure the definition does not opt out entirely from making sure that non-routing hosts are interoperable: BGP Speaker A router that implements the BGP protocol. The internal behavior of non-routing hosts that also implement BGP are out of scope of this document. However, in their interactions with routers, non-routing hosts must behave as if they were routers. And Jeff replied: BGP Speaker A router that implements the BGP protocol. The internal behavior of non-routing hosts that also implement BGP are out of scope of this document. However, in their interactions with BGP speaking routers, non-routing hosts that implement BGP should be indistinguishable from a router on the wire. (or something like that - s/on the wire/ with whatever sounds best.) IOW, look like bgp on the wire - what you do internally is out of scope. Yakov replied, that we should keep the current definition, since it is clear that non-routing hosts are outside of the scope. Jeff responded that he is ok with that if we normalize the use of "BGP Speaker" instead of "BGP router" in the document. Yakov agreed to this, we are at consensus on this. This was discussed in the "proxy: more comments on draft -18" thread. And in the "Issues list, #17: Section 3, Page 8, Paragraph 3 - Obsolete?" thread. And also, the "issue 17 - final resolution" thread. ---------------------------------------------------------------------------- 18) MED Removal Text ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Use text at the end of the discussion. Discussion: This issue is spawned from issue 16. An anonymous reviewer pointed out: > Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC > attribute is removed before..." The first sentence is pretty nearly > incomprehensible. Yakov replied: here is my attempt to clarify this: If a MULTI_EXIT_DISC attribute is removed before re-advertising a route into IBGP, then (prior to the removal) the MULTI_EXIT_DISC attribute may only be considered in the comparison of EBGP learned routes; the attribute is then removed, and then the remaining EBGP learned routes may be compared to the remaining IBGP learned routes, without considering the MULTI_EXIT_DISC attribute for those EBGP learned routes whose MULTI_EXIT_DISC attribute will be removed before advertising these routes to IBGP. Any further suggestions on how to improve this would be appreciated. Siva replied: How about this: % If a MULTI_EXIT_DISC attribute is removed before re-advertising a % route into IBGP, then comparison based on the MULT_EXIT_DISC % attribute may (MUST?) be performed only among the EBGP learned routes. % This comparison MUST be performed before the removal of the % MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute must then % be removed from those EBGP routes where such removal is required and % which are still eligible. This is followed by comparison with IBGP % learned routes. I think this reflects our objectives, which is: a) If MED is to be removed, compare EBGP routes based on the MED b) Then remove the MED c) Then do comparison with IBGP routes Andrew suggested: If a router is configured to remove a MUTLI_EXIT_DISC attribute from a route learned from EBGP, before readvertising it into IBGP the router MUST compare the route with other EBGP-learned routes before removing the MULTI_EXIT_DISC. Once this comparison is complete, the MED may be removed, and any remaining routes can be compared with IBGP routes to determine the best route. Yakov replied: Here is the text that will go in the next version of the draft: If a MULTI_EXIT_DISC attribute is removed before re-advertising a route into IBGP, then comparison based on the MULT_EXIT_DISC attribute MAY be performed only among the EBGP learned routes. This comparison MUST be performed before the removal of the MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute is then removed from those EBGP routes where such removal is required and which are still eligible. This is followed by comparison with IBGP learned routes. Matthew responded to this with: I think this new text is ambiguous. >Here is the text that will go in the next version of the draft: > > If a MULTI_EXIT_DISC attribute is removed before re-advertising a > route into IBGP, then comparison based on the MULT_EXIT_DISC > attribute MAY be performed only among the EBGP learned routes. This could be taken to mean either that the comparison may be performed, and if it's performed it must be performed only between EBGP learned routes, or that the comparison must be performed, but it may be performed only between EBGP learned routes. > This comparison MUST be performed before the removal of the > MULTI_EXIT_DISC attribute. If doing the comparison is optional, then I think that this sentence should read "If the comparsion is performed, then it MUST be perfo..." > The MULT_EXIT_DISC attribute is then > removed from those EBGP routes where such removal is required and > which are still eligible. This is followed by comparison with > IBGP learned routes. I think that it is desirable for an operator to be able to turn off MED processing entirely (including turning off all MED based comparisons), so I would suggest the following text: If a MULTI_EXIT_DISC attribute is removed before re-advertising a route into IBGP, comparison based on the received MULTI_EXIT_DISC attribute MAY be performed. If an implementation chooses to perform this comparison, then the comparison MUST be performed only among EBGP learned routes, and it MUST be performed before the removal of the MULTI_EXIT_DISC attribute. Curtis replied to Yakov's message: Looks good to me. I see no need to change "This comparison MUST be performed before the removal of the MULTI_EXIT_DISC attribute". There is no implication that MULTI_EXIT_DISC must be removed and the first sentence clearly indicates that doing so is not required therefore no ambiguity. Adding a "If a MULTI_EXIT_DISC attribute is removed" to the second sentence would be redundant. After some further discussion we have reached full consensus with: If a MULTI_EXIT_DISC attribute is removed before re-advertising a route into IBGP, then comparison based on the received EBGP MULTI_EXIT_DISC attribute MAY still be performed. If an implementation chooses to remove MULTI_EXIT_DISC, then the optional comparison on MULTI_EXIT_DISC if performed at all MUST be performed only among EBGP learned routes. The best EBGP learned route may then be compared with IBGP learned routes after the removal of the MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a subset of EBGP learned routes and the selected "best" EBGP learned route will not have MULTI_EXIT_DISC removed, then the MULTI_EXIT_DISC must be used in the comparison with IBGP learned routes. For IBGP learned routes the MULTI_EXIT_DISC MUST be used in route comparisons which reach this step in the decision process. This is discussed in the "proxy: more comments on draft 18" thread. And in the "issue 18" thread. ---------------------------------------------------------------------------- 19) Security Considerations ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Fix Security Considerations section to include manditory MD5 auth and advance security considerations draft along with the base draft. Discussion: Yakov started this discussion by proposing text which would require TCP MD5 authententication for BGP implementations. This is to bring the spec in line with an IETF requirement that authentication be available. After some discussion the plan is to advance draft-ietf-idr-bgp-vuln-00.txt as Informational along with the base BGP specification. This draft will serve as the security analysis section of the base spec. This is discussed in the "revised Security Considerations section" thread. ---------------------------------------------------------------------------- 20) Peer Oscillation Damping ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: Keep the Peer Oscillation Damping reference in the specification. Discussion: This began when Siva proposed: Since this feature is going to be added in a new draft, and its addition will change the operation of the state machine, can we remove all mention of it in the state machine ? As part of this removal, can we also remove the IdleHold Timer from the FSM since it is not useful in the absence of peer oscillation damping ? The draft that describes this procedure can then describe the change in the state machine required to do this. Sue replied that: The reason we should not remove the peer oscillation damping from the state machine: 1) Deployed implementations support peer oscillation damping 2) Hooks for the additions in the FSM cannot be added later. These hooks are optional and do not need to be implemented. Siva replied: I understand. I am not trying to object to peer oscillation damping, I think it is a good idea and we have included it in our implementation as well. I was suggesting that instead of a partial description in this draft, it be completely described in the draft on peer oscillation damping. However, I do see your point, and unless there are any objections from others, I think we have consensus on this issue. This was discussed in the "Response to FSM input - Comments 1-10" thread: Comment #1. ---------------------------------------------------------------------------- 21) Session Attributes - IdleHold Timer ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Add the text in the discussion section. Discussion: This discussion began with Siva asking: Why have a Hold Timer and a Hold Time ? Can we replace this with just Hold timer ? Can we also add the following session attributes: a) DelayBgpOpenTimer b) IdleHold Timer (in case we choose not to remove this from the bas = FSM) Can we also add the following flag to the session attributes: a) DelayOpen Flag After some discussion we have this text on the table: Event8: Idle hold timer expires Definition: An Event generated when the Idle Hold Timer expires. The Idle Hold Timer is only used when the persistent peer oscillation damping function is enabled. % % Implementations not implemented persistent % peer oscillations damping functions may not % have the Idle Hold Timer. Sue replied: I will accept the new text for the following total text: Event8: Idle hold timer expires Definition: An event generated when the Idle Hold Timer expires indicating that the session has completed a back-off period to prevent bgp peer oscillation. The Idle Hold Timer is only used when the persistent peer oscillation damping function is enabled. Implementations not implementing the presistent peer oscillation damping functions may not have the Idle Hold Timer. Status: Optional We are at consensus with this. Tom added a couple of minor edits, correcting the spelling of "persistent" in the third paragraph, and pointing out that: oscillation damping functions may not have the Idle Hold ** function ** (because we only have function not functions in the previous sentence) Timer. Sue added the edits. Siva also liked the way this issue has turned out. This was discussed in the "Response to FSM input - Comments 1-10" thread: Comment #2. And in the "Draft 19 - issue #21" thread, alternately the "Draft 19 - Issue 21" thread. ---------------------------------------------------------------------------- 22) Specify New Attributes (Accept Connections/Peer Oscillation Damping) ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Add the text in the discussion section to section 8.0. Discussion: This begain with Siva propsosing: Can we call these out as well: * Accept Connections from unconfigured peers (Enabled/Disabled) * Peer Oscillation Dampening (Enabled/Disabled) (In case we choose not to remove it from base spec) After some discussion we have this text on the table: The following will be added to 8.0 Optional parameters that may be supported either per connection or per implementation: 1) Delay Open flag 2) Delay Open Timer 3) Perform automatic start flag 4) Passive TCP establishment flag 5) BGP stop_peer_flag flag 6) Idle Hold timer 7) Perform automatic stop flag 8) Perform Collision detect in Establish mode flag Sue accepted these changes. Tom added this correction for item 2 in Sue's text: 2) Delay Open Timer ** Open Delay timer ** (for which we have consensus in Issue list v2 item 7) Siva asked, and Sue accepted these additional changes: 9) accept connections from un-configured peers 5) BGP stop_peer_flap flag We are at consensus on this. This was discussed in the "Response to FSM input - Comments 1-10" thread: Comment #3. This was also discussed in the "BGP Draft 19 - Close open items 22" thread. ---------------------------------------------------------------------------- 23) Event1/Event2 Clean Up ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Use "Local system administrator" in both sections. Discussion: Siva proposed that we clean up the text for these Events by selecting either "Administrator" or "Local system" but not both. Sue proposed text using "Local system administrator" that was agreed on. This was discussed in the "Response to FSM input - Comments 1-10" thread: Comment #4. ---------------------------------------------------------------------------- 24) Events 3, 5, 6 & 7 Give Examples ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: Leave the examples out. Discussion: This began with Siva proposing we add examples for these event states. Sue believes this is largely out-of-scope, but did agree to move the example of "automatic stop" to the event description section. She asked for proposed text for additional examples. Sue replied that she has made the following changes, and asked if these worked for Siva. New text: Event7: Automatic stop Definition: Local system automatically stops the BGP connection. An example of an automatic stop event is exceeding the number of prefixes for a given peer and the local system automatically disconnecting the peer. Status: Optional depending on local system Siva thought this for Event 7 was fine. Sue replied to the list, saying that, previously examples had caused dissention, and asked if there was a strong feeling either way. Siva proposed this text for Events 3, 5 & 6: Event 3: Examples of this event are: When a connection is terminated during exchange of Open messages due to version failure Event 5: Examples of this event are: Similar to Event 3 Event 6: Examples of this event are: Similar to Event 3 and b) When a Idle Hold timer expires (within local limit) Sue replied to this: I'm going to leave the examples out of events 3, 4, 6 since I've not heard any strong input on the mail list **and** I had strong comments on prior versions of the draft. I'd like to declare that issue 24 has consensus. Siva agreed, we are at consensus on this issue. This was discussed in the "Response to FSM input - Comments 1-10" thread: Comment #5. This was also in the "Issue 25" thread, and the "Issue 25 - this is really issue 24" threads. This is also in the "Draft 19 - Issue 24" thread. ---------------------------------------------------------------------------- 25) Event 4 & 5 Session Initiation Text ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: Leave the text as is. Discussion: This began with Siva wanting to change: Definition: Local system automatically starts the BGP session with the passive flag=20 enabled. The passive flag indicates=20 that the peer will listen prior to=20 establishing a connection. to: The passive flag indicates that the state machine will wait for specified peer to initiate a connection with the local system. If this does not happen within a specific time (hold time), the local system will then also attempt to initiate connection with the specified peer. Sue replied: The text in 8.2.1.1 indicates the definition of the passive flag. 6a) ========== My understanding of your text is that you want to replace in both sets of text: "The passive flag indicates the peer will listen prior to establishing a connection". with: "The passive flag indicates that the state machine will wait for the specified peer to initiate a connection with a local system. The problem with this sentence is that in the "unconfigured" case the phrase "specified" peer is confusing. I think the original text is clearer. 6b) ========== If this does not happen within a specific time (hold time), the local system will then also attempt to initiate (a) connection with the specified peer. My comments: Again, the "specified peer" term is confusing. Also, the 2nd half of the statement mixes the actions of the state machine with the events. I believe this muddies the text instead of clarifying it. Siva and Sue later agreed to leave the text the same because of the Unconfigured + passive TCP connection + Delay Open situation. This was discussed in the "Response to FSM input - Comments 1-10" thread: Comment #6. ---------------------------------------------------------------------------- 26) Event 4 & 5 - bgp_stop_flap option ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Add new event below. Discussion: This began with Siva asking: Won't a variant of this with bgp_stop_flap option set be requried ? We can also achieve the same by using the bgp_stop-Flap option as a flag that is provided as an input to the state machine. Siva later clarified this to include: We already have Event 3 - Automatic Start Event 5 - Automatic start with bgp_stop_flap option set To make things consistent, shouldn't we either a) Add 3 new events : 1) Manual start with bgp_stop flap option set 2) Manual start with passive TCP establishment and bgp_stop_flap option set 3) Automatic start with passive TCP establishment and bgp_stop_flap option set or b) Remove Event 6, and rely on a flag to tell us wether peer flap damping is to be performed for the session or not. Sue said she prefered option A. And stated that #1 & #2 are infeasible, but that we need to add #3. Tom replied: But if we add an event, then we must add and agree on actions for all six existing states so I think to say that adding a new event settle things might be naive. If we do add 3) Automatic start with passive TCP establishment and bgp_stop_flap option set which I understand is Sue's resolution, then for Idle state the actions are straightforward but for the other five, is the event completely ignored? If so, does it mean that the passive flag and the bgp_stop_flap option are ignored and we carry on as if we were when we were started which may have been without them. Or is the fact of starting ignored but the flags remain set and so color the effect of other events? Needs defining. Jeff replied to this, quoting the existing draft: The start events [Event 1, 3-6] are ignored in connect state. The start events [Event1, 3-6] are ignored in the Active state. The Start events [Event1, 3-6] are ignored in the OpenSent state. Any start event [Event1, 3-6] is ignored in the OpenConfirm state. Any start event (Event 1, 3-6) is ignored in the Established state. And elaborated, saying that: "ignore" means do nothing. This means don't twiddle with the flags. :-) The text that was finally agreed on is: Event 7: Automatic start with bgp_stop flap option set and passive TCP establishment option set Definition: Local system automatically starts the BGP peer connection with peer oscillation damping enabled and passive TCP establishment enabled. The exact method of damping persistent peer oscillations is left up to the implementation, and is outside the scope of this document. Status: Optional, used only if the bgp peer has enabled bgp peer oscillation damping with following optional flags settings below. Optional attributes: 1) Perform automatic start flag SHOULD be set 2) BGP stop_peer_flap flag SHOULD be set I've re-ordered the Timer events to keep the text changes down to a minimum. action 9 - connect retry timer action 10 - Hold Timer expires action 11 - Keepalive timer expires action 13 - Open Delay timer expires action 14 - Idle Hold timer expires All other events are incremented by 1 This was discussed in the "Response to FSM input - Comments 1-10" thread: Comment #7. ---------------------------------------------------------------------------- 27) Event 5 Clarification ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: Leave the text as is. Discussion: This began when Siva asked that in event 5: Is it correct that this event will occur only when we want to restart a connection (after it had been terminated due to some reason beside administrative action) that we had accepted from an unconfigured peer ? Sue replied: The automatic start function is an implementation specific mechanism. This text does not seek to restrict it in any fashion. Siva said that although he felt his original clarification would be more useful to new implementors he is ok with the text as is. This was discussed in the "Response to FSM input - Comments 1-10" thread: Comment #8. ---------------------------------------------------------------------------- 28) Timer Events Definition - Make Consistant ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Change text to use "generate" across the board. Discussion: Can we use similar language for Events 8-12 to make them consistant? It was agreed that we will use "generate" i.e.: Event 8: An event generated when the Idle Hold timer expires. Event 9: An event generated when the ConnectRetry timer expires. Event 10: An event generated when the Hold timer expires. Event 11: An event generated when the Keepalive timer expires Event 12: An event generated when the Delay BGP Open timer expires. This is at consensus. This was discussed in the "Response to FSM input - Comments 1-10" thread Comment #9. ---------------------------------------------------------------------------- 29) Event 8 - Clean Up ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Clean up first sentance. New text below. Discussion: Siva began this by asking if we could clean up the wording of Event 8. After some discussion with Sue we are at this change for the first sentance: An event trigerred by the expiry of the Idle Hold timer, indicating that the session has completed waiting for a back-off period to prevent bgp peer oscillation. This was discussed in the "Response to FSM input - Comments 1-10" thread: Comment #10. ---------------------------------------------------------------------------- 30) Hold Timer - Split? ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: Keep the hold timer text as is. Discussion: Siva proposed that since: We use the hold timer for two purposes * Waiting for an open message (with a default value of 240 seconds) * Waiting for Keepalives (with a default value of 90 seconds) Can we use two different timers (or at least call them two different timer events) ? Sue replied that this is not how it is implemented currently. Siva replied that we have two conceptually different timers, but that it would certainly work to only have one, since only one needs to be running at any given time. Tom agreed that we can keep things as is. This was discussed in the "Comments 11-20" thread: Comment #11. ---------------------------------------------------------------------------- 31) OpenDelay Timer Definition ---------------------------------------------------------------------------- Status: Consensus Change: Yes - See issue 28 Summary: This is fixed by the fixing of issue 28. Discussion: This began with Siva's request that we add something to Event 12 to specify what to do when the timer expires. This seems to have been addressed in issue 28. This was discussed in the "Comments 11-20" thread: Comment #12. ---------------------------------------------------------------------------- 32) Definition of TCP Connection Accept (Event 13) ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Change "Definition" text as indicated below. Discussion: Siva proposed that we change text from refering to "TCP connection request" to "receiving a TCP connection". This led to this proposed text: Definition: Event indicating the reception of a TCP connection request with a valid source IP address and TCP port, and valid destination IP address and TCP Port. The definition of invalid source address and port and invalid destination address is left to the implementation. This met with agreement. This thread also discussed the idea of filtering the incomming address/port. It was decided that this was implementation dependant. This was discussed in the "Comments 11-20" thread: Comment #13. ---------------------------------------------------------------------------- 33) Event 13 & 14 - Valid Addresses & Ports ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: See text at the end of the discussion. Discussion: With regard to Event 13 & 14, Siva raised questions about: 1) What does it mean to validate a port, and 2) Should we state what we consider an invalid IP addres to be? Sue replied that this is local policy and is implementation dependant. Siva agreed regarding the source port & IP address, but disagreed about the destination port. He argued that we need to know the destination port for interoperability. Sue asked Siva to provide some text. After a long lull, Sue replied with: I would like to keep the current text of "Should" in the following text "BGP's destination port SHOULD be port 179 as defined by IANA." Should indicates that it normally should be 179. If an implementation allows for an alternative TCP port, it is still valid as the "MUST" is not indicated. There have been no further comments on this, the chairs have decided to close it. This was discussed in the "Comments 11-20" thread: Comment #14. This was also in the "BGP-19: Issue 33" thread. ---------------------------------------------------------------------------- 34) Event 17 - TCP Connection Fails to TCP Connection Termination ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Change the text to "fails." Discussion: This began with Siva observing: This event can occur even when the transport connection is closed by the other end. Since this does not reflect a 'failure ', can we change the event name to % Event17: TCP connection termination Sue replied that: Discussion: It both terminates from the remote site and can "timeout" - fail. Suggestions? I can use "disconnect", what do you think. Siva replied that this was a minor issue, and on further reflection, either "fails" or "disconnect" would be acceptable. Sue replied that she has accepted Siva's comments, and the text will be changed to "fails". This was discussed in the "Comments 11-20" thread: Comment #15. This was also discussed in the "BGP-19: Issue 34-35, 40-48" thread. ---------------------------------------------------------------------------- 35) Making Definition Style Consistant ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Adpot consistant style for the definition of events. Discussion: This started with Siva asking if we could make the definition style consistant across eventsr. Sue replied to this with text for 13-17, Siva clarified that he was talking more about 18-21, and proposed text. We are agreed on the text for 13-17: Event13: TCP connection indication and valid remote peer Definition: Event indicating the local system reception of a TCP connection request with a valid source IP address and TCP port, and valid destination IP address and TCP Port. The definition of invalid source, and invalid destination IP address is left to the implementation. BGP's destination port SHOULD be port 179 as defined by IANA. TCP connection request is denoted by the local system receiving a TCP SYN. Status: Mandatory (Optional) Event14: RCV TCP connection indication with invalid source or destination Definition: Event indicating the local system reception of a TCP connection request with either an invalid source address or port number or an invalid destination address or port number. BGP destination port number SHOULD be 179 as defined by IANA. Again, a TCP connection request denoted by local system receiving a TCP SYN. Status: Mandatory (Optional) Event15: TCP connection request sent received an ACK. Definition: Event indicating the Local system's request to establish a TCP connection to the remote peer. The local system's TCP session sent a TCP SYN, and received a TCP SYN, ACK pair of messages, and Sent a TCP ACK. Status: Mandatory Event16: TCP connection confirmed Definition: Event indicates that the local system receiving a confirmation that the TCP connection has been established by the remote site. The remote peer's TCP engine sent a TCP SYN. The local peer's TCP engine sent a SYN, ACK pair, and now has received a final ACK. Status: Mandatory Event17: TCP connection fails Definition: Event indicates that the local system has received a TCP connection failure notice. The remote BGP peer's TCP machine could have sent a FIN. The local peer would respond with a FIN-ACK. Another alternative is that the local peer indicated a timeout in the TCP session and downed the connection. Status: Mandatory Siva proposed these changes for 18-21: > Event18: BGPOpen > > Definition: An event indicating that a valid Open > message has been received. with % Event18: BGPOpen % % Definition: An event is generated when a valid Open % message has been received. > Event19: BGPOpen with BGP Delay Open Timer running > > Definition: An event indicating that a valid Open > message has been successful > established for a peer that is > currently delaying the sending of an > BGP Open message. with % Event19: BGPOpen with BGP Open Delay Timer running % % Definition: An event is generated when a valid Open % message has been received for a peer that % is currently delaying the sending of a % BGP Open message. Editorial Note: "Delay Open Timer" replaced with "Open Delay Timer" per issue 7. > Event20: BGPHeaderErr > > Definition: BGP message header is not valid. with % Event20: BGPHeaderErr % % Definition: An event is generated when a received BGP % message header is not valid. > Event21: BGPOpenMsgErr > > Definition: An BGP Open message has been received > with errors. with % Event21: BGPOpenMsgErr % % Definition: An event is generated when BGP Open message % with errors has been received. Sue replied that she accepted Siva's comments, so we are at consensus here. This was discussed in the "Comments 11-20" thread: Comment #16. This also came up in the "BGP-19: Issue 34-35, 40-48" thread. ---------------------------------------------------------------------------- 36) Event 19 - Definition Cleanup ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Replace definition for Event 19 with the text in the discussion. Discussion: Siva propsosed we replace: > Definition: An event indicating that a valid Open=20 > Message has been successful=20 > established for a peer that is=20 > currently delaying the sending of an=20 > BGP Open message.=20 with: % Definition: An event indicating that a valid OPEN % Message has been received for a peer % that has a successfully established % transport connection and is currently % delaying the seending of a BGP open % message in Event 19. Sue agreed to the changes. This was discussed in the "Comments 11-20" thread: Comment #17. ---------------------------------------------------------------------------- 37) Event 22 - Cleanup ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Replace Event 22 definition with the text from the discussion. Discussion: Siva began with observing: > Event22: Open collision discard > > Definition: An event generated administratively=20 > when a connection Collision has been=20 > detected while processing an incoming =20 > Open message. This connection has been=20 Isn't this event 'automatically' generated, since it is a system generated event ?=20 Sue replied that: response: How this generated is implementation specific. The "administratively" is to cover policy. Siva also proposed an editorial fix with: > Event 22 is an administrative could=20 > occur if FSM is implemented as two=20 > The word event is missing. How about % Event 22 is an automatic event that % could occur if FSM is implemented as two=20 Sue replied with this rewritten text: Event22: Open collision dump Definition: An event generated administratively when a connection collision has been detected while processing an incoming OPEN message and this connection has been selected to disconnected. See Section 6.8 for more information on collision detection. Event22 is an administrative based only implementation specific policy. This Event may occur if the FSM is implemented as two linked state machines. Sive agreed with this new text. This was discussed in the "Comments 11-20" thread: Comment #18. ---------------------------------------------------------------------------- 38) FSM Description - ConnectRetry Count ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: Leave the counter text alone, since it is used in peer oscillation and will be in the MIB. Discussion: Siva opened with this question: The Connect Retry count is updated by the FSM but never used. In the absence of peer oscillation damping, will this be used to stop connection establishment attempts after a certain maximum number ? Yes, this is either implementation specific or is it based on the peer oscillation damping draft. Can we include the use of this counter in some place ? Connect retry counter 1) Will be utilized by the peer oscillation damping drat. 2) Will be included in bgp-4-mibv2-xx. I just check and I didn't find it. Do you still want text in the main? To which Siva replied that he believes we can leave the main text alone. This was discussed in the "Comments 11-20" thread: Comment #19. ---------------------------------------------------------------------------- 39) Handling Event 7 (Auto Stop) to Idle State processing ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Fix the text as indicated in the discussion. Discussion: Siva began with: The handling of Event 7 is missing from the Idle State processing. Can we add this ? How about replacing > An manual stop event (Event2) is ignored in the Idle state. with % Manual stop (Event 2) and Auto stop (Event 7) events are ignored % in the Idle state Sue replied that she would add the text. This was discussed in the "Comments 11-20" thread: Comment #20. ---------------------------------------------------------------------------- 40) Clearing the Connection Retry Timer ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: Leave things alone, since it is better to be redundant than to let something slip through. Discussion: Siva opend with the observation: There are a few sections where the FSM draft states that the Connection Retry timer needs to be reset, wheras the conenct retry timer had been cleared prior to entering that state. We can remove these instructions to clear the connect retry timer. List of places where the connect retry timer need not be cleared a) Handling of Event 19 in the Connect State b) Handling of Events 12 in the Active State c) All cases where it is refered to in the OpenSent, OpenConfirm and Established states Sue replied: Comment: 1) Does it hurt to have the connect retry timer cleared at these points, since it has already been cleared. I felt it eased the implementations to allow the action routines to be shared across as many states as possible. You can see this a bit more actively. Tom replied to this: I propose we leave it in and close this issue. 1) To take out an action as redundant you need to be supremely confident that it really cannot make a difference. I am not (supremely confident); rather, the more I look at the FSM, the more places I find where actions are missing, as I have posted to the list, from obscure yet possible sequences of events and timing. And there is an outstanding issue of mine which flagged seven places where the next state was missing and so I think it impossible for any one to be confident that any particular action is redundant until that is cleared up and that is proving complex in some cases. So, play safe, keep them in. 2) The argument for removing them is that the number of possible distinct action lists is increased. True - it will mean that an implementor will have to code more code when first implementing BGP. For me this is no contest; keeping it safe at the possible cost of redundancy outweighs the one-off cost of additional implementation. So keep the actions in and close the issue. Jeff replied that he agreed with Tom on this. Siva concurred, that this approach was acceptable. Unless someone objects, this issue is at consensus. This was discussed in the "Comments 21-30" thread: Comment #21. This is also discussed in the "BGP-draft-19: Issue 40 Clear Connect retry timer" thread. ---------------------------------------------------------------------------- 41) Handling of Event 14 in the Connect State ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Make event 14 optional. Discussion: Siva opened the discussion with: > If the transport connection receives an indication > that is invalid or unconfigured. [Event 14]: > - the TCP connection is rejected. I don't understand how we would get this event while in this state. Sue replied: See my earlier comments (1-10) on the connection state. It happens in implementations which track the TCP state more closely. I suggest that Event 14 become optional. Sue also suggested we fold this into the discussion about events 13-17, which is tracked in issue 13.4. Sue proposed: My resolution: Let event 14 be optional. Not all BGP implementations support it. And asked if this let us reach consensus on this issue. Siva agreed with this, we are at consensus on this. This was discussed in the "Comments 21-30" thread: Comment #22. This was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. ---------------------------------------------------------------------------- 42) Handling events 20, 21 in the Connect State and Active State ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Use the text Tom proposed in the discussion section. Discussion: Siva began this with: We need to consider the case where we receive events 20 (message header error) and 21 (Open message error) when the delay timer is running. Since the connection has been established at this point, we need to send a Notification message and then terminate the connection. To which Sue replied: Alternative comments: 1) We have not sent an Open statement. 2) Why do we have to send an Notification? I see no justification for it. Suggestion: Do you have implementations that send notification? Do you know of others that don't. Jeff saw this as indicative of an issue with section 4.2 the way it is currently written: >From section 4.2 of -18: : 4.2 OPEN Message Format : : After a TCP is established, the first message sent by each side is an : OPEN message. If the OPEN message is acceptable, a KEEPALIVE message : confirming the OPEN is sent back. Once the OPEN is confirmed, UPDATE, : KEEPALIVE, and NOTIFICATION messages may be exchanged. This text implies that NOTIFICATIONs can only be sent once we have sent an open and then a keepalive, generally meaning we're in the Established state. Anyone suggestions for modifying the wording? Section 6.1 (Message header error) is one situation that implies that a NOTIFICATION can be sent without sending even an OPEN message. Note that since the base FSM implies that we send an OPEN message immediately when we have a completed trasnport connection, we SHOULD be in at least OpenSent. However, the DelayOpen timer means that we MAY send a NOTIFICATION when we are in the Connect state. GateD, at least, will not send a NOTIFICATION without first sending an OPEN. We need to pick one: You can send NOTIFICATIONS before OPEN or before OPEN if the OpenDelay timer is running. However, we MUST fix the text above. Tom opined: A NOTIFICATION without a preceding OPEN is rather hard to interpret; it is the OPEN that gives the recipient what it needs to know about its potential peer (Version, AS number, ID, options etc) so it makes sense to send an OPEN even if it is followed by a NOTIFICATION to say goodbye :-( as opposed to a KEEPALIVE which says hello:-). But as ever, what is implemented? Yakov suggested these modifications to the text to resolve this: 1. Delete the last sentence in the above paragraph or 2. Delete "and NOTIFICATION" in the last sentence in the above paragraph Jeff replied that he prefered the first option, and that the second could be interpreted as NOTIFICAITONs not being legal, when, in fact, they may. So the text on the table to resolve this is: 4.2 OPEN Message Format After a TCP is established, the first message sent by each side is an OPEN message. If the OPEN message is acceptable, a KEEPALIVE message confirming the OPEN is sent back. However, this does not entirely clear up the original point about the FSM. If we reveive an error in Connect/Active, do we send a NOTIFY? Do we preface it with an OPEN, so that OPEN/NOTIFY are sent in immediete succession? Sue replied: I suggest we don't send a "NOTIFICATION" when Event 20 or Event 21 is received in Conect or Active state. Tom responded to this issue with: Issue 42 queries whether or not we can send a NOTIFICATION when we have not sucessfully exchanged OPENs. I propose we should, following the suggestions of Jeff and Yakov. As Yakov suggested, this requires the removal of the second sentence, first paragraph, of 4.2 which implies a NOTIFICATION can only be sent after a succesful exchange of OPENs. I think this fits best with the other references to the uses of NOTIFICATION in the draft. In terms of the FSM, it means that in Connect and Active states, on receipt of events 20 or 21, we should send a NOTIFICATION so that the last section starting In response to any other event............. is replaced by (and noting we have agreed to drop references to MIB actions) If the BGP message header checking or OPEN message checking detect an error (see Section 6.2) [Events 20 or 21], the local system: - sends a NOTIFICATION message with the appropriate error code, - resets the connect retry timer (sets to zero), - releases all BGP resources, - drops the TCP connection - increments the ConnectRetryCnt (connect retry count) by 1, - [optionally] performs peer oscillation damping - and goes to the Idle state. In response to any other event (Events 7-8, 10-11,18, 22-27), the local system: - resets the connect retry timer (sets to zero), - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by one, - [optionally] performs peer oscillation damping, - and goes to the Idle state (Note that this text is not quite watertight. Suppose we are in Active state, having been started with CRT running, receive an SYN (event 13), send SYN-ACK and then get a malformed message (events 20/21). We have not yet received an ACK and so should not send anything over TCP; I would expect TCP to buffer this awaiting the ACK except we then take down the TCP connection - or try to; I don't know what happens next but regard it as sufficiently obscure not to be concerned). (My other concern is greater; why do we now not send NOTIFICATIONs for other events; in Open Sent, Open Confirm or Established, we send one for the 'default event list' so what makes events 20 and 21 in Active and Connect so special? I can justify the absence of a NOTIFICATION for events 7, 8, 10, 11, 18, 22 since there is no evidence of a TCP connection to send it on; but events 23-27 in Active or Connect say we have received an erroneous message, the TCP connection is there so why not send a NOTIFICATION? Event7: Automatic stop Event8: Idle hold timer expires Event10: Hold timer expires Event11: Keepalive timer expires Event18: BGPOpen Event22: Open collision dump Event23: NotifMsgVerErr Event24: NotifMsg Event25: KeepAliveMsg Event26: UpdateMsg Event27: UpdateMsgErr Sue accepted Tom's text, so barring any objections, we are at consensus on this. This was discussed in the "Comments 21-30" thread: Comment #23. This was also brought up in the "BGP-19: Issue 34-35, 40-48" thread, and the "Draft bgp19 - issue #42 NOTIFICATION before OPEN" thread. ---------------------------------------------------------------------------- 43) Handling the default events in the Connect state ---------------------------------------------------------------------------- Status: No Consensus Change: Potentially Summary: Discussion: Siva opened this with: The Open Delay timer [original: BGP Delay OpenTimers) needs to be cleared if it is running. How about adding this: % - If the ConnectRetry Timer is running % - Clear the Connect Retry timer % - Otherwise % - Clear the Open Delay timer [original: BGP Delay Open Timer] Sue replied that: By the default you mean the text: In response to any other events[Events 7-8, 10-11, 18, 20-27], the local system: "resets" to me implies stops and clears. I think the text is clear than the text above. ------------ Is this the replacement text you imply above: - resets the connect retry timer (sets to zero), - clears the Open Delay timer [original: BGP Delay timer] (sets to zero), - increments the ConnectRetryCnt (connect retry count) by 1, - [optionally] performs bgp peer oscillation damping, and - goes to Idle text: Editor's note: various incarnations of "Open Delay timer" have been replaced with "Open Delay timer". See issue 7. Sue replied that she accepted Siva's changes with these editorial changes: old text: - resets the connect retry timer (sets to zero) - clears the open delay timer new text: - if the connect retry timer is running, clear the connect retry timer (set to zero). - if the open delay timer is running, clear the open delay timer (set to zero). Since the substantive changes have been accepted, unless someone objects, this issue is at consensus. This was discussed in the "Comments 21-30" thread: Comment #24. This was also brought up in the "BGP-19: Issue 34-35, 40-48" ---------------------------------------------------------------------------- 44) Handling Event 23 in Connect and OpenSent ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Adopt text at the end of the discussion section. Discussion: This began with Siva saying: This is currently being handled in the default event processing section. However, we do not need to go through the peer oscillation damping process in this case. Can we change the wordings to reflect this, or move this out of peer oscillation damping processing ? Sue replied: 1) There is no default event handling process in the text, you will need to specify the text. 2) The state table below (hares-statemt-03.txt) states shows the changes ------------- Event 23 states: current Idle Connect Active Open-Sent Open-Cnf Establish ---------------------------------------------------- next state Idle Idle Idle Idle Idle Idle ----------------------------------------------- action V D D Y Y T ============================================== V - Indicate FSM errors and ignore. D - 1) resets the connect retry timer (sets to zero), 2) drops the TCP connection, 2) releases all BGP resources, 3) increments the ConnectRetryCnt (connect retry count) by 1, 4) [optionally] performs the bgp peer oscillation damping, and Goes to Idle state. Y 1) resets the connect retry timer (sets to zero), 2) Drops the TCP connection, 3) releases all BGP resources, 4) [optionally] In an exchange between Siva and Sue, this came up: Siva: "Default event handling" was perhaps a poor choice of words. What I meant is this Event 23 (Notify Message Version error) only indicates a version mismatch. By going through action sequence D, we will be performing peer oscillation damping. Should we perform damping, since this is not really a cause for persistent oscillation ? Also, since we have a distinct event to indicate a version error event, can include text indicating that version negotiation processing should take place upon receipt of this event ? Sue: Yes, we can change the "D" in state machine to a "y". The issue is what if Connect state occurs and there is not a TCP connection. Should an OPEN with wrong version be accepted? If the Open Delay flag is off, the connection state should not be getting an Open. The "D" action below works for "open delay flag off". The "y" action you suggest can occur if the open delay timer is on. If this is the issue, please confirm. We could say: if open delay flag is on -> y action if open delay flag is off -> D action Please let me know if this is the concern, and suggest text. Prior to this exhange, this issue was at consensus. The only thing that is firm in this exchange is changing "D" to "y". There seems to be some open discussion still, so we'll reopen it. After some discussion, this is the text we have settled on: If a NOTIFICATION message is received with a version error[Event24], the local system checks the Open Delay timer. If the Open Delay timer is running, the local system: - resets the connect retry timer (sets to zero), - stops and reset the Open Delay timer (sets to zero, - releases all BGP resources, - drops the TCP connection, - changes its state to Idle. If the Open Delay timer is not running, the local system: - resets the connect retry timer (sets to zero), - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, - optionally performs peer oscillation damping, and - changes its state to Idle. N.B. This is now event 24 (see issue 26). We are at consensus with this. This was discussed in the "Comments 21-30" thread: Comment #25. This was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. ---------------------------------------------------------------------------- 45) Event 17 in the Connect state ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Adopt text at the end of the discussion section. Discussion: This began with Siva asking: > If the transport connection fails (timeout or transport > disconnect) [Event17], the local system: > - changes its state to Active. If the transport connection fails when the Open Delay timer [original: BGP Open Delay timer] is running, should we still be going into the Active state ? Sue replied refering to the disussion tracked in issue 13.4. Jeff responded that: In this particular case, I think the issue is separate from the issues for events 13-17 since this isn't particular to how deep the BGP implementation meddles in the TCP implementation. If we are in the Connect state, because we have an incoming transport connection that has completed, but we have the OpenDelay timer running and the transport connection is closed, we can simply drop into Active after resetting the ConnectRetry timer and clearing the OpenDelay timer (if set/exists). In the case of an unconfigured peer, we can discard the FSM instance. Tom replied that he agreed with this. Tom then proposed this text: If the TCP connection fails[Event 17] and the Open Delay timer is running, the local system: - restarts the connect retry timer, - clears the Open Delay timer - continues to listen for a connection that may be initiated by the remote BGP peer, and - changes its state to Active. If the TCP connection fails [Event17] and the Open Delay timer is not running, the local system: - drops the TCP connection, - releases all BGP resources, - sets ConnectRetryCnt (the connect retry count) to zero - resets the connect retry timer (sets to zero), and - goes to Idle state. to replace If the TCP connection fails (timeout or disconnect) [Event17], the local system: - restarts the connect retry timer, - continues to listen for a connection that may be initiated by the remote BGP peer, and - changes its state to Active. Sue agreed to change the text to reflect the comments. o Jeff brought out a couple of other concerns, and Tom replied: > If the TCP connection fails [Event17] and the Open Delay > timer is not running, the local system: > - drops the TCP connection, > - releases all BGP resources, There are no resources to release while in the connect state. (Unless we're using this as shorthand for something else - I forget.) Tom: I was unsure about this action. It is present for Active state event 17 which is why I put it in, it does include sub-actions such as clear Open Delay timer (not running), clear Connect Retry timer (could be running) so I think it right to play safe and include it. Jeff: > - sets ConnectRetryCnt (the connect retry count) to zero I'm forgetting if this action is consistant with everything else. I don't have a current copy of the FSM and I don't trust -18 to be current enough. :-) This said, why do we go to zero? I could see not incrementing it and letting the normal decay process deal with it. The same would apply for the above. Tom: Again, I was unsure about this so put it in and waited for comment. I have a chart of 27 events and 6 states in which I have colored in the connect retry and peer oscillation damping actions and it looks like measles; I could not divine the underlying logic. Incrementing the connect retry count would make as much if not more sense to me. (It is zeroed for Manual Stop). But the action '[optionally] perform peer oscillation damping' is yet more erratic (eg for event 10 - Hold Timer expired - it is performed exiting Connect, Active, Established but not Open Confirm or Open Sent) so I left it out. Again, it might make more sense put it in. Sue replied to this: The connect state could have a few resources (minimum peer footprint) as the FSM goes from Idle to Connected state. While this amount of BGP resources is not as much as the final amount, it still needs to get released. 2nd - I think the connectretrycount should be removed; Thanks for catching that. Please confirm that part #1 is OK with you so we can put issue 45 into consensus state. Sue accpeted Tom's solution, for the following text: If the TCP connection fails [Event18], the local system checks the Open Delay Timer. If the Open Delay timer is running, the local system: - restarts the connect retry timer, - stops the Open Delay timer and resets value to zero, - continues to listen for a connection that may be initiated by the remote BGP peer, and - changes its state to Active. If the open Delay timer is not running, the locla system: - resets the connect retry timer (sets to zero), and - Drops the TCP connection, - Releases all BGP resources, - and goes to Idle State. N.B. This is now event 18 (see issue 26). We are at consensus with this. This was discussed in the "Comments 21-30" thread: Comment #26. This was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. ---------------------------------------------------------------------------- 46) Handling of Event 17 in Active state ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: See issue 13.4, this issue closed in favor of that one. Discussion: This began with Siva saying: We should now move into Idle state. Can we add % - Goes to Idle state Sue replied that she thought this should be bundled in with the issue tracked in 13.4. Since no one objected, this issue has been closed in favor of that one. This was discussed in the "Comments 21-30" thread: Comment #27. ---------------------------------------------------------------------------- 47) Handling of Event 19 in Active state ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Add the new text in the discussion section. Discussion: This began with Siva suggesting: > - Set the Hold timer to a large value (4 minutes), Since OPEN messages have been exchanged, can we change this to % - If the negotiated Hold time is not 0, set the Hold time to % - the negotiated value Sue replied that: The text in Active and Open Sent needs to be the same. The text in Open Sent is: - sets the Hold timer according to the negotiated value (see section 4.2), and Which text do you prefer? Sue replied that this text would be added to the next draft: New text - if the hold timer value is non-zero, - starts the keepalive timer to initial value, - resets the hold timer to the negotiated value, - else if the hold timer is zero - resets the keepalive timer (set to zero), - resets the hold timer to zero. This seems to address Siva's concerns, this issue is at consensus, if there are objections, we can reopen it. This was discussed in the "Comments 21-30" thread: Comment #28. This was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. ---------------------------------------------------------------------------- 48) Handling of Event 2 in Active state ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Update the draft with the text at the end of the discussion section. Discussion: Siva opened with: > A manual stop event[Event2], the local system: > - Sends a notification with a Cease, > - drops the Transport connection These two actions are possible only if a transport connection had already been established. How about changing the text to % - If a transport connection had been successfully established % - Send a Notification with a Cease % - Drop the Transport Connection Sue counter suggested: A manual stop event [Event 2], the local system - Drop the TCP connection, - Release all BGP resources, - resets the connection retry timer [sets to zero], - goes to Idle. Jeff replied: I'm rather confused. Under exactly what circumstances can we be in the Active state and have an active TCP connection at all? Ditto for having any BGP resources? Going to Idle is fine. Tom offered this example: eg start with passive flag, TCP SYN received, SYN-ACK sent, ACK received, Delay Open flag set and there we are. Most events are now possible either from a well-implemented remote peer or a badly implemented remote peer. Sue asked if there were any additional comments, if not, the text will be: A manual stop event[Event2], the local system: - Sends a NOTIFICATION with a Cease, - releases all BGP resources including - stopping the OPen delay timer - drops the TCP connection, - sets ConnectRetryCnt (connect retry count) to zero - resets the connect retry timer (sets to zero), - changes its state to Idle. There have been no additional comments, we will use the text Sue proposed. This was discussed in the "Comments 21-30" thread: Comment #29. This was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. ---------------------------------------------------------------------------- 49) Default Event handling in Active state ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: No routes in active. Discussion: Siva began with: To ensure consistencey with E2 handling, can we add % - If any BGP Routes exist, delete the routes Sue replied: Comment: Yakov and Jeff noted, there are no routes in Active state. Since there were no responses disagreeing, we'll consider this closed unless someone wants to open it back up. This was discussed in the "Comments 21-30" thread: Comment #30. ---------------------------------------------------------------------------- 50) Clearing Hold timer in OpenSent, OpenConfirm and Established State ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: This issue is addressed in the "Clear BGP resources" Discussion: This began with Siva stating: In all event handling where we go to Idle state, we need to clear the Hold Timer as well. Sue replied that: issue resolve one way last Jan - March Clearing of keep alive timer included in Clear BGP resources No response to this yet, but since this seems to be resolved it is at consensus unless someone objects. This was discussed in the "Comments 30-36" thread: Comment #31. ---------------------------------------------------------------------------- 51) Clearing Keepalive timer in OpenConfirm and Established State ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: This issue is addressed in the "Clear BGP resources" Discussion: This began with Siva stating: In all event handling where we go to Idle state, we need to clear the Keepalive Timer as well. Sue replied that: issue resolve one way last Jan - March Clearing of keep alive timer included in Clear BGP resources No response to this yet, but since this seems to be resolved it is at consensus unless someone objects. This was discussed in the "Comments 30-36" thread: Comment #32. ---------------------------------------------------------------------------- 52) Handling Event 18 in the OpenSent state (Keepalive Timer) ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Make the event optional. Discussion: This began with Siva asking: Why do we start the Keepalive timer at this stage ? Isn't it sufficient to do so when we move into Established state ? Sue replied: An earlier comment from Tom (and you) requested the following: <---Open [Open sent state] Open--> [Event 18] <---Open <---Keepalive [Action from Event 18 in Open Sent] [Open Confirm] Keepalive -> [Event 25] [established] What do implementations do? We'll have to query implementations. Jeff added: I'm assuming the second OPEN going from right to left is a typo. If it isn't, thats a FSM error to the peer on the left. Theoretically, an implementation that utilizes its keepalive timer to send the first keepalive to transition to Established is still interoperable. However: o Keepalives can be disabled by negotiating hold time of zero o We really shouldn't need to restart the Keepalive timer. If there is a delay in the keepalive that transitions from OpenConfirm to Established, its due to the transport connection. It should be reliable and it *should* get through. If it doesn't, there's other problems and the hold timer for the peer on the right should do the Right Thing and drop the connection. > What do implementations do? We'll have to query implementations. GateD at least waits to enter the Established state prior to starting the KeepAlive timer. Tom also added: My comment was that if we do not send a KeepAlive (and start the KeepAlive timer), on exiting from Active with Event 19 to OpenConfirm then we never will and the connection will die. Open Confirm state means valid Open received so we must send a KeepAlive to acknowledge the Open (as pointed out in Jeff's other posting) and we never do it in OpenConfirm state itself (unless the KeepAlive timer expires which it cannot because we have not started it). So for me, OpenSent state Event 18 was and is correct, sending the KeepAlive without which the connection goes no further and Active state Event 19 needs to be brought into line. To say that the timer is started when entering Established state is fine except for a slight problem; we have no way in this FSM of defining actions that are taken on entering a state, only actions to be taken on leaving another state so that is why the KeepAlive actions need to be where they are (or are not in the case of Active state Event 19). Sue replied, asking more implementors to chime in on what they do for this part of the FSM. Curits replied that we should: Make it optional. Timing out in open or open-sent has never been much of an issue, so whether one or three keepalive get sent shouldn't be a hot topic. Sue said that this was fine, and she would work on text specifying optional. Jeff replied regarding GateD's behavior: GateD will start its keepalive timer while in this state, so multiple keepalives will be sent. As someone previously said, this is a "yawn" issue. But to choose one way or the other, we may potentially make someone in non-compliance. From the closure of issue 12, we have this text, which discusses Keepalives to consider in relation to the other keepalive issue here: Change 1: new text Active state - event 19 If an Open is received with the Open Delay timer is running [Event 19], the local system - clears the connect retry timer (cleared to zero), - stops and clears the Open Delay timer - completes the BGP initialization, - stops and clears the Open Delay timer - sends an OPEN message, - send a Keepalive message, - if the hold timer value is non-zero, - starts the keepalive timer to initial value, - resets the hold timer to the negotiated value, else if the hold timer is zero - resets the keepalive timer (set to zero), - resets the hold timer to zero. - changes its state to OpenConfirm. If the value of the autonomous system field is the same as the local Autonomous System number, set the connection status to an internal connection; otherwise it is "external". Sicne there were no more comments, this is at consensus. This was discussed in the "Comments 30-36" thread: Comment #33. And in the "BGP-draft-19: Issue 52 - Event 18 in OpenSent State (Keepalive timer set)" thread. ---------------------------------------------------------------------------- 53) Established State MIB ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: MIB references pulled in favor of having them in the MIB document. See issue 8. Discussion: This began with Siva asking: Some event handling in the Established state do not set the MIB Reason when handling an event that causes an error. Can we add this ? Sue replied that we have pulled the MIB wording from the FSM. See issue 8. This was discussed in the "Comments 30-36" thread: Comment #34. ---------------------------------------------------------------------------- 54) State impact of not supporting Optional Events ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Add the text at the end of the discussion section. Discussion: Siva stated that: For the events whose status is optional, can we state the impact of not supporting them (in terms of any interoperability issues). I understand that most of the optional events will not have such an impact; but a clarification statement for the optional events would benefit new implementors. Sue responded: Much of the support of optional parameters depends on policy. I could put a short note about the optional events and parameters as part of 8.1.5 or 8.2.1.3 I think it fits better in 8.1.5. Optional: Events: 3-8, 12, 13-14[my suggestion] 19, 22 Timers: Idle Hold Timer Open Delay Timer Required flags for optional parameters: Open Delay Flag BGP Stop Flap Sue said she would try to work up more if it is agreed that this is on the right track. Sue provided this text to clarify the behavior associated with Optional Attributes: 8.2.1.3 FSM and Optional Attributes Optional Attributes specify either flags that augment the normal processing of the BGP FSM, or optional timers. If a Optional attribute can be set on a system, the Events and the BGP FSM actions must be support. For example, if the following options can be set in a BGP implementation: AutoStart and Passive TCP connection Establishment flag, then the events 3, 4 and 5 must be supported. If an Optional attribute cannot be set (that is declared always off logically), the events supporting that set of options do not have to be supported. This was discussed in the "Comments 30-36" thread: Comment #35. ---------------------------------------------------------------------------- 55) New DelayOpen State ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: We've chosen not to reopen the debate about adding a DelayOpen State to the FSM. Discussion: Siva began with asking: Is delaying the sending of an OPEN message a standrad industry practice ? Also, in the FSM, this has been handled by practically implementing a sub-state each, within the CONNECT and ACTIVE states. Won't the FSM look more simple if we just had a new DelayOpen state that we could move into ? Sue responded that this was something we have tried to do before, but that it spawned some degree of rabid response on both sides. Given our current mandate to stick with what is implemented, it is probably best not to reopen this debate. Unless someone badly wants to reopen this debate, the issue is at Consenus. This was discussed in the "Comments 21-30" thread: Comment #22. This was discussed in the "Comments 21-30" thread: Comment #26. This was discussed in the "Comments 30-36" thread: Comment #36. ---------------------------------------------------------------------------- 56) Clarify what is covered in the base document. ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Add the text at the end of the discussion to clarify what is documented where with regard to BGP and its extentions. Discussion: This grew out of a discussion on how to use BGP Identifiers in an IPv6-only environment. In that discussion it became clear that the way the documents are currently structured it is not clear to new readers that extention specifications can and do specify behavior that superseeds the behavior specified in the base spec. To that end it was agreed that this text should be added: This document specifies the base behavior of the BGP protocol. This behavior can and is modified by extention specifications. When the protocol is extended the new behavior is fully documented in the extention specifications. This was discussed in the "Next-Hop in IPv6 only environments" thread. --Izn7cH1Com+I3R9J Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="Changelog-v2.txt" CHANGELOG ---------------------------------------------------------------------------- v2.2 to v2.3 2003-02-26 ---------------------------------------------------------------------------- Added: 56) Clarify what is covered in the base document. Updated: 18) MED Removal Text 24) Events 3, 5, 6 & 7 Give Examples 26) Event 4 & 5 - bgp_stop_flap option 33) Event 13 & 14 - Valid Addresses & Ports 41) Handling of Event 14 in the Connect State 42) Handling events 20, 21 in the Connect State and Active State 44) Handling Event 23 in Connect and OpenSent 45) Event 17 in the Connect state 52) Handling Event 18 in the OpenSent state (Keepalive Timer) 54) State impact of not supporting Optional Events Moved to Consensus: 18) MED Removal Text 24) Events 3, 5, 6 & 7 Give Examples 26) Event 4 & 5 - bgp_stop_flap option 33) Event 13 & 14 - Valid Addresses & Ports 41) Handling of Event 14 in the Connect State 42) Handling events 20, 21 in the Connect State and Active State 44) Handling Event 23 in Connect and OpenSent 45) Event 17 in the Connect state 52) Handling Event 18 in the OpenSent state (Keepalive Timer) 54) State impact of not supporting Optional Events 56) Clarify what is covered in the base document. ---------------------------------------------------------------------------- v2.1 to v2.2 2003-01-30 ---------------------------------------------------------------------------- Updated: 12) Entering OpenConfirm / Adding "Stop OpenDelay" action 13) FSM Missing Next States 13.2) FSM Missing Next States - Event 14 (Connect State) 13.4) FSM Missing Next States - Event 13-17 (TCP Connection) 13.6) FSM Missing Next States - Event 18 (Open Confirm) 17) Section 3, Page 8, Paragraph 3 - Obsolete? 18) MED Removal Text 21) Session Attributes - IdleHold Timer 22) Specify New Attributes (Accept Connections/Peer Oscillation Damping) 24) Events 3, 5, 6 & 7 Give Examples 26) Event 4 & 5 - bgp_stop_flap option 34) Event 17 - TCP Connection Fails to TCP Connection Termination 35) Making Definition Style Consistant 40) Clearing the Connection Retry Timer 41) Handling of Event 14 in the Connect State 42) Handling events 20, 21 in the Connect State and Active State 43) Handling the default events in the Connect state 44) Handling Event 23 in Connect and OpenSent 45) Event 17 in the Connect state 47) Handling of Event 19 in Active state 48) Handling of Event 2 in Active state 52) Handling Event 18 in the OpenSent state (Keepalive Timer) Moved to Consensus: 12) Entering OpenConfirm / Adding "Stop OpenDelay" action 13) FSM Missing Next States 13.2) FSM Missing Next States - Event 14 (Connect State) 13.4) FSM Missing Next States - Event 13-17 (TCP Connection) 13.6) FSM Missing Next States - Event 18 (Open Confirm) 17) Section 3, Page 8, Paragraph 3 - Obsolete? 34) Event 17 - TCP Connection Fails to TCP Connection Termination 35) Making Definition Style Consistant 40) Clearing the Connection Retry Timer 43) Handling the default events in the Connect state 47) Handling of Event 19 in Active state 48) Handling of Event 2 in Active state ---------------------------------------------------------------------------- v2.0 to v2.1 2003-01-20 ---------------------------------------------------------------------------- Updated: 2) MUST/SHOULD Capitalization 13.2) FSM Missing Next States - Event 14 (Connect State) 13.4) FSM Missing Next States - Event 13-17 (TCP Connection) 13.5) FSM Missing Next States - Event 17 (Connect State) 13.6) FSM Missing Next States - Event 18 (Open Confirm) 15) FSM - Consistent FSM Event Names 17) Section 3, Page 8, Paragraph 3 - Obsolete? 21) Session Attributes - IdleHold Timer 22) Specify New Attributes (Accept Connections/Peer Oscillation Damping) 24) Events 3, 5, 6 & 7 Give Examples 26) Event 4 & 5 - bgp_stop_flap option 33) Event 13 & 14 - Valid Addresses & Ports 45) Event 17 in the Connect state Moved to Consensus: 13.5) FSM Missing Next States - Event 17 (Connect State) 15) FSM - Consistent FSM Event Names 21) Session Attributes - IdleHold Timer 22) Specify New Attributes (Accept Connections/Peer Oscillation Damping) --Izn7cH1Com+I3R9J-- From owner-idr@merit.edu Wed Feb 26 16:46:02 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27418 for ; Wed, 26 Feb 2003 16:46:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B33A59125A; Wed, 26 Feb 2003 16:49:52 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 82EA19125C; Wed, 26 Feb 2003 16:49:52 -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 31DC79125A for ; Wed, 26 Feb 2003 16:49:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 174615DE50; Wed, 26 Feb 2003 16:49:51 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 792CE5DD95 for ; Wed, 26 Feb 2003 16:49:50 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.11.3/8.11.1) id h1QLoLo01359 for idr@merit.edu; Wed, 26 Feb 2003 16:50:21 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.nexthop.com (8.11.3/8.11.1) with ESMTP id h1QLoA101332 for ; Wed, 26 Feb 2003 16:50:10 -0500 (EST) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: BGP Base Draft - Issue List v2.3 (Draft-19) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 26 Feb 2003 16:49:39 -0500 Message-ID: Thread-Topic: BGP Base Draft - Issue List v2.3 (Draft-19) Thread-Index: AcLd1/HO7D/GsXF/QcaAtlwzlbdBkQACO0RQ From: "Susan Hares" To: Cc: X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA27418 Andrew: Thanks for the latest version of the list. sue -----Original Message----- From: andrewl@xix-w.bengi.exodus.net [mailto:andrewl@xix-w.bengi.exodus.net] Sent: Wednesday, February 26, 2003 3:42 PM To: idr@merit.edu Cc: andrewl@xix-w.bengi.exodus.net Subject: BGP Base Draft - Issue List v2.3 (Draft-19) Greetings, Attached is v2.3 of the issues list, and the associated changelog. As of this moment, all of the issues are at consensus. However, I do know that there are some concerns still extant, and that may result in either issues being reopened, or new issues being added. Andrew From owner-idr@merit.edu Wed Feb 26 16:49:01 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27565 for ; Wed, 26 Feb 2003 16:49:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E38EB9125C; Wed, 26 Feb 2003 16:52:46 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB1FF9125D; Wed, 26 Feb 2003 16:52: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 47CE69125C for ; Wed, 26 Feb 2003 16:52:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2D6C65DEEF; Wed, 26 Feb 2003 16:52:45 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 1EEBB5DEE1 for ; Wed, 26 Feb 2003 16:52:42 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.11.3/8.11.1) id h1QLqfp01880 for idr@merit.edu; Wed, 26 Feb 2003 16:52:41 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.nexthop.com (8.11.3/8.11.1) with ESMTP id h1QLqD101789 for ; Wed, 26 Feb 2003 16:52:13 -0500 (EST) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Next-Hop in IPv6 only environment X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 26 Feb 2003 16:52:13 -0500 Message-ID: Thread-Topic: Next-Hop in IPv6 only environment Thread-Index: AcLc8MMeIwIZanxmTjmEnf3z8LcP9QA8Hizg From: "Susan Hares" To: "Alex Zinin" , "Curtis Villamizar" Cc: "Yakov Rekhter" , , "Manav Bhatia" , "Enke Chen" , "Jeffrey Haas" , , X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA27565 Alex: Thanks for the note. Sue -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Tuesday, February 25, 2003 12:10 PM To: Curtis Villamizar Cc: Yakov Rekhter; Susan Hares; andrewl@xix-w.bengi.exodus.net; Manav Bhatia; Enke Chen; Jeffrey Haas; mjh@icir.org; idr@merit.edu Subject: Re: Next-Hop in IPv6 only environment While something like this definitely wouldn't harm the spec, I don't think it is really required--a situation where the base spec is more recent than the extensions is absolutely normal and happens quite often. A higher number of the base RFC does not mean it obsoletes the extension spec, whatever RFC number that is. Example: OSPFv2 spec: RFC2328; the demand circuit extension to it suppressing Hello's on a link: RFC1793... and no disclaimers that extensions may modify the described behavior, and no confusion :) Then again, it's a minor question. If you guys believe it's a good idea to have something like this in the text--sure. -- Alex Tuesday, February 25, 2003, 8:54:02 AM, Curtis Villamizar wrote: > In message <200302251607.h1PG7WS85809@merlot.juniper.net>, Yakov Rekhter writes > : >> > >> > My understanding from the ADs is that >> > we are completing the Base specification >> > first without any additions. >> > >> > After we have completed the 1st version of >> > the base specification, I believe the ADs >> > will re-open the charter to these additions. >> > It is my understanding that we will deal >> > with IPv6 issues after this point. >> > >> > Yakov, Bill and Alex - am I correct? >> >> I think that adding the text suggested by Andrew would be fine. >> >> Yakov. > A worthwhile clarification since it keeps coming up on the list. I > agree that it is worth adding Andrew's text either to the front or as > an additional "Protocol Extensions" appendix at the very end. > Curtis >> > If there is confusion on this issue, I would suggest we add a statement >> > like this: >> > >> > This document specifies the base behavior of the BGP protocol. This >> > behavior can and is modified by extention specifications. When the >> > protocol is extended the new behavior is fully documented in the >> > extention specifications. >> > >> > to the beginning of the document somewhere. >> > >> > Andrew From owner-idr@merit.edu Fri Feb 28 13:56:21 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08884 for ; Fri, 28 Feb 2003 13:56:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9080E912A7; Fri, 28 Feb 2003 13:59:59 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 57E6E912A8; Fri, 28 Feb 2003 13:59: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 00F09912A7 for ; Fri, 28 Feb 2003 13:59:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id DC9225DE8F; Fri, 28 Feb 2003 13:59:57 -0500 (EST) Delivered-To: idr@merit.edu Received: from web14108.mail.yahoo.com (web14108.mail.yahoo.com [216.136.172.138]) by segue.merit.edu (Postfix) with SMTP id 67DA75DE8E for ; Fri, 28 Feb 2003 13:59:57 -0500 (EST) Message-ID: <20030228185956.64632.qmail@web14108.mail.yahoo.com> Received: from [47.234.0.51] by web14108.mail.yahoo.com via HTTP; Fri, 28 Feb 2003 10:59:56 PST Date: Fri, 28 Feb 2003 10:59:56 -0800 (PST) From: PamSri Subject: Regarding BGP Router ID To: idr@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Hi , The latest base draft of BGP talks about BGP identifier as follows: "If the BGP Identifier field of the OPEN message is syntactically incorrect, then the Error Subcode is set to Bad BGP Identifier. Syn-tactic correctness means that the BGP Identifier field represents a valid IP host address." Does this mean that BGP Identifier has be a routable address ? sri __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-idr@merit.edu Fri Feb 28 14:00:22 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09042 for ; Fri, 28 Feb 2003 14:00:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2EDEE912A8; Fri, 28 Feb 2003 14:04:14 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51272912A9; Fri, 28 Feb 2003 14:04: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 4F0DD912A8 for ; Fri, 28 Feb 2003 14:03:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2A8AE5DE7D; Fri, 28 Feb 2003 14:03:40 -0500 (EST) Delivered-To: idr@merit.edu Received: from web14102.mail.yahoo.com (web14102.mail.yahoo.com [216.136.172.132]) by segue.merit.edu (Postfix) with SMTP id 5DD8B5DE1C for ; Fri, 28 Feb 2003 14:03:39 -0500 (EST) Message-ID: <20030228190338.3349.qmail@web14102.mail.yahoo.com> Received: from [47.234.0.51] by web14102.mail.yahoo.com via HTTP; Fri, 28 Feb 2003 11:03:38 PST Date: Fri, 28 Feb 2003 11:03:38 -0800 (PST) From: PamSri Subject: Re: Regarding BGP Router ID To: idr@merit.edu In-Reply-To: <20030228185956.64632.qmail@web14108.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Actually by routable i mean reachable address. sri --- PamSri wrote: > Hi , > The latest base draft of BGP talks about BGP > identifier as follows: > > "If the BGP Identifier field of the OPEN message is > syntactically incorrect, then the Error Subcode is > set > to Bad BGP Identifier. Syn-tactic correctness means > that the BGP Identifier field represents a valid IP > host address." > > Does this mean that BGP Identifier has be a routable > address ? > > sri > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-idr@merit.edu Fri Feb 28 14:03:03 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09094 for ; Fri, 28 Feb 2003 14:03:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8D538912A9; Fri, 28 Feb 2003 14:06:51 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CD18912AB; Fri, 28 Feb 2003 14:06: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 40BCD912A9 for ; Fri, 28 Feb 2003 14:06:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 304255DE91; Fri, 28 Feb 2003 14:06:50 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 936165DE90 for ; Fri, 28 Feb 2003 14:06:49 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.11.3/8.11.1) id h1SJ6lJ64581; Fri, 28 Feb 2003 14:06:47 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.11.3/8.11.1) with ESMTP id h1SJ6i164574; Fri, 28 Feb 2003 14:06:44 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h1SJ6ii19494; Fri, 28 Feb 2003 14:06:44 -0500 (EST) Date: Fri, 28 Feb 2003 14:06:44 -0500 From: Jeffrey Haas To: PamSri Cc: idr@merit.edu Subject: Re: Regarding BGP Router ID Message-ID: <20030228140644.I16411@nexthop.com> References: <20030228185956.64632.qmail@web14108.mail.yahoo.com> <20030228190338.3349.qmail@web14102.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030228190338.3349.qmail@web14102.mail.yahoo.com>; from pamsri01@yahoo.com on Fri, Feb 28, 2003 at 11:03:38AM -0800 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Fri, Feb 28, 2003 at 11:03:38AM -0800, PamSri wrote: > Actually by routable i mean reachable address. Best current practice would say "yes" with this typically being the host's "loopback" address. However, as noted in the archives and in the v6-only router-id ID for BGP, its just a number. However, its one that may cause interoperability problems if one party treats it as a number and the other insists on syntactic correctness. > sri -- Jeff Haas NextHop Technologies From owner-idr@merit.edu Fri Feb 28 14:16:51 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09433 for ; Fri, 28 Feb 2003 14:16:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3FDD5912AB; Fri, 28 Feb 2003 14:20:39 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D5A7912AC; Fri, 28 Feb 2003 14:20:38 -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 AE972912AB for ; Fri, 28 Feb 2003 14:20:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8B63E5DE8E; Fri, 28 Feb 2003 14:20:37 -0500 (EST) Delivered-To: idr@merit.edu Received: from web14108.mail.yahoo.com (web14108.mail.yahoo.com [216.136.172.138]) by segue.merit.edu (Postfix) with SMTP id BBD1B5DE83 for ; Fri, 28 Feb 2003 14:20:36 -0500 (EST) Message-ID: <20030228192036.68699.qmail@web14108.mail.yahoo.com> Received: from [47.234.0.51] by web14108.mail.yahoo.com via HTTP; Fri, 28 Feb 2003 11:20:36 PST Date: Fri, 28 Feb 2003 11:20:36 -0800 (PST) From: PamSri Subject: Re: Regarding BGP Router ID To: Jeffrey Haas Cc: idr@merit.edu In-Reply-To: <20030228140644.I16411@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Can you give me a reason why the configured IP of the Router ID needs to be reachable ? So for example if i were to configure x.x.x.x for my router ID (which is a loopback address) why does someone need to be able to ping it in order for my peering session to be UP ? sri --- Jeffrey Haas wrote: > On Fri, Feb 28, 2003 at 11:03:38AM -0800, PamSri > wrote: > > Actually by routable i mean reachable address. > > Best current practice would say "yes" with this > typically being > the host's "loopback" address. > > However, as noted in the archives and in the v6-only > router-id > ID for BGP, its just a number. However, its one > that may cause > interoperability problems if one party treats it as > a number and > the other insists on syntactic correctness. > > > sri > > -- > Jeff Haas > NextHop Technologies __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-idr@merit.edu Fri Feb 28 14:27:14 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09702 for ; Fri, 28 Feb 2003 14:27:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 14C4A912AD; Fri, 28 Feb 2003 14:30:30 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D45F1912AE; Fri, 28 Feb 2003 14:30:29 -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 A8842912AD for ; Fri, 28 Feb 2003 14:30:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 11F0D5DE93; Fri, 28 Feb 2003 14:30:26 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 9F8645DE69 for ; Fri, 28 Feb 2003 14:30:25 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.11.3/8.11.1) id h1SJUOW65280; Fri, 28 Feb 2003 14:30:24 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.11.3/8.11.1) with ESMTP id h1SJUK165273; Fri, 28 Feb 2003 14:30:20 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h1SJUKg19996; Fri, 28 Feb 2003 14:30:20 -0500 (EST) Date: Fri, 28 Feb 2003 14:30:20 -0500 From: Jeffrey Haas To: PamSri Cc: idr@merit.edu Subject: Re: Regarding BGP Router ID Message-ID: <20030228143020.J16411@nexthop.com> References: <20030228140644.I16411@nexthop.com> <20030228192036.68699.qmail@web14108.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030228192036.68699.qmail@web14108.mail.yahoo.com>; from pamsri01@yahoo.com on Fri, Feb 28, 2003 at 11:20:36AM -0800 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Fri, Feb 28, 2003 at 11:20:36AM -0800, PamSri wrote: > Can you give me a reason why the configured IP of the > Router ID needs to be reachable ? So for example if i > were to configure x.x.x.x for my router ID (which is a > loopback address) why does someone need to be able to > ping it in order for my peering session to be UP ? To attempt to summarize way too much list archives, it *doesn't*. The BGP Identifier is just a number. However, for purposes of operations, it is very handy to have the number in your internal network for troubleshooting. Outside of your network (in the aggregator field), its handy to have it to figure out what box may have done a bit of aggregation. But even then, all you really need is a number along with the AS to pass that back to the aggregating network for troubleshooting purposes. Its also notable that loopback addresses are often reachable within a given AS, but access is administratively denied outside or perhaps even denied from anything other than the management network. > sri -- Jeff Haas NextHop Technologies From owner-idr@merit.edu Fri Feb 28 14:35:05 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09994 for ; Fri, 28 Feb 2003 14:35:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5B5DC91243; Fri, 28 Feb 2003 14:38:53 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 290BB912AE; Fri, 28 Feb 2003 14:38: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 16E5991243 for ; Fri, 28 Feb 2003 14:38:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id F00225DE92; Fri, 28 Feb 2003 14:38:51 -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 C96025DE7D for ; Fri, 28 Feb 2003 14:38:51 -0500 (EST) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 2DCA442C744; Fri, 28 Feb 2003 11:38:51 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id D5E6215D3C1; Fri, 28 Feb 2003 11:38:50 -0800 (PST) To: PamSri Cc: idr@merit.edu, enke@redback.com Subject: Re: Regarding BGP Router ID In-Reply-To: Message from PamSri of "Fri, 28 Feb 2003 10:59:56 PST." <20030228185956.64632.qmail@web14108.mail.yahoo.com> Date: Fri, 28 Feb 2003 11:38:50 -0800 From: Enke Chen Message-Id: <20030228193850.D5E6215D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Sri: Please read the document that clarifies and relaxes the requirements for BGP Identifier. -- Enke > Message-ID: <20030228185956.64632.qmail@web14108.mail.yahoo.com> > Received: from [47.234.0.51] by web14108.mail.yahoo.com via HTTP; Fri, 28 Feb 2003 10:59:56 PST > Date: Fri, 28 Feb 2003 10:59:56 -0800 (PST) > From: PamSri > Subject: Regarding BGP Router ID > To: idr@merit.edu > > Hi , > The latest base draft of BGP talks about BGP > identifier as follows: > > "If the BGP Identifier field of the OPEN message is > syntactically incorrect, then the Error Subcode is set > to Bad BGP Identifier. Syn-tactic correctness means > that the BGP Identifier field represents a valid IP > host address." > > Does this mean that BGP Identifier has be a routable > address ? > > sri > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ From owner-idr@merit.edu Fri Feb 28 14:37:59 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10116 for ; Fri, 28 Feb 2003 14:37:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5BC31912AE; Fri, 28 Feb 2003 14:41:46 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F4F3912AF; Fri, 28 Feb 2003 14:41: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 CE8AE912AE for ; Fri, 28 Feb 2003 14:41:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id B38D15DE9C; Fri, 28 Feb 2003 14:41:44 -0500 (EST) Delivered-To: idr@merit.edu Received: from web14101.mail.yahoo.com (web14101.mail.yahoo.com [216.136.172.131]) by segue.merit.edu (Postfix) with SMTP id D75805DE92 for ; Fri, 28 Feb 2003 14:41:43 -0500 (EST) Message-ID: <20030228194143.10132.qmail@web14101.mail.yahoo.com> Received: from [47.234.0.51] by web14101.mail.yahoo.com via HTTP; Fri, 28 Feb 2003 11:41:43 PST Date: Fri, 28 Feb 2003 11:41:43 -0800 (PST) From: PamSri Subject: Re: Regarding BGP Router ID To: idr@merit.edu In-Reply-To: <20030228143020.J16411@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Not sure if you have covered all the scenarios but mindful of the fact that this entity is something that gets shared. It can cause potential security issues in VPN scenarios. Maybe your observation over simplifies this case. sri --- Jeffrey Haas wrote: > On Fri, Feb 28, 2003 at 11:20:36AM -0800, PamSri > wrote: > > Can you give me a reason why the configured IP of > the > > Router ID needs to be reachable ? So for example > if i > > were to configure x.x.x.x for my router ID (which > is a > > loopback address) why does someone need to be able > to > > ping it in order for my peering session to be UP ? > > To attempt to summarize way too much list archives, > it *doesn't*. > The BGP Identifier is just a number. > > However, for purposes of operations, it is very > handy to have the > number in your internal network for troubleshooting. > Outside of > your network (in the aggregator field), its handy to > have it to figure > out what box may have done a bit of aggregation. > But even then, > all you really need is a number along with the AS to > pass that back > to the aggregating network for troubleshooting > purposes. > > Its also notable that loopback addresses are often > reachable within > a given AS, but access is administratively denied > outside or > perhaps even denied from anything other than the > management network. > > > sri > > -- > Jeff Haas > NextHop Technologies __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-idr@merit.edu Fri Feb 28 14:39:43 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10163 for ; Fri, 28 Feb 2003 14:39:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EE3FB912AF; Fri, 28 Feb 2003 14:43:37 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BDC48912B0; Fri, 28 Feb 2003 14:43: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 ADD91912AF for ; Fri, 28 Feb 2003 14:43:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9C08E5DE9C; Fri, 28 Feb 2003 14:43:35 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 096C55DE98 for ; Fri, 28 Feb 2003 14:43:35 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.11.3/8.11.1) id h1SJhWk65704; Fri, 28 Feb 2003 14:43:32 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.11.3/8.11.1) with ESMTP id h1SJhT165697; Fri, 28 Feb 2003 14:43:29 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h1SJhT920239; Fri, 28 Feb 2003 14:43:29 -0500 (EST) Date: Fri, 28 Feb 2003 14:43:28 -0500 From: Jeffrey Haas To: PamSri Cc: idr@merit.edu Subject: Re: Regarding BGP Router ID Message-ID: <20030228144328.K16411@nexthop.com> References: <20030228143020.J16411@nexthop.com> <20030228194143.10132.qmail@web14101.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030228194143.10132.qmail@web14101.mail.yahoo.com>; from pamsri01@yahoo.com on Fri, Feb 28, 2003 at 11:41:43AM -0800 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Fri, Feb 28, 2003 at 11:41:43AM -0800, PamSri wrote: > gets shared. It can cause potential security issues > in VPN scenarios. Could you clarify? > sri -- Jeff Haas NextHop Technologies From owner-idr@merit.edu Fri Feb 28 19:04:21 2003 Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17556 for ; Fri, 28 Feb 2003 19:04:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C576E912DB; Fri, 28 Feb 2003 19:06:11 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8CB36912DC; Fri, 28 Feb 2003 19:06: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 8569C912DB for ; Fri, 28 Feb 2003 19:05:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5D3CF5DEC2; Fri, 28 Feb 2003 19:05:41 -0500 (EST) Delivered-To: idr@merit.edu Received: from web14104.mail.yahoo.com (web14104.mail.yahoo.com [216.136.172.134]) by segue.merit.edu (Postfix) with SMTP id C0CA85DEA7 for ; Fri, 28 Feb 2003 19:05:40 -0500 (EST) Message-ID: <20030301000539.17085.qmail@web14104.mail.yahoo.com> Received: from [151.203.103.112] by web14104.mail.yahoo.com via HTTP; Fri, 28 Feb 2003 16:05:39 PST Date: Fri, 28 Feb 2003 16:05:39 -0800 (PST) From: PamSri Subject: Re: Regarding BGP Router ID To: Jeffrey Haas Cc: idr@merit.edu In-Reply-To: <20030228144328.K16411@nexthop.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1838290710-1046477139=:17002" Sender: owner-idr@merit.edu Precedence: bulk --0-1838290710-1046477139=:17002 Content-Type: text/plain; charset=us-ascii The nexthop for the VPNIPv4 prefixes will be exposed in terms of Router ID. Following is the example: EBGP IBGP x <------------------------------> y <--------------------------------------> z y is attached to VRF red & green. y has the loop back address of Y and z Z respectively. The IBGP peering is between Y & Z. For the VRFs y is attached to, all the prefixes get advertised to Z with nexthop of Y. Now the point that i am raising is in the OPEN messages to x and Z, y sends Y which turns out to be the next hop for the VPNIPv4 prefixes. Hence i said that there is a potential for security issues in the case of VPNs where we want the prefixes as well as the nexthops protected. sri Jeffrey Haas wrote:On Fri, Feb 28, 2003 at 11:41:43AM -0800, PamSri wrote: > gets shared. It can cause potential security issues > in VPN scenarios. Could you clarify? > sri -- Jeff Haas NextHop Technologies --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more --0-1838290710-1046477139=:17002 Content-Type: text/html; charset=us-ascii

The nexthop for the VPNIPv4 prefixes will be exposed in terms of Router ID. Following is the example:

                EBGP                               IBGP

x <------------------------------> y <--------------------------------------> z

y is attached to VRF red & green. y has the loop back address of Y and z Z respectively.

The IBGP peering is between Y & Z. For the VRFs y is attached to, all the prefixes get advertised to Z with nexthop of Y. Now the point that i am raising is in the OPEN messages to x and Z, y sends Y which turns out to be the next hop for the VPNIPv4 prefixes. Hence i said that there is a potential for security issues in the case of VPNs where we want the prefixes as well as the nexthops protected.

sri

 Jeffrey Haas <jhaas@nexthop.com> wrote:

On Fri, Feb 28, 2003 at 11:41:43AM -0800, PamSri wrote:
> gets shared. It can cause potential security issues
> in VPN scenarios.

Could you clarify?

> sri

--
Jeff Haas
NextHop Technologies


Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, and more --0-1838290710-1046477139=:17002-- 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 TAA28483 for ; Fri, 28 Feb 2003 19:06:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C576E912DB; Fri, 28 Feb 2003 19:06:11 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8CB36912DC; Fri, 28 Feb 2003 19:06: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 8569C912DB for ; Fri, 28 Feb 2003 19:05:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5D3CF5DEC2; Fri, 28 Feb 2003 19:05:41 -0500 (EST) Delivered-To: idr@merit.edu Received: from web14104.mail.yahoo.com (web14104.mail.yahoo.com [216.136.172.134]) by segue.merit.edu (Postfix) with SMTP id C0CA85DEA7 for ; Fri, 28 Feb 2003 19:05:40 -0500 (EST) Message-ID: <20030301000539.17085.qmail@web14104.mail.yahoo.com> Received: from [151.203.103.112] by web14104.mail.yahoo.com via HTTP; Fri, 28 Feb 2003 16:05:39 PST Date: Fri, 28 Feb 2003 16:05:39 -0800 (PST) From: PamSri Subject: Re: Regarding BGP Router ID To: Jeffrey Haas Cc: idr@merit.edu In-Reply-To: <20030228144328.K16411@nexthop.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1838290710-1046477139=:17002" Sender: owner-idr@merit.edu Precedence: bulk --0-1838290710-1046477139=:17002 Content-Type: text/plain; charset=us-ascii The nexthop for the VPNIPv4 prefixes will be exposed in terms of Router ID. Following is the example: EBGP IBGP x <------------------------------> y <--------------------------------------> z y is attached to VRF red & green. y has the loop back address of Y and z Z respectively. The IBGP peering is between Y & Z. For the VRFs y is attached to, all the prefixes get advertised to Z with nexthop of Y. Now the point that i am raising is in the OPEN messages to x and Z, y sends Y which turns out to be the next hop for the VPNIPv4 prefixes. Hence i said that there is a potential for security issues in the case of VPNs where we want the prefixes as well as the nexthops protected. sri Jeffrey Haas wrote:On Fri, Feb 28, 2003 at 11:41:43AM -0800, PamSri wrote: > gets shared. It can cause potential security issues > in VPN scenarios. Could you clarify? > sri -- Jeff Haas NextHop Technologies --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more --0-1838290710-1046477139=:17002 Content-Type: text/html; charset=us-ascii

The nexthop for the VPNIPv4 prefixes will be exposed in terms of Router ID. Following is the example:

                EBGP                               IBGP

x <------------------------------> y <--------------------------------------> z

y is attached to VRF red & green. y has the loop back address of Y and z Z respectively.

The IBGP peering is between Y & Z. For the VRFs y is attached to, all the prefixes get advertised to Z with nexthop of Y. Now the point that i am raising is in the OPEN messages to x and Z, y sends Y which turns out to be the next hop for the VPNIPv4 prefixes. Hence i said that there is a potential for security issues in the case of VPNs where we want the prefixes as well as the nexthops protected.

sri

 Jeffrey Haas <jhaas@nexthop.com> wrote:

On Fri, Feb 28, 2003 at 11:41:43AM -0800, PamSri wrote:
> gets shared. It can cause potential security issues
> in VPN scenarios.

Could you clarify?

> sri

--
Jeff Haas
NextHop Technologies


Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, and more --0-1838290710-1046477139=:17002-- 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 OAA25725 for ; Fri, 28 Feb 2003 14:44:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EE3FB912AF; Fri, 28 Feb 2003 14:43:37 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BDC48912B0; Fri, 28 Feb 2003 14:43: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 ADD91912AF for ; Fri, 28 Feb 2003 14:43:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9C08E5DE9C; Fri, 28 Feb 2003 14:43:35 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 096C55DE98 for ; Fri, 28 Feb 2003 14:43:35 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.11.3/8.11.1) id h1SJhWk65704; Fri, 28 Feb 2003 14:43:32 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.11.3/8.11.1) with ESMTP id h1SJhT165697; Fri, 28 Feb 2003 14:43:29 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h1SJhT920239; Fri, 28 Feb 2003 14:43:29 -0500 (EST) Date: Fri, 28 Feb 2003 14:43:28 -0500 From: Jeffrey Haas To: PamSri Cc: idr@merit.edu Subject: Re: Regarding BGP Router ID Message-ID: <20030228144328.K16411@nexthop.com> References: <20030228143020.J16411@nexthop.com> <20030228194143.10132.qmail@web14101.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030228194143.10132.qmail@web14101.mail.yahoo.com>; from pamsri01@yahoo.com on Fri, Feb 28, 2003 at 11:41:43AM -0800 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Fri, Feb 28, 2003 at 11:41:43AM -0800, PamSri wrote: > gets shared. It can cause potential security issues > in VPN scenarios. Could you clarify? > sri -- 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 OAA25715 for ; Fri, 28 Feb 2003 14:42:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5BC31912AE; Fri, 28 Feb 2003 14:41:46 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F4F3912AF; Fri, 28 Feb 2003 14:41: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 CE8AE912AE for ; Fri, 28 Feb 2003 14:41:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id B38D15DE9C; Fri, 28 Feb 2003 14:41:44 -0500 (EST) Delivered-To: idr@merit.edu Received: from web14101.mail.yahoo.com (web14101.mail.yahoo.com [216.136.172.131]) by segue.merit.edu (Postfix) with SMTP id D75805DE92 for ; Fri, 28 Feb 2003 14:41:43 -0500 (EST) Message-ID: <20030228194143.10132.qmail@web14101.mail.yahoo.com> Received: from [47.234.0.51] by web14101.mail.yahoo.com via HTTP; Fri, 28 Feb 2003 11:41:43 PST Date: Fri, 28 Feb 2003 11:41:43 -0800 (PST) From: PamSri Subject: Re: Regarding BGP Router ID To: idr@merit.edu In-Reply-To: <20030228143020.J16411@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Not sure if you have covered all the scenarios but mindful of the fact that this entity is something that gets shared. It can cause potential security issues in VPN scenarios. Maybe your observation over simplifies this case. sri --- Jeffrey Haas wrote: > On Fri, Feb 28, 2003 at 11:20:36AM -0800, PamSri > wrote: > > Can you give me a reason why the configured IP of > the > > Router ID needs to be reachable ? So for example > if i > > were to configure x.x.x.x for my router ID (which > is a > > loopback address) why does someone need to be able > to > > ping it in order for my peering session to be UP ? > > To attempt to summarize way too much list archives, > it *doesn't*. > The BGP Identifier is just a number. > > However, for purposes of operations, it is very > handy to have the > number in your internal network for troubleshooting. > Outside of > your network (in the aggregator field), its handy to > have it to figure > out what box may have done a bit of aggregation. > But even then, > all you really need is a number along with the AS to > pass that back > to the aggregating network for troubleshooting > purposes. > > Its also notable that loopback addresses are often > reachable within > a given AS, but access is administratively denied > outside or > perhaps even denied from anything other than the > management network. > > > sri > > -- > Jeff Haas > NextHop Technologies __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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 OAA25692 for ; Fri, 28 Feb 2003 14:39:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5B5DC91243; Fri, 28 Feb 2003 14:38:53 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 290BB912AE; Fri, 28 Feb 2003 14:38: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 16E5991243 for ; Fri, 28 Feb 2003 14:38:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id F00225DE92; Fri, 28 Feb 2003 14:38:51 -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 C96025DE7D for ; Fri, 28 Feb 2003 14:38:51 -0500 (EST) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 2DCA442C744; Fri, 28 Feb 2003 11:38:51 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id D5E6215D3C1; Fri, 28 Feb 2003 11:38:50 -0800 (PST) To: PamSri Cc: idr@merit.edu, enke@redback.com Subject: Re: Regarding BGP Router ID In-Reply-To: Message from PamSri of "Fri, 28 Feb 2003 10:59:56 PST." <20030228185956.64632.qmail@web14108.mail.yahoo.com> Date: Fri, 28 Feb 2003 11:38:50 -0800 From: Enke Chen Message-Id: <20030228193850.D5E6215D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Sri: Please read the document that clarifies and relaxes the requirements for BGP Identifier. -- Enke > Message-ID: <20030228185956.64632.qmail@web14108.mail.yahoo.com> > Received: from [47.234.0.51] by web14108.mail.yahoo.com via HTTP; Fri, 28 Feb 2003 10:59:56 PST > Date: Fri, 28 Feb 2003 10:59:56 -0800 (PST) > From: PamSri > Subject: Regarding BGP Router ID > To: idr@merit.edu > > Hi , > The latest base draft of BGP talks about BGP > identifier as follows: > > "If the BGP Identifier field of the OPEN message is > syntactically incorrect, then the Error Subcode is set > to Bad BGP Identifier. Syn-tactic correctness means > that the BGP Identifier field represents a valid IP > host address." > > Does this mean that BGP Identifier has be a routable > address ? > > sri > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.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 OAA25611 for ; Fri, 28 Feb 2003 14:31:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 14C4A912AD; Fri, 28 Feb 2003 14:30:30 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D45F1912AE; Fri, 28 Feb 2003 14:30:29 -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 A8842912AD for ; Fri, 28 Feb 2003 14:30:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 11F0D5DE93; Fri, 28 Feb 2003 14:30:26 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 9F8645DE69 for ; Fri, 28 Feb 2003 14:30:25 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.11.3/8.11.1) id h1SJUOW65280; Fri, 28 Feb 2003 14:30:24 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.11.3/8.11.1) with ESMTP id h1SJUK165273; Fri, 28 Feb 2003 14:30:20 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h1SJUKg19996; Fri, 28 Feb 2003 14:30:20 -0500 (EST) Date: Fri, 28 Feb 2003 14:30:20 -0500 From: Jeffrey Haas To: PamSri Cc: idr@merit.edu Subject: Re: Regarding BGP Router ID Message-ID: <20030228143020.J16411@nexthop.com> References: <20030228140644.I16411@nexthop.com> <20030228192036.68699.qmail@web14108.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030228192036.68699.qmail@web14108.mail.yahoo.com>; from pamsri01@yahoo.com on Fri, Feb 28, 2003 at 11:20:36AM -0800 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Fri, Feb 28, 2003 at 11:20:36AM -0800, PamSri wrote: > Can you give me a reason why the configured IP of the > Router ID needs to be reachable ? So for example if i > were to configure x.x.x.x for my router ID (which is a > loopback address) why does someone need to be able to > ping it in order for my peering session to be UP ? To attempt to summarize way too much list archives, it *doesn't*. The BGP Identifier is just a number. However, for purposes of operations, it is very handy to have the number in your internal network for troubleshooting. Outside of your network (in the aggregator field), its handy to have it to figure out what box may have done a bit of aggregation. But even then, all you really need is a number along with the AS to pass that back to the aggregating network for troubleshooting purposes. Its also notable that loopback addresses are often reachable within a given AS, but access is administratively denied outside or perhaps even denied from anything other than the management network. > sri -- 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 OAA25558 for ; Fri, 28 Feb 2003 14:21:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3FDD5912AB; Fri, 28 Feb 2003 14:20:39 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D5A7912AC; Fri, 28 Feb 2003 14:20:38 -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 AE972912AB for ; Fri, 28 Feb 2003 14:20:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8B63E5DE8E; Fri, 28 Feb 2003 14:20:37 -0500 (EST) Delivered-To: idr@merit.edu Received: from web14108.mail.yahoo.com (web14108.mail.yahoo.com [216.136.172.138]) by segue.merit.edu (Postfix) with SMTP id BBD1B5DE83 for ; Fri, 28 Feb 2003 14:20:36 -0500 (EST) Message-ID: <20030228192036.68699.qmail@web14108.mail.yahoo.com> Received: from [47.234.0.51] by web14108.mail.yahoo.com via HTTP; Fri, 28 Feb 2003 11:20:36 PST Date: Fri, 28 Feb 2003 11:20:36 -0800 (PST) From: PamSri Subject: Re: Regarding BGP Router ID To: Jeffrey Haas Cc: idr@merit.edu In-Reply-To: <20030228140644.I16411@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Can you give me a reason why the configured IP of the Router ID needs to be reachable ? So for example if i were to configure x.x.x.x for my router ID (which is a loopback address) why does someone need to be able to ping it in order for my peering session to be UP ? sri --- Jeffrey Haas wrote: > On Fri, Feb 28, 2003 at 11:03:38AM -0800, PamSri > wrote: > > Actually by routable i mean reachable address. > > Best current practice would say "yes" with this > typically being > the host's "loopback" address. > > However, as noted in the archives and in the v6-only > router-id > ID for BGP, its just a number. However, its one > that may cause > interoperability problems if one party treats it as > a number and > the other insists on syntactic correctness. > > > sri > > -- > Jeff Haas > NextHop Technologies __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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 OAA25424 for ; Fri, 28 Feb 2003 14:07:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8D538912A9; Fri, 28 Feb 2003 14:06:51 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CD18912AB; Fri, 28 Feb 2003 14:06: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 40BCD912A9 for ; Fri, 28 Feb 2003 14:06:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 304255DE91; Fri, 28 Feb 2003 14:06:50 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 936165DE90 for ; Fri, 28 Feb 2003 14:06:49 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.11.3/8.11.1) id h1SJ6lJ64581; Fri, 28 Feb 2003 14:06:47 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.11.3/8.11.1) with ESMTP id h1SJ6i164574; Fri, 28 Feb 2003 14:06:44 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h1SJ6ii19494; Fri, 28 Feb 2003 14:06:44 -0500 (EST) Date: Fri, 28 Feb 2003 14:06:44 -0500 From: Jeffrey Haas To: PamSri Cc: idr@merit.edu Subject: Re: Regarding BGP Router ID Message-ID: <20030228140644.I16411@nexthop.com> References: <20030228185956.64632.qmail@web14108.mail.yahoo.com> <20030228190338.3349.qmail@web14102.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030228190338.3349.qmail@web14102.mail.yahoo.com>; from pamsri01@yahoo.com on Fri, Feb 28, 2003 at 11:03:38AM -0800 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Fri, Feb 28, 2003 at 11:03:38AM -0800, PamSri wrote: > Actually by routable i mean reachable address. Best current practice would say "yes" with this typically being the host's "loopback" address. However, as noted in the archives and in the v6-only router-id ID for BGP, its just a number. However, its one that may cause interoperability problems if one party treats it as a number and the other insists on syntactic correctness. > sri -- 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 OAA25404 for ; Fri, 28 Feb 2003 14:04:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2EDEE912A8; Fri, 28 Feb 2003 14:04:14 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51272912A9; Fri, 28 Feb 2003 14:04: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 4F0DD912A8 for ; Fri, 28 Feb 2003 14:03:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2A8AE5DE7D; Fri, 28 Feb 2003 14:03:40 -0500 (EST) Delivered-To: idr@merit.edu Received: from web14102.mail.yahoo.com (web14102.mail.yahoo.com [216.136.172.132]) by segue.merit.edu (Postfix) with SMTP id 5DD8B5DE1C for ; Fri, 28 Feb 2003 14:03:39 -0500 (EST) Message-ID: <20030228190338.3349.qmail@web14102.mail.yahoo.com> Received: from [47.234.0.51] by web14102.mail.yahoo.com via HTTP; Fri, 28 Feb 2003 11:03:38 PST Date: Fri, 28 Feb 2003 11:03:38 -0800 (PST) From: PamSri Subject: Re: Regarding BGP Router ID To: idr@merit.edu In-Reply-To: <20030228185956.64632.qmail@web14108.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Actually by routable i mean reachable address. sri --- PamSri wrote: > Hi , > The latest base draft of BGP talks about BGP > identifier as follows: > > "If the BGP Identifier field of the OPEN message is > syntactically incorrect, then the Error Subcode is > set > to Bad BGP Identifier. Syn-tactic correctness means > that the BGP Identifier field represents a valid IP > host address." > > Does this mean that BGP Identifier has be a routable > address ? > > sri > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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 OAA25327 for ; Fri, 28 Feb 2003 14:00:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9080E912A7; Fri, 28 Feb 2003 13:59:59 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 57E6E912A8; Fri, 28 Feb 2003 13:59: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 00F09912A7 for ; Fri, 28 Feb 2003 13:59:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id DC9225DE8F; Fri, 28 Feb 2003 13:59:57 -0500 (EST) Delivered-To: idr@merit.edu Received: from web14108.mail.yahoo.com (web14108.mail.yahoo.com [216.136.172.138]) by segue.merit.edu (Postfix) with SMTP id 67DA75DE8E for ; Fri, 28 Feb 2003 13:59:57 -0500 (EST) Message-ID: <20030228185956.64632.qmail@web14108.mail.yahoo.com> Received: from [47.234.0.51] by web14108.mail.yahoo.com via HTTP; Fri, 28 Feb 2003 10:59:56 PST Date: Fri, 28 Feb 2003 10:59:56 -0800 (PST) From: PamSri Subject: Regarding BGP Router ID To: idr@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Hi , The latest base draft of BGP talks about BGP identifier as follows: "If the BGP Identifier field of the OPEN message is syntactically incorrect, then the Error Subcode is set to Bad BGP Identifier. Syn-tactic correctness means that the BGP Identifier field represents a valid IP host address." Does this mean that BGP Identifier has be a routable address ? sri __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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 QAA04570 for ; Wed, 26 Feb 2003 16:53:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E38EB9125C; Wed, 26 Feb 2003 16:52:46 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB1FF9125D; Wed, 26 Feb 2003 16:52: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 47CE69125C for ; Wed, 26 Feb 2003 16:52:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2D6C65DEEF; Wed, 26 Feb 2003 16:52:45 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 1EEBB5DEE1 for ; Wed, 26 Feb 2003 16:52:42 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.11.3/8.11.1) id h1QLqfp01880 for idr@merit.edu; Wed, 26 Feb 2003 16:52:41 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.nexthop.com (8.11.3/8.11.1) with ESMTP id h1QLqD101789 for ; Wed, 26 Feb 2003 16:52:13 -0500 (EST) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Next-Hop in IPv6 only environment X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 26 Feb 2003 16:52:13 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Next-Hop in IPv6 only environment Thread-Index: AcLc8MMeIwIZanxmTjmEnf3z8LcP9QA8Hizg From: "Susan Hares" To: "Alex Zinin" , "Curtis Villamizar" Cc: "Yakov Rekhter" , , "Manav Bhatia" , "Enke Chen" , "Jeffrey Haas" , , X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id QAA04570 Alex: Thanks for the note. Sue -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Tuesday, February 25, 2003 12:10 PM To: Curtis Villamizar Cc: Yakov Rekhter; Susan Hares; andrewl@xix-w.bengi.exodus.net; Manav Bhatia; Enke Chen; Jeffrey Haas; mjh@icir.org; idr@merit.edu Subject: Re: Next-Hop in IPv6 only environment While something like this definitely wouldn't harm the spec, I don't think it is really required--a situation where the base spec is more recent than the extensions is absolutely normal and happens quite often. A higher number of the base RFC does not mean it obsoletes the extension spec, whatever RFC number that is. Example: OSPFv2 spec: RFC2328; the demand circuit extension to it suppressing Hello's on a link: RFC1793... and no disclaimers that extensions may modify the described behavior, and no confusion :) Then again, it's a minor question. If you guys believe it's a good idea to have something like this in the text--sure. -- Alex Tuesday, February 25, 2003, 8:54:02 AM, Curtis Villamizar wrote: > In message <200302251607.h1PG7WS85809@merlot.juniper.net>, Yakov Rekhter writes > : >> > >> > My understanding from the ADs is that >> > we are completing the Base specification >> > first without any additions. >> > >> > After we have completed the 1st version of >> > the base specification, I believe the ADs >> > will re-open the charter to these additions. >> > It is my understanding that we will deal >> > with IPv6 issues after this point. >> > >> > Yakov, Bill and Alex - am I correct? >> >> I think that adding the text suggested by Andrew would be fine. >> >> Yakov. > A worthwhile clarification since it keeps coming up on the list. I > agree that it is worth adding Andrew's text either to the front or as > an additional "Protocol Extensions" appendix at the very end. > Curtis >> > If there is confusion on this issue, I would suggest we add a statement >> > like this: >> > >> > This document specifies the base behavior of the BGP protocol. This >> > behavior can and is modified by extention specifications. When the >> > protocol is extended the new behavior is fully documented in the >> > extention specifications. >> > >> > to the beginning of the document somewhere. >> > >> > Andrew 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 QAA04487 for ; Wed, 26 Feb 2003 16:50:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B33A59125A; Wed, 26 Feb 2003 16:49:52 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 82EA19125C; Wed, 26 Feb 2003 16:49:52 -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 31DC79125A for ; Wed, 26 Feb 2003 16:49:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 174615DE50; Wed, 26 Feb 2003 16:49:51 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 792CE5DD95 for ; Wed, 26 Feb 2003 16:49:50 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.11.3/8.11.1) id h1QLoLo01359 for idr@merit.edu; Wed, 26 Feb 2003 16:50:21 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.nexthop.com (8.11.3/8.11.1) with ESMTP id h1QLoA101332 for ; Wed, 26 Feb 2003 16:50:10 -0500 (EST) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: BGP Base Draft - Issue List v2.3 (Draft-19) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 26 Feb 2003 16:49:39 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BGP Base Draft - Issue List v2.3 (Draft-19) Thread-Index: AcLd1/HO7D/GsXF/QcaAtlwzlbdBkQACO0RQ From: "Susan Hares" To: Cc: X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id QAA04487 Andrew: Thanks for the latest version of the list. sue -----Original Message----- From: andrewl@xix-w.bengi.exodus.net [mailto:andrewl@xix-w.bengi.exodus.net] Sent: Wednesday, February 26, 2003 3:42 PM To: idr@merit.edu Cc: andrewl@xix-w.bengi.exodus.net Subject: BGP Base Draft - Issue List v2.3 (Draft-19) Greetings, Attached is v2.3 of the issues list, and the associated changelog. As of this moment, all of the issues are at consensus. However, I do know that there are some concerns still extant, and that may result in either issues being reopened, or new issues being added. Andrew 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 PAA02369 for ; Wed, 26 Feb 2003 15:45:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D2E2991216; Wed, 26 Feb 2003 15:44:39 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7008E91231; Wed, 26 Feb 2003 15:44: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 09BDF91216 for ; Wed, 26 Feb 2003 15:44:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id CD1705DE91; Wed, 26 Feb 2003 15:44:31 -0500 (EST) Delivered-To: idr@merit.edu Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id A2BE55DDC8 for ; Wed, 26 Feb 2003 15:44:29 -0500 (EST) Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id MAA28591; Wed, 26 Feb 2003 12:41:32 -0800 (PST) Date: Wed, 26 Feb 2003 12:41:32 -0800 From: andrewl@xix-w.bengi.exodus.net To: idr@merit.edu Cc: andrewl@xix-w.bengi.exodus.net Subject: BGP Base Draft - Issue List v2.3 (Draft-19) Message-ID: <20030226124132.N5760@demiurge.exodus.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Izn7cH1Com+I3R9J" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-idr@merit.edu Precedence: bulk --Izn7cH1Com+I3R9J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Greetings, Attached is v2.3 of the issues list, and the associated changelog. As of this moment, all of the issues are at consensus. However, I do know that there are some concerns still extant, and that may result in either issues being reopened, or new issues being added. Andrew --Izn7cH1Com+I3R9J Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="Issue_List-v2.3.txt" 2003-02-26 v2.3 This is version 2.3 of this list. All the 2.x versions pertain to draft-ietf-idr-bgp4-18.txt. The revisions discussed here are targeted to be incorporated into the -19 version of this document. Since late August 2002, there has been a push to get any and all issues with the base spec. resolved so the IDR group can move this draft forward to the IESG. This is a list of the issues that have been brought up regarding the base draft, and the current working group consensus on them. All mistakes are mine, please email me at andrewl@cw.net with corrections. Please include the number and the title of the issue in the subject lines of email discussing that issue. It will help in keeping track. N.B. There is no rhyme or reason to the numbering scheme other than unique tags to address the issues. ============================================================================ Table of Contents ============================================================================ 1) Reference to RFC 1772 2) MUST/SHOULD Capitalization 3) Fix Update Error Subcode 7 -- accidently removed. 4) Section 5.1.4 - Editoral Comment 5) Section 9.1 - Change "all peers" to "peers" 6) AS Loop Detection & Implicit Withdraws 7) Standardize FSM Timer Descriptions 8) FSM MIB enumerations 9) Make "delete routes" language consistant 10) Correct OpenSent and OpenConfirm delete wording 11) Incorrect next state when the delay open timer expires. 12) Entering OpenConfirm / Adding "Stop OpenDelay" action 13) FSM Missing Next States 13.1) FSM Missing Next States - Event 15 or 16 (Connect State) 13.2) FSM Missing Next States - Event 14 (Connect State) 13.3) FSM Missing Next States - Event 15 or 16 (Active State) 13.4) FSM Missing Next States - Event 13-17 (TCP Connection) 13.5) FSM Missing Next States - Event 17 (Connect State) 13.6) FSM Missing Next States - Event 18 (Open Confirm) 14) FSM - Peer Oscillation Damping 15) FSM - Consistant FSM Event Names 16) Many Editorial Comments 17) Section 3, Page 8, Paragraph 3 - Obsolete? 18) MED Removal Text 19) Security Considerations 20) Peer Oscillation Damping 21) Session Attributes - IdleHold Timer 22) Specify New Attributes (Accept Connections/Peer Oscillation Damping) 23) Event1/Event2 Clean Up 24) Events 3, 5, 6 & 7 Give Examples 25) Event 4 & 5 Session Initiation Text 26) Event 4 & 5 - bgp_stop_flap option 27) Event 5 Clarification 28) Timer Events Definition - Make Consistant 29) Event 8 - Clean Up 30) Hold Timer - Split? 31) OpenDelay Timer Definition 32) Definition of TCP Connection Accept (Event 13) 33) Event 13 & 14 - Valid Addresses & Ports 34) Event 17 - TCP Connection Fails to TCP Connection Termination 35) Making Definition Style Consistant 36) Event 19 - Definition Cleanup 37) Event 22 - Cleanup 38) FSM Description - ConnectRetry Count 39) Handling Event 7 (Auto Stop) to Idle State processing 40) Clearing the Connection Retry Timer 41) Handling of Event 14 in the Connect State 42) Handling events 20, 21 in the Connect State and Active State 43) Handling the default events in the Connect state 44) Handling Event 23 in Connect and OpenSent 45) Event 17 in the Connect state 46) Handling of Event 17 in Active state 47) Handling of Event 19 in Active state 48) Handling of Event 2 in Active state 49) Default Event handling in Active state 50) Clearing Hold timer in OpenSent, OpenConfirm and Established State 51) Clearing Keepalive timer in OpenConfirm and Established State 52) Handling Event 18 in the OpenSent state (Keepalive Timer) 53) Established State MIB 54) State impact of not supporting Optional Events 55) New DelayOpen State 56) Clarify what is covered in the base document. ============================================================================ Issues with Consensus ============================================================================ 1) Reference to RFC 1772 2) MUST/SHOULD Capitalization 3) Fix Update Error Subcode 7 -- accidently removed. 4) Section 5.1.4 - Editoral Comment 5) Section 9.1 - Change "all peers" to "peers" 6) AS Loop Detection & Implicit Withdraws 7) Standardize FSM Timer Descriptions 8) FSM MIB enumerations 9) Make "delete routes" language consistant 10) Correct OpenSent and OpenConfirm delete wording 11) Incorrect next state when the delay open timer expires. 12) Entering OpenConfirm / Adding "Stop OpenDelay" action 13) FSM Missing Next States 13.1) FSM Missing Next States - Event 15 or 16 (Connect State) 13.2) FSM Missing Next States - Event 14 (Connect State) 13.3) FSM Missing Next States - Event 15 or 16 (Active State) 13.4) FSM Missing Next States - Event 13-17 (TCP Connection) 13.5) FSM Missing Next States - Event 17 (Connect State) 13.6) FSM Missing Next States - Event 18 (Open Confirm) 14) FSM - Peer Oscillation Damping 15) FSM - Consistent FSM Event Names 16) Many Editorial Comments 17) Section 3, Page 8, Paragraph 3 - Obsolete? 18) MED Removal Text 19) Security Considerations 20) Peer Oscillation Damping 21) Session Attributes - IdleHold Timer 22) Specify New Attributes (Accept Connections/Peer Oscillation Damping) 23) Event1/Event2 Clean Up 24) Events 3, 5, 6 & 7 Give Examples 25) Event 4 & 5 Session Initiation Text 26) Event 4 & 5 - bgp_stop_flap option 27) Event 5 Clarification 28) Timer Events Definition - Make Consistant 29) Event 8 - Clean Up 30) Hold Timer - Split? 31) OpenDelay Timer Definition 32) Definition of TCP Connection Accept (Event 13) 33) Event 13 & 14 - Valid Addresses & Ports 34) Event 17 - TCP Connection Fails to TCP Connection Termination 35) Making Definition Style Consistant 36) Event 19 - Definition Cleanup 37) Event 22 - Cleanup 38) FSM Description - ConnectRetry Count 39) Handling Event 7 (Auto Stop) to Idle State processing 40) Clearing the Connection Retry Timer 41) Handling of Event 14 in the Connect State 42) Handling events 20, 21 in the Connect State and Active State 43) Handling the default events in the Connect state 44) Handling Event 23 in Connect and OpenSent 45) Event 17 in the Connect state 46) Handling of Event 17 in Active state 47) Handling of Event 19 in Active state 48) Handling of Event 2 in Active state 49) Default Event handling in Active state 50) Clearing Hold timer in OpenSent, OpenConfirm and Established State 51) Clearing Keepalive timer in OpenConfirm and Established State 52) Handling Event 18 in the OpenSent state (Keepalive Timer) 53) Established State MIB 54) State impact of not supporting Optional Events 55) New DelayOpen State 56) Clarify what is covered in the base document. ============================================================================ Issues WITHOUT Consensus ============================================================================ ** NONE ** ---------------------------------------------------------------------------- 1) Reference to RFC 1772 ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: Proposed changing RFC 1772 reference, since that document should be updated. Discussion: Jeff proposed that we reconsider referencing RFC 1772, since that document should be updated. Yakov pointed out that this is a non-normative reference and can just be left as is. Jeff agreed that this wasn't a big deal. We are at consensus to leave things as they are. This was discussed in the "-18 last call comments" thread. ---------------------------------------------------------------------------- 2) MUST/SHOULD Capitalization ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Capitalize MUST/SHOULD where appropate. Discussion: Jeff brought this up, and Yakov reponded asking that he point out specific instances where this is needed. Jeff said he would do so, given some time. Yakov later replied that this would be fixed in the -19 version. Jeff replied with a master diff showing the MUST/SHOULDs, for the entire document please see the beginning of the thread entitled: "Issues list, #2: MUST/SHOULD Capitalization" This was discussed in the "18 last call comments" thread. This was also brought up in the "proxy: comments on draft -18" thread. ---------------------------------------------------------------------------- 3) Fix Update Error Subcode 7 -- accidently removed. ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Add error subcode 7 back in, it looks like it was inadvertently removed. Add deprication text to Open Message Error subcode 5. Discussion: Jeff supplied: Update message error subcode 7 is removed. Especially in -18, it looks like an editing mistake based on where it would fall in the editing.. Yakov mentioned that this is addressed in Appendix A. Jeff replied: What I would like to see is something like this: 6 - Invalid ORIGIN Attribute 7 - [Deprecated - See Appendix A] 8 - Invalid NEXT_HOP Attribute As it stands, 7 lies on a page boundary and looks like it got clipped by the roff. Yakov agreed, and also said he would add similar text for Open Message Error subcode 5. This was discussed in the "18 last call comments" thread. ---------------------------------------------------------------------------- 4) Section 5.1.4 - Editoral Comment ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Fix "restricts" to "RESTRICTIONS" Discussion: Jeff proposed an editorial fix. This is agreed to. This was discussed in the "-18 last call comments" thread. ---------------------------------------------------------------------------- 5) Section 9.1 - Change "all peers" to "peers" ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Section 9.1 - Change "all peers" to "peers" Discussion: Jeff proposed: 9.1: The output of the Decision Process is the set of routes that will be advertised to (delete all) peers; the selected routes will be stored in the local speaker's Adj-RIB-Out according to policy. The previous wording implied that routes in the LocRib MUST be placed in the adj-rib-out. Yakov agreed, this fix will be in the next revision. This was discussed in the "-18 last call comments" thread. ---------------------------------------------------------------------------- 6) AS Loop Detection & Implicit Withdraws ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Update the text to reflect the AS Loop detection should be done in the BGP decision process. Discussion: John brought this up, and suggested: I have one further comment just in case it's not perfectly obvious to everyone, which is that "ignore the UPDATE" is not strictly the action you take when receiving a looped update. Rather, you treat it as an implicit withdraw, i.e. you process it as any other update but treat the contained NLRI as unfeasible. I was going to write that this is sufficiently clear from the spec, but I regret to say that it isn't. Here is the fourth paragraph of section 9: The information carried by the AS_PATH attribute is checked for AS loops. AS loop detection is done by scanning the full AS path (as specified in the AS_PATH attribute), and checking that the autonomous system number of the local system does not appear in the AS path. If the autonomous system number appears in the AS path the route may be stored in the Adj-RIB-In, but unless the router is configured to accept routes with its own autonomous system in the AS path, the route shall not be passed to the BGP Decision Process. Operations of a router that is configured to accept routes with its own autonomous system number in the AS path are outside the scope of this document. I don't think this is quite right -- the decision process needs to be run if the looped routes had previously been advertised feasibly on the same session. This could be fixed by hacking the quoted paragraph, but it seems more straightforward to do it by removing the quoted paragraph and making the fix in 9.1.2 Phase 2 instead. This could be done by inserting the following between the third and fourth paragraphs of 9.1.2 Phase 2: If the AS_PATH attribute of a BGP route contains an AS loop, the BGP route should be excluded from the Phase 2 decision function. AS loop detection is done by scanning the full AS path (as specified in the AS_PATH attribute), and checking that the autonomous system number of the local system does not appear in the AS path. Operations of a router that is configured to accept routes with its own autonomous system number in the AS path are outside the scope of this document. Section 9.3, first bullet, also addresses this topic, but I don't think it's sufficient. Yakov agreed that this was a change for the better and will include this in the next revision. We are at consensus on this issue. This is discussed in the "-18 last call comments" thread. ---------------------------------------------------------------------------- 7) Standardize FSM Timer Descriptions ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Standardize the state descriptions on those listed in the discussion section of this issue. Discussion: Tom proposed: I think a standard description would serve us better instead of using the following different ways (which I take all to refer to the same entity): delayBGP open timer BGP delay open timer BGP open delay timer delay open timer BGP delay timer I suggest Open Delay timer (with those capitals) I believe that the corresponding flag is consistently referred to (apart from the capitalisation) as Delay Open flag Yakov agreed with this suggestion, no one else disagreed, we are at consensus. This was discussed in the "BGP18-FSM-terminology" thread. ---------------------------------------------------------------------------- 8) FSM MIB enumerations ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Move MIB references from the base spec into the MIB document. Discussion: Tom pointed out that: The FSM makes several references to putting values into MIB objects and while some of the values are defined, eg FSM error or Hold Timer expired, I can find no definition of the following in any of the BGP documents, MIB or otherwise. connect retry expired TCP disconnect administrative down collision detect closure Call Collision cease collision detected and dump connection Administrative stop I believe an implementation needs to be told these values somewhere and that there should be a reference to that place in bgp18. Jeff replied that to make things easier, the MIB references will be removed from the base spec, and into the MIB document. This was discussed in the "WG Last Call FSM MIB enumeration" thread, and the "bgp18 WG Last Call fsm MIB objects" thread. ---------------------------------------------------------------------------- 9) Make "delete routes" language consistant ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Replace a variety of wording with "deletes all routes associated with this connection,". Discussion: Tom pointed out that we use a variety of language to say how we are going to delete routes in the FSM. He proposed that we instead use: - deletes all routes associated with this connection, This met with agreement, and will be reflected in the next version. This was discussed in the "bgp18 WG Last Call fsm delete action" thread. ---------------------------------------------------------------------------- 10) Correct OpenSent and OpenConfirm delete wording ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Remove delete wording from OpenSent and OpenConfirm states. Discussion: Venu asked why there was delete wording in the OpenSent and OpenConfirm states when a BGP speaker cannot recieve routes in these states. Jeff acknowledged that this was an error. Yakov agreed to fix the next version. This was discussed in the "bgp18 WG Last Call fsm delete action" thread. ---------------------------------------------------------------------------- 11) Incorrect next state when the delay open timer expires. ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Fix the next state. Discussion: Tom pointed out that: I believe that there is an incorrect next state when the delay open timer expires [event 12] in the Active state. The next state should be OpenSent and not OpenConfirm. OpenConfirm is for KeepAlive processing when Open messages have been sent and received. OpenSent is for Open sent and not yet received. The corresponding section in Connect state I believe is correct. Yakov agreed, and will fix this in the next revision. This was discussed in the "bgp18 WG Last CAll fsm incorrect next state" ---------------------------------------------------------------------------- 12) Entering OpenConfirm / Adding "Stop OpenDelay" action ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Add this text: Change 2 - Connect state event 17 (currently defined as going to Active) event 9 (stays in Connect state) new Text: In response to the connect retry timer expires event [Event 9], the local system: - drops the TCP connection, - restarts the connect retry timer, - stops the Open Delay timer and resets the timer to zero, - initiates a TCP connection to the other BGP peer, - continues to listen for a connection that may be initiated by the remote BGP peer, and - stays in Connect state. If the TCP connection fails [Event17], the local system: - restarts the connect retry timer, - stops the Open Delay timer and resets value to zero, - continues to listen for a connection that may be initiated by the remote BGP peer, and - changes its state to Active. Further discussion on Keepalives has been moved to issue 52. Discussion: This discussion began with Tom outlining these two points: When the OpenConfirm state is entered from OpenSent with the receipt of a valid open [Event 18], then a KeepAlive message is sent and the timer is started. When the OpenConfirm state is entered from Active or Connect on receipt of a valid open [Event 19], no message is sent, no timer is started. I believe this inconsistency is an error and should be corrected by adding these two actions in those two places. Sue replied: Just to clarify this comment: Event 19 = valid open with delay timer running Active = 1) awaiting TCP connection, or 2) TCP connection completed and awaiting the TCP connection with delay timer running Case 1: - should not see Event 19 In transition from Active to Open Confirm, the connection must have a TCP connection completed. Case 1 does not have this occurring, so the transition must be avoided. Case 2: - should see Event 19 - Open, Keepalive should be sent. Previous text: (Action H from FSM document) If an Open is received with the BGP Delay Open timer running, [Event 19], the local system: - clears the connect retry timer [cleared to zero), - completes the BGP initialization, - stop and clears the BGP Open Delay timer, - Sends an Open Message, - sets the hold timer to a large value (4 minutes), and - changes its state to an Open Confirm. New text: [a New Action - N-2 : N + BGP keepalive sent] If an Open is received with the BGP Delay Open Timer running [Event 19], the local system: - clear the connect retry timer [cleared to zero], - completes the BGP initialization, - stops and clears the BGP Open Delay timer, - Send an Open message, - Sends a Keepalive message, - If hold timer value is non-zero, - set keepalive timer - hold timer reset to negotiated value else if hold timer is zero, - reset the keepalive timer, and - reset the hold timer. - If the value of the autonomous system field is the same as the local Autonomous system number, set the connection status to a internal connection; otherwise it is "external". Tom and Sue discussed the OpenDelay state, and recalled that this was excluded a number of months ago as not reflecting current practice. By way of clarification, Sue added: 1) Agree, this can occur in the Active state as well as the Connect state. Will you accept the earlier text below to be inserted both places? Background: The state machine for Event 19 is: Idle Connect Active Open Open Estb Sent Confirm =============================================== Event 19 | | | | | | | next state |Idle | Open | Open | Open |Idle | Idle | | | confirm| confirm| Confirm| | | =============================================== action | V | N-2 | N-2 | N | E-1 | E | =============================================== Per the State Machine. Action v - FSM Error Action E - FSM Error, drop connection - etc, drop routes Action E-1 - FSM Error, drop connection (lots of Action N-2 (text below) Action N (text below, without sending Open) 2) Do you think that Event 19 is possible in the Open Sent state? Please answer this separately. Tom replied that: 1) yes I think the same text in both Active and Connect states is a good resolution 2) complicated. As the fsm text stands, Event 19, along with a host of others, takes us back from Open Sent to Idle (I assume on the grounds this is an error condition) which seems very reasonable. But ...in quite a few places, such as Connect state events 2, 7,8,9,10,11, 17, 18, 20 thru 27, we do not stop the OpenDelay timer when going to Idle or Active so we could then go from eg Idle with Manual start [event 1] to Connect to Open Sent all before the OpenDelay timer expires in which case event 19 can occur validly in Open Sent - obscure but possible. (This is also true with Active state and events 2, 17 and the default list at the end). But I think this is an error, and that when exiting Connect state or Active state as listed above, we should have an additional action to stop the OpenDelay timer in which case event 19 in Open Sent becomes an error condition (again). But but but as ever, I cannot speak with authority for implementations and so if implementations do not stop the OpenDelay timer when exiting as above, then Event 19 is valid in Open Sent state - obscure but possible (again). My wish is to add the extra action, stop OpenDelay timer, for the events listed above in Active and Connect states in the expectation that that is what people have or should have implemented. Tom added a reponse to Sue after some other threads have been discussed: You asked if event 19 (Open with OpenDelay timer running) was possible in OpenSent state; I gave a lengthy reply (below) to the effect yes it could because the OpenDelay timer did not always get stopped but the timer should be stopped in which case the event would not happen. Reading your responses to Siva , I see you include stopping the Open Delay timer in the action 'release all BGP resources' when going to Idle (which I missed seeing earlier in the year). That eliminates most but not all of the possibilities I mentioned. I now believe we would need to add the action 'stop OpenDelay timer' for Connect state event 17 (currently defined as going to Active) event 9 (stays in Connect state) in order to stop event 19 in Open Sent Sue replied that, she thought this was at consensus, and provided the new text, which is: Change 1: new text Active state - event 19 If an Open is received with the Open Delay timer is running [Event 19], the local system - clears the connect retry timer (cleared to zero), - stops and clears the Open Delay timer - completes the BGP initialization, - stops and clears the Open Delay timer - sends an OPEN message, - send a Keepalive message, - if the hold timer value is non-zero, - starts the keepalive timer to initial value, - resets the hold timer to the negotiated value, else if the hold timer is zero - resets the keepalive timer (set to zero), - resets the hold timer to zero. - changes its state to OpenConfirm. If the value of the autonomous system field is the same as the local Autonomous System number, set the connection status to an internal connection; otherwise it is "external". Change 2 - Connect state event 17 (currently defined as going to Active) event 9 (stays in Connect state) new Text: In response to the connect retry timer expires event [Event 9], the local system: - drops the TCP connection, - restarts the connect retry timer, - stops the Open Delay timer and resets the timer to zero, - initiates a TCP connection to the other BGP peer, - continues to listen for a connection that may be initiated by the remote BGP peer, and - stays in Connect state. If the TCP connection fails [Event17], the local system: - restarts the connect retry timer, - stops the Open Delay timer and resets value to zero, - continues to listen for a connection that may be initiated by the remote BGP peer, and - changes its state to Active. Tom replied that: Change 2, stop Open Delay timer in Connect state events 9 and 17, fine; that is what I understand to be the real issue 12. Change 1, event 19 in Active state, is IMHO issues 47 and 52. This is tangled because the initial paragraphs of Issue 12 in the issue list are nothing to to with stopping Open Delay timer and everything to to with sending a Keepalive message before entering Open Confirm state from Active or Connect state on event 19; which I raised and see as issue 52. Issue 47 was Siva's issue 28 and relates to a different action for Active state event 19. I agree with change 1 in that it adds in the sending of Keepalive which I believe essential; I think Siva needs to respond concerning issue 47. (nb the stop Open Delay action is duplicated) I wonder if we should use a different character for the bullet points under the if and else clauses to make it clear where they end ie - if the hold timer .... + do this + and this else if ... + do the other + and this But I still have an issue for Connect state event 19 where I believe, as for Active state event 19, we should send a Keepalive and start the Keepalive timer. I will pursue this as part of issue 52 if that suits you. I think the text will be the same as whatever we agree for Active state event 19. This was discussed in the "bgp 18 WG Last Call fsm missing keepalive" thread. And also in the "Event 19 in Open Sent state was Re: bgp18 WG Last Call fsm missing keepalive" thread. This also came up in the "issues 12 - consensus & two changes - 2nd message" thread. ---------------------------------------------------------------------------- 13) FSM Missing Next States ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Seven sub-issues spawned to resolve each of the next-state questions. See each sub-issue for specifics. Discussion: This began with Tom pointing out 7 places where the next state was not clear. Interlaced with his comments below is the proposed text to fix the problems and the status of the issue. All sub-issues are at consensus. This conversation was started in the "bgp18 WG Last Call fsm missing next state" thread. ---------------------------------------------------------------------------- 13.1) FSM Missing Next States - Event 15 or 16 (Connect State) ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Add next state of Connect. Discussion: Tom pointed out that: Connect State: If the TCP connection succeeds [Event 15 or Event 16], the local system checks the "Delay Open Flag". If the delay Open flag is set, the local system: **enters what state Sue proposed these changes: 1) Connect State - Event 15 or Event 16 [consensus, editorial] note: The delay retry timer is utilized instead of the connect retry timer for the next two changes. Previous text: If the TCP connection succeeds [Event 15 or Event 16], local system checks the "Delay Open Flag". If the delay open flag is set, the local system: - clears the connect retry timer, - sets the BGP open delay timer to initial value If the Delay Open flag is not set, the local system: - clears the connect retry timer, - clear BGP Open Delay timer (set to zero), - completes the BGP initialization, - send an Open message to its peer, - sets hold timer to a large value, and - change the state to Open Sent. New text: If the TCP connection succeeds [Event 15 or Event 16], local system checks the Delay Open flag prior to processing: If the Delay Open flag is set, the local system: - clears the connect retry timer, - sets the BGP open delay timer to initial value, and - stays in the Connect state. If the Delay Open flag is not set, the local system: - clears the connect retry timer, - clears the BGP Delay timer (sets to zero), - completes the BGP initialization, - sends an Open message to its peer, - sets the hold timer to a large value, and - changes the state to Open Sent. Tom agreed that this was good, with the change to "Open Delay timer" as discussed in issue 7. This conversation was started in the "bgp18 WG Last Call fsm missing next state" thread. ---------------------------------------------------------------------------- 13.2) FSM Missing Next States - Event 14 (Connect State) ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: We selected option 2 from discussion as the correct text: 2) treat it as an invalid response, reject the connection and see if a valid configured one comes iwthin the connect timer's window. Discussion: Tom pointed out that: Connect State: If the TCP connection receives an indication that is invalid or unconfigured. [Event 14]: **enters what state Sue proposed these alternatives: 2)Connect State - Event 14 [no consensus] Current Text: If the TCP connection receives an indication that that is invalid or unconfigured [Event 14], - the TCP connection is rejected. At the very least this section needs more "word smithing", so I'd like to change it for more clarity at least. I'm not sure this represents the implementations. What I'd like to do is query the implementations to see what they do if they receive a valid TCP connection with an invalid or unconfigured peer. Two options: Alternative 1: Count it as a valid response New Text: If a TCP connection is received that has an invalid format, or an unconfigured host [Event 14], the local system: - rejects the TCP connection, - increments the connect retry counter, - performs bgp peer oscillation checks. If bgp peer oscillation checks allow for a new connection, the bgp peer - restarts the Connect retry timer with configured value, and - enters the Active state. FSM table: Idle Connect Active Open-Sent Open-Confirm Establish Event-14 ======================================================= Next state Idle | Active|Active|Open-Sent|Open-Confirm|Establish| ======================================================= action V | Y2 | L | Ignore | Ignore | Ignore | ======================================================= Alternative 2: Reject the connection and see if valid or configured one appears within the connect timer window. New Text: If a TCP connection is received that has an invalid format, or an unconfigured host [Event 14], the local system: - rejects the TCP connection, - and stays in the Connect state. FSM table: Idle Connect Active Open-Sent Open-Confirm Establish Event-14 ======================================================= Nxt state Idle |Connect|Active|Open-Sent|Open-Confirm|Establish| ======================================================= action V | L | L | Ignore | Ignore | Ignore | ======================================================= Sue then sent out a call to implementors to let the list know what they did with their FSMs. Tom replied that he agreed that we need to wait to see what the existing implementations do. He also suggested: **tp need a then clause here 'if bgp peer oscillation damping does not allow for a new connection, then the local system ???' be added before the FSM table in option 1 of the proposed text. Sue prodded the list saying that: Should the peer: 1) Treat it as a valid response, and enters the active state to watch for a another TCP connection with a valid peer. 2) treat it as an invalid response, reject the connection and see if a valid configured one comes iwthin the connect timer's window. Without further input, I will select option 2. Curtis replied that this was fine with him. There has been no further disagreement, we are at consensus on this. This conversation was started in the "bgp18 WG Last Call fsm missing next state" thread. It was also discussed in the "BGP draft-19 - FSM input needed from developers" thread. ---------------------------------------------------------------------------- 13.3) FSM Missing Next States - Event 15 or 16 (Active State) ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Add text listed in discussion. Discussion: Tom pointed out: Active State: A TCP connection succeeds [Event 15 or Event 16], the local system: process the TCP connection flags - If the BGP delay open flag is set: ** enters what state (I think this is an FSM error in TCP because it has not initiated a connection!) Sue proposed these changes: Previous text: A TCP connection succeeds [Event 15 or Event 16], the local system: process the TCP connection flags - If the BGP delay open flag is set: - clears the connect retry timer [through the following text: - and changes its state to Open Sent. New text: If the TCP connection succeeds [Event 15 or Event 16], local system checks the "Delay Open Flag" prior to processing: If the delay open flag is set, the local system: - clears the connect retry timer, - sets the BGP open delay timer to initial value, and - stays in the Active state. If the Delay Open flag is not set, the local system: - clears the connect retry timer, - clears the BGP Delay timer (sets to zero), - completes the BGP initialization, - sends an Open message to its peer, - sets the hold timer to a large value, and - changes the state to Open Sent. Tom agreeded with this. This conversation was started in the "bgp18 WG Last Call fsm missing next state" thread. ---------------------------------------------------------------------------- 13.4) FSM Missing Next States - Event 13-17 (TCP Connection) ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: We selected: Choice 2: Event 13 and Event 14 be optional, and Events 15 - 17 be mandatory. Discussion: Tom started this by saying that: If the local system receives a valid TCP Indication [Event 13], the local system processes the TCP connection flags. ** enters what state If the local system receives a TCP indication that is invalid for this connection [Event 14]: ** enters what state Sue proposed we move this to the "fsm missing next state - Events 13-17 and the TCP connection" thread. The response in this thread was: 4) Active State, Event 13 [no consensus] 5) Active State, Event 14 [no consensus] The problem with this state is it is difficult to exactly specify without discussing the TCP Messages that FSM document covers. I'll query if the implementors require all of events 13-17 as mandatory. Sue polled the implemtentors on the list with this query: These events are described in section 8.1.3. In our discussion in January through May of 2002, many implementers mapped their implementation onto the following TCP events list in 8.1.3. Events 13 - 17 Event 13 - TCP connection indication & valid remote peer Event 14 - TCP connection indication with invalid source or destination Event 15 - TCP connection request sent (by this peer) received an Acknowledgement [ local system sent a TCP SYN, Received a TCP SYN, ACK pair back, and Sent a TCP ACK] Event 16 - TCP connection confirmed [local system received a TCP SYN, sent a TCP SYN, ACK back, and received a TCP ACK] Event 17 - TCP connections Should we have all of these states? Which implementations support all of these Events? The full FSM text was snipped here for brevity. Sue prodded the list with: Do the implementors require Events 13 - 17 in the State machine ? Event 13 - TCP connection valid indication Event 14 - TCP connection invalid indication Event 15 - TCP connection request acknowedged Event 16 - TCP connection confirmed Event 17 - TCP connection fails Choice 1: Events 13 - 17 are mandatory Choice 2: Event 13 and Event 14 be optional, and Events 15 - 17 be mandatory. If no one objects, we will use Choice 2. Curtis said this was fine with him. There has been no further disagreement, we are at consensus on this. This was started in the "bgp18 WG Last Call fsm missing next state" thread. And continued in the "fsm missing next state - Events 13-17 and the TCP connection" thread. It was also discussed in the "BGP draft-19 - FSM input needed from developers" thread. ---------------------------------------------------------------------------- 13.5) FSM Missing Next States - Event 17 (Connect State) ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: Closed in favor of 13.4 Discussion: If the local system receives a TCP connection failed [Event 17] (timeout or receives connection disconnect), the local system will: ** enters what state Sue replied with this: comment: In the Active state, we may already have a connection and be awaiting the Open Delay timer. The TCP disconnect or timeout could occur in this state due to the "Open Delay Timer". If the TCP Disconnect is ignored, we could have some peer oscillation. If the we wait, then the connection retry timer needs to be kept running. The text below allows this timer. The real question is what is the status of the current implementations. I agree, the Active state and the connect state should match. Old Text: If the TCP connection fails (timeout or disconnection) [Event 17], the local system: - set TCP disconnect in the MIB reason code, - restart Connect retry timer (with initial value), - release all BGP resources, - Acknowledge the Drop of the TCP connection if TCP disconnect (FIN ACK), - Increment ConnectRetryCnt (connect retry count) by 1, and - performs the BGP peer oscillation damping process. Applicable FSM State table: FSM table old: Event 17 current: Idle Connect Active Open-Sent Open-Confirm Establish ========================================================= Next state Idle |Active |Idle |Active | Idle |Idle | | | | | | | ========================================================= action V | Y2 | G | Ignore| Track 2nd | Track 2nd | | | | | connection | connection| ========================================================= Alternative 1: FSM table new: Event 17 current: Idle Connect Active Open-Sent Open-Confirm Establish ========================================================= Next state Idle |Active |Active |Active | Idle |Idle | | | | | | | ========================================================= action V | G | G | Ignore| Track 2nd | Track 2nd | | | | | connection | connection| ========================================================= G: The local system: - restarts the connect retry timer (at intial value), - continues to listen for a connection that may be initiated by the remote peer, and - sets its next state to Active. New Text: (for Connect and Active state) If the TCP connection fails (timeout or disconnect) [Event 17], the local system: - restarts the connect retry timer, - continues to listen for a connection that may be initiated by the remote BGP peer, and - changes it state to Active. Alternative 2: FSM table new: Event 17 current: Idle Connect Active Open-Sent Open-Confirm Establish ========================================================= Next state Idle |Idle |Idle |Active | Idle |Idle | | | | | | | ========================================================= action V | Y2 | Y2 | Ignore| Track 2nd | Track 2nd | | | | | connection | connection| ========================================================= Next Text: If the location system receives a TCP connection failed [Event 17], the local system will: - increment the ConnectRetrycnt (connect retry count) by 1, - release all BGP resources associated with this connection, - perform BGP peer oscillation (if configured), and - go to Idle Y2 - is: The local system: 1) increments the ConnectRetryCnt (connect retry count) by 1, 2) releases all BGP resources associated with this connection, and 3) performs the BGP peer oscillation damping process if the damping process allows for a new connection, the local system - restarts the connect retry timer (with initial value, and - goes to Idle If the damping process does not allow for a new connection, the local system - set the flags to damp the creation of a new bgp connection until a manual start occurs, and - goes to Idle. Tom agreed with the options, and stated that he prefered option 2. Sue is also happy with option 2, if no one else chimes in. After the issues list came out Tom responded to this issue, saying: I think this issue SHOULD be administratively terminated. It relates to Connect state Event 17 (TCP connection fails) and I am credited with raising it; in fact, the issue I raised was missing next state for Active state event 17 and this has now been subsumed into 13.4 (but note that 13.4 does not explicitly say Active state - I know it should because I raised that issue too). I will ensure it does not get lost from any resolution of 13.4. And Connect state event 17 does appear as part of issue 45 which Siva raised so I think that either way, 13.5 can go. This conversation was started in the "bgp18 WG Last Call fsm missing next state" thread. ---------------------------------------------------------------------------- 13.6) FSM Missing Next States - Event 18 (Open Confirm) ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: This is the text: In the Open Confirm state, a valid Open message [Event 22] is received. The BGP Peer connection is check to ee if there is a collision per section 6.8. If this connection is to be dropped due to the call collision, the local system will drop the call by: - sending a NOTIFICATION with a CEASE, - resets the Connect timer (to zero), - releases all BGP resources (this includes stopping the Open Delay Timer and reseting it to zero), - increments the ConnectRetryCnt by 1 (connect retry +count), and - optionally performs a BGP peer oscilation damping processing, and - enters the Idle State. Discussion: Tom opened this with: Open Confirm State: If the Open messages is valid [Event 18], the collision detect function is processed per section 6.8. If this connection is to be dropped due to call collision, the local system: ** enters what state Sue replied with: Here's my proposed text. Please let me know what you think. I think this is an editorial change. Old text: If the open message is valid, the collision detect function is processed per section 6.8. If this connection is to be dropped due to call collision, the local system: - sends a Notification with a Cease - resets the Connect timer (to zero), - releases all BGP resources, - Drop the TCP connection (sends a TCP FIN), - increments the ConnectRetryCnt by 1 (connect retry count), and - performs an BGP peer oscillation damping process. New text: If the open message is valid, the BGP peer connection is check to detect a collision per section 6.8. If this connection is to be dropped due to call collision, the local system: - sends a Notification with a Cease - resets the Connect timer (to zero), - releases all BGP resources, - Drop the TCP connection (sends a TCP FIN), - increments the ConnectRetryCnt by 1 (connect retry count), and - performs an BGP peer oscillation damping processing, and - enters the Idle State. notes: Collision detect impacts Open Sent, Open Confirm, and Established states. Tom replied: I am still struggling with; we are in OpenConfirm so we already have received an Open from the remote peer and Event 18 is a second Open from the same peer. Perhaps my struggle is that I think in terms of two (or more) FSM for a given IP address pair so the Open Collision detection will occur when the/an- other FSM receives a valid Open in states Active/Connect/Open Sent and will generate Event 22 into this FSM so Event 18 cannot occur. But yes, if Event 18 can occur in this FSM and this connection is to be dumped, then Idle state it should be as you suggest. I have slotted in [optionally] in front of the peer oscillation damping in your text because I think it should be optional:-) Sue replied: this mechanism allows a single fsm to handle both. 2 fsm and 1 fsm BGP FSM seem to exist. (I queried implementors a few times on this one. So, I just put in this change to provide the flexibility. Collision detect tends to give scrambled brains for most people.. As Dennis Ferguson said 2 years ago, that's the hardest part of the FSM. Sue then stated that she would query implementors to see what is being done. Sue prodded the list with: In the Open Confirm state, a valid Open message [Event 22] is received. The BGP Peer connection is check to ee if there is a collision per section 6.8. If this connection is to be dropped due to the call collision, the local system will drop the call by: - sending a NOTIFICATION with a CEASE, - resets the Connect timer (to zero), - releases all BGP resources (this includes stopping the Open Delay Timer and reseting it to zero), - increments the ConnectRetryCnt by 1 (connect retry +count), and - optionally performs a BGP peer oscilation damping processing, and - enters the Idle State. Implementors need to verify if this text and the text for Event 22 allows all implementors to perform the necessary Call Collision actions. If no objects, we will use this text. Curtis said he had no problem with this. There has been no disagreement, we are at consensus with this. This conversation was started in the "bgp18 WG Last Call fsm missing next state" thread. It was also discussed in the "BGP draft-19 - FSM input needed from developers" thread. ---------------------------------------------------------------------------- 14) FSM - Peer Oscillation Damping ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Change references to peer oscillation damping to consistant phrase: "[optionally] performs peer oscillation damping". Also remove old reference to "BGP Peer Restart Backoff Mechanisms". Discussion: Tom suggested we use consistant terminology to refer to peer osillation damping. He also pointed out a stale reference. Yakov agreed to fix both of these. ---------------------------------------------------------------------------- 15) FSM - Consistent FSM Event Names ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Make FSM names consistent. Specifics are in the discssion section. Discussion: Tom proposed that: The event name used in the FSM show much variation to the point sometimes where I am not clear that it is always the same event (eg where the event name is qualified by a subset of the possible causes). Assuming that it is, I propose the following changes to make the wording consistent, clear and concise for event names. ** denotes changed text using the convention /'old text'/'new text'/ 8. BGP Finite State machine Event1: Manual start Event2: Manual stop Event3: Automatic start **Event4: Manual start with passive TCP /estabishment/flag/ **Event5: Automatic start with passive TCP /establishment/flag/ Event6: Automatic start with bgp_stop_flap option set **Event7: Auto//matic/ stop Event8: Idle hold timer expires Event9: Connect retry timer expires **Event10: Hold time//r/ expires Event11: Keepalive timer expires Event12: Open Delay timer expires **Event13: TCP connection valid indication **Event14: TCP connection invalid indication **Event15: TCP connection request /sent received an ACK/acknowledged/ Event16: TCP connection confirmed Event17: TCP connection fails Event18: BGPOpen Event19: BGPOpen with *Open Delay timer running Event20: BGPHeaderErr Event21: BGPOpenMsgErr Event22: Open collision dump Event23: NotifMsgVerErr Event24: NotifMsg Event25: KeepAliveMsg Event26: UpdateMsg Event27: UpdateMsgErr 8.2.2 Finite State Machine Connect State: If the BGP port receives a ** valid TCP connection indication [Event 13], If the TCP connection receives **an invalid indication [Event 14]: If the TCP connection fails **/(timeout or disconnect)// [Event17] Active State: If the local system receives a **valid TCP //indication/ [Event 13], If the local system receives a TCP connection failed [Event 17] **/(timeout or receives connection disconnect)//, Open Sent: If a connection in Open Sent is determined to be the connection that must be closed, an **/administrative collision detect/Open collision dump/ [Event 22] is signaled to the state machine. If such an **/administrative collision detect dump [Event 22]/event/ is If a TCP **//connection valid/ indication [Event 13] or TCP **//connection/ request **//acknowledged/ [Event 15] Open Confirm State: ... or receives a TCP **/Disconnect// connection fails/ [Event 17] from the In the event of **/TCP establishment//TCP connection valid indication /[Event 13] .... the local system will **/issue a call/generate an Open/ collision dump [Event 22]. When the local system receives a **/call/open/ collision dump event [Event 22]/such an event/, the Established State: **/disconnect from the underlying TCP/TCP connection fails/ [Event17], it: ... it will process **/a Call/an Open/ Collision dump event[Event 22]. Notes: Event 4 title brought in line with text Event 5 title brought in line with text Event 7 title brought in line with text Event 13 title shortened to be closer to text, text brought in line Event 14 title shortened to be closer to text, text brought in line Event 15 title brought in line with text Event 17 text brought in line with title (text often introduces qualifying conditions that are too restrictive) Event 22 text brought in line with title Sue replied: I will accept the text you proposed for the Event names. I will update the FSM text to include your changes. We'll consider issue 15 in consensus. I've fixed the text. So we are at consensus here. This is discussed in the thread: "bgp18 WG Last Call fsm event names." It was also discussed in the "Issue 15 - Consistent FSM Event Names" thread. ---------------------------------------------------------------------------- 16) Many Editorial Comments ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Many editorial suggestions, and what we are doing with them are listed below. Some issues have been broken out seperately where there is a longer discussion on them. Discussion: Alex began this by presenting comments from an anonymous reviewer, unless otherwise noted, responses are from Yakov: > Almost all of these are simple clarifications. > > Section 1, page 5: IGP definition - it's not clear from this > definition whether IBGP would be considered an IGP? any suggestion on how to improve the definition to clarify this issue would be appreciated. There was some further discussion on this and it was decided that people reading this document ought to know what an IGP is. > Section 3, page 7, para 4: Does RFC 1772 still represent the *planned* > use of BGP? Or the actual use? Or something different from actual > use? Perhaps we should just take out references to 1772. Further discussion seemed to indicate that this reference should stay. > Section 3, page 8, para 3 - "The hosts executing..." This paragraph > seems obsolete. I'll take it out. With regard to this, Siva asked if some route optimizaiton vendors rely on this. Since this wasn't resolved, it is discussed further in issue 17. > Section 4.1, page 11 - Length is in network byte order. all the encodings are in network byte order. This applies not just to the BGP spec, but to other protocols as well. This comment was made about a number of fields. It was later agreed that a reference would be made to this at the beginning of the document. > Section 4.2, page 12 - Hold Time - what does a value of zero indicate? if you read section 4.4 then you'll find that: If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent. > Section 4.2, page 13 - BGP Identifier - network byte order? > "IP address" -> "IPv4 address" I'll put at the beginning a sentence saying that in the context of this document the term "IP address" means an IP Version 4 address. > Section 4.3, Page 14, para1, sentence 2 - "path attribute" -> "path > attributes" fixed. > Section 4.3,Page 17, NEXT_HOP: "IP address" -> "IPv4 address" > Specify that this is 4 octets. > Reference here to multi-protocol extensions for IPv6 nexthop? no. > RFC 2283 is unclear whether NEXT_HOP should always be included > when using multiprotocol extensions. Clarify this here? It is already clarified in 2283bis. > Section 4.3, Page 17/18 - MED and LocalPref: > "non-negative" -> "unsigned" for consistency with elsewhere. > (non-negative might imply values > 2^31 cannot be used). fixed. > Section 4.3, Page 19 - Prefix: "IP address" -> "IPv4 address" > Prefix: "enough trailing bits to" -> "the minimum number of > trailing bits needed to" fixed. > Section 4.4, Page 20: - "BGP does not use any TCP-based keep-alive > mechanism to determine if peers are reachable". Is it worth noting > that TCP may still timeout the connection even if TCP keepalives are > turned off? the text is fine as it is. > Section 4.4, Page 20: > KEEPALIVE message consists" -> "A KEEPALIVE message consists" fixed. > Section 5, Page 23: "The same attribute can not appear more than once > with the Path Attributes field...". Does this mean the same attribute > type, or the same attribute type and value? the former (the same attribute type). > Section 5.1 "The usage of each BGP path attributes .." -> attribute fixed. > Section 5.1.3 "IP address" -> "IPv4 address" > > "A BGP speaker must never advertise an address of a peer to that peer > as a NEXT_HOP, for a route that the speaker is originating." > suggest replace this text with: > "A route originated by a BGP speaker must never be advertised to a > peer using an address of that peer as NEXT_HOP" fixed. > Section 5.1.4: "A BGP speaker MUST IMPLEMENT a mechanism ... which > allows the MULTI_EXIT_DISC to be removed from a route." Might want to > say that this is dangerous unless you received the route from an EBGP > peer? think we should keep the text as is. > Section 5.1.5: "If it [LOCAL_PREF] is contained in an UPDATE message > that is received from an external peer, then this attribute MUST be > ignored by the receiving speaker, except for the case of BGP > Confederations [RF3065]." > - "ignored" might be taken to mean that you don't process it for > decision, but that you propagate it to internal peers. I might > write "silently removed" or something similar. I think the text is ok as is. > Section 5.1.5, para 2. "set of AS" -> "set of ASs" fixed. > Section 6.3: wrt NEXT_HOP semantic correctness: should we check that a > NEXT_HOP is not a multicast or broadcast address? I'll add to the definition of NEXT_HOP that it is a unicast address. > Section 6.3, page 32, para 7: "peer than sent" -> "peer that sent" fixed. > Section 6.3: "if any attribute appears more than once" - does this > mean the same attribute type, or the same attribute type and value? the former. > Section 6.8 "Comparing BGP identifiers is done by treating them as > (4-octet-long) unsigned integers". Need to convert to host byte order > before comparing. fixed. > Section 6.8, item 2: "closes BGP connection" -> "closes the BGP connection" > "accepts BGP connection" -> "accepts the BGP connection". fixed. > Section 9.1.2.2: item (c): in the explanation of neighborAS(n), it is > unclear for IBGP connections how to determine "the neighbor AS from > which the other IBGP speaker learned the route". If this is really > the leftmost entry in the AS path (or the local AS if the path is > empty), the spec should explicitly say so. fixed. > Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC > attribute is removed before..." The first sentence is pretty nearly > incomprehensible. This topic has some more discussion surrounding what text we should use to clarify this issue. This is followed up in issue 18. > Section 9.1.2.2 (d) > "d) If at least one of the candidate routes was received from an > external peer in a neighboring autonomous system, remove from con- > sideration all routes which were received from internal peers." > For consistency with (c) and clarity, this might be reworded: > "d) If any of the candidate routes was learned via EBGP, remove > from consideration all routes which were learned by IBGP." fixed. > Section 9.1.2.2 (e) > "cost (n) is better than cost (m)" > Given the definition of cost, it might be clearer to say > "cost (n) is lower than cost (m)" fixed. > Section 9.1.2.2 (g) > "neighbor address" has not been defined. I'll replace "neighbor address" with "peer address". > Section 9.2.2.2, Page 70 (AGGREGATOR) - "All AGGREGATOR attributes of > all routes to be aggregated should be ignored." > > Perhaps "ignored" is ambiguous here, and it's not clear whether > should is a SHOULD. Suggest: > > "Any AGGREGATOR attributes from the routes to be aggregated MUST > NOT be included in the aggregated route." fixed. > Section 9.3 - shouldn't this subsection be moved to the discussion of > Phase 1 or Phase 2 of the decision process? Or at least move it > before Section 9.2. I think it is fine where it is now. > Appendix E, para 2: IP precedence has been deprecated. Delete this > paragraph, or replace with appropriate diffserv codepoint. deleted. > Security Considerations: > "BGP supports the ability to authenticate BGP messages by using BGP > authentication." > This sentence should be removed, and the Authentication Information > parameter has been deprecated. Please see the recent e-mail exchange on the Security Considerations See issue 19 for more on the Security Considerations section of the draft. These topics were discussed in the "proxy: more comments on the draft -18" thread. ---------------------------------------------------------------------------- 17) Section 3, Page 8, Paragraph 3 - Obsolete? ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Leave the current definition of BGP Speaker, and normalize the text to use "BGP Speaker" instead of router. Discussion: This issue was spawned from the discussions in issue 16, specifically: Anonymous reviwer: > Section 3, page 8, para 3 - "The hosts executing..." This paragraph > seems obsolete. Yakov: I'll take it out. With regard to this, Siva asked if some route optimizaiton vendors rely on this. Jeff replied: To provide context, this paragraph currently reads: : The hosts executing BGP need not be routers. A non-routing host : could exchange routing information with routers via EGP [RFC904] or : even an interior routing protocol. That non-routing host could then : use BGP to exchange routing information with a border router in : another Autonomous System. The implications and applications of this : architecture are for further study. There are several deployed entities that could be considered to "exploit" this paragraph. Route collectors, route servers, bandwidth shapers and other optimizers. However, the original text may be showing its age a little bit. Perhaps the following might be a bit more appropriate: "The hosts executing BGP need not be routers. A non-routing host may exchange routing information with a BGP speaker for reasons that are outside the scope of this document." I would also propose adding to the same paragraph (but could be persuaded to drop it since it is *logically* redundant): "These non-routing hosts should exercise great care not to insert themselves into the forwarding path if they re-announce BGP routes." Yakov replied: Since operations of non-routing host are outside the scope of the document, and since the document doesn't preclude non-routing hosts to run BGP, I would prefer just to take the following paragraph out, and not to add any new text. The hosts executing BGP need not be routers. A non-routing host could exchange routing information with routers via EGP [RFC904] or even an interior routing protocol. That non-routing host could then use BGP to exchange routing information with a border router in another Autonomous System. The implications and applications of this architecture are for further study. Jeff replied that this was ok, and instead suggested: At the beginning of the document, we define: BGP speaker A router that implements BGP. This (potentially) restricts a speaker to being a router. Additionally, several spots in the text where we probably should say "BGP speaker", we use router. Yakov agreed to add this definition. Jeff replied that there still was a problem with this definition being too limiting. The discussion meandered off list for a couple of exchanges and these additional definitions were proposed: First Jeff proposed this: "A router that implements the BGP protocol. Non-routing hosts that also implement BGP are out of scope of this document." Then Andrew replied, that we should make sure the definition does not opt out entirely from making sure that non-routing hosts are interoperable: BGP Speaker A router that implements the BGP protocol. The internal behavior of non-routing hosts that also implement BGP are out of scope of this document. However, in their interactions with routers, non-routing hosts must behave as if they were routers. And Jeff replied: BGP Speaker A router that implements the BGP protocol. The internal behavior of non-routing hosts that also implement BGP are out of scope of this document. However, in their interactions with BGP speaking routers, non-routing hosts that implement BGP should be indistinguishable from a router on the wire. (or something like that - s/on the wire/ with whatever sounds best.) IOW, look like bgp on the wire - what you do internally is out of scope. Yakov replied, that we should keep the current definition, since it is clear that non-routing hosts are outside of the scope. Jeff responded that he is ok with that if we normalize the use of "BGP Speaker" instead of "BGP router" in the document. Yakov agreed to this, we are at consensus on this. This was discussed in the "proxy: more comments on draft -18" thread. And in the "Issues list, #17: Section 3, Page 8, Paragraph 3 - Obsolete?" thread. And also, the "issue 17 - final resolution" thread. ---------------------------------------------------------------------------- 18) MED Removal Text ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Use text at the end of the discussion. Discussion: This issue is spawned from issue 16. An anonymous reviewer pointed out: > Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC > attribute is removed before..." The first sentence is pretty nearly > incomprehensible. Yakov replied: here is my attempt to clarify this: If a MULTI_EXIT_DISC attribute is removed before re-advertising a route into IBGP, then (prior to the removal) the MULTI_EXIT_DISC attribute may only be considered in the comparison of EBGP learned routes; the attribute is then removed, and then the remaining EBGP learned routes may be compared to the remaining IBGP learned routes, without considering the MULTI_EXIT_DISC attribute for those EBGP learned routes whose MULTI_EXIT_DISC attribute will be removed before advertising these routes to IBGP. Any further suggestions on how to improve this would be appreciated. Siva replied: How about this: % If a MULTI_EXIT_DISC attribute is removed before re-advertising a % route into IBGP, then comparison based on the MULT_EXIT_DISC % attribute may (MUST?) be performed only among the EBGP learned routes. % This comparison MUST be performed before the removal of the % MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute must then % be removed from those EBGP routes where such removal is required and % which are still eligible. This is followed by comparison with IBGP % learned routes. I think this reflects our objectives, which is: a) If MED is to be removed, compare EBGP routes based on the MED b) Then remove the MED c) Then do comparison with IBGP routes Andrew suggested: If a router is configured to remove a MUTLI_EXIT_DISC attribute from a route learned from EBGP, before readvertising it into IBGP the router MUST compare the route with other EBGP-learned routes before removing the MULTI_EXIT_DISC. Once this comparison is complete, the MED may be removed, and any remaining routes can be compared with IBGP routes to determine the best route. Yakov replied: Here is the text that will go in the next version of the draft: If a MULTI_EXIT_DISC attribute is removed before re-advertising a route into IBGP, then comparison based on the MULT_EXIT_DISC attribute MAY be performed only among the EBGP learned routes. This comparison MUST be performed before the removal of the MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute is then removed from those EBGP routes where such removal is required and which are still eligible. This is followed by comparison with IBGP learned routes. Matthew responded to this with: I think this new text is ambiguous. >Here is the text that will go in the next version of the draft: > > If a MULTI_EXIT_DISC attribute is removed before re-advertising a > route into IBGP, then comparison based on the MULT_EXIT_DISC > attribute MAY be performed only among the EBGP learned routes. This could be taken to mean either that the comparison may be performed, and if it's performed it must be performed only between EBGP learned routes, or that the comparison must be performed, but it may be performed only between EBGP learned routes. > This comparison MUST be performed before the removal of the > MULTI_EXIT_DISC attribute. If doing the comparison is optional, then I think that this sentence should read "If the comparsion is performed, then it MUST be perfo..." > The MULT_EXIT_DISC attribute is then > removed from those EBGP routes where such removal is required and > which are still eligible. This is followed by comparison with > IBGP learned routes. I think that it is desirable for an operator to be able to turn off MED processing entirely (including turning off all MED based comparisons), so I would suggest the following text: If a MULTI_EXIT_DISC attribute is removed before re-advertising a route into IBGP, comparison based on the received MULTI_EXIT_DISC attribute MAY be performed. If an implementation chooses to perform this comparison, then the comparison MUST be performed only among EBGP learned routes, and it MUST be performed before the removal of the MULTI_EXIT_DISC attribute. Curtis replied to Yakov's message: Looks good to me. I see no need to change "This comparison MUST be performed before the removal of the MULTI_EXIT_DISC attribute". There is no implication that MULTI_EXIT_DISC must be removed and the first sentence clearly indicates that doing so is not required therefore no ambiguity. Adding a "If a MULTI_EXIT_DISC attribute is removed" to the second sentence would be redundant. After some further discussion we have reached full consensus with: If a MULTI_EXIT_DISC attribute is removed before re-advertising a route into IBGP, then comparison based on the received EBGP MULTI_EXIT_DISC attribute MAY still be performed. If an implementation chooses to remove MULTI_EXIT_DISC, then the optional comparison on MULTI_EXIT_DISC if performed at all MUST be performed only among EBGP learned routes. The best EBGP learned route may then be compared with IBGP learned routes after the removal of the MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a subset of EBGP learned routes and the selected "best" EBGP learned route will not have MULTI_EXIT_DISC removed, then the MULTI_EXIT_DISC must be used in the comparison with IBGP learned routes. For IBGP learned routes the MULTI_EXIT_DISC MUST be used in route comparisons which reach this step in the decision process. This is discussed in the "proxy: more comments on draft 18" thread. And in the "issue 18" thread. ---------------------------------------------------------------------------- 19) Security Considerations ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Fix Security Considerations section to include manditory MD5 auth and advance security considerations draft along with the base draft. Discussion: Yakov started this discussion by proposing text which would require TCP MD5 authententication for BGP implementations. This is to bring the spec in line with an IETF requirement that authentication be available. After some discussion the plan is to advance draft-ietf-idr-bgp-vuln-00.txt as Informational along with the base BGP specification. This draft will serve as the security analysis section of the base spec. This is discussed in the "revised Security Considerations section" thread. ---------------------------------------------------------------------------- 20) Peer Oscillation Damping ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: Keep the Peer Oscillation Damping reference in the specification. Discussion: This began when Siva proposed: Since this feature is going to be added in a new draft, and its addition will change the operation of the state machine, can we remove all mention of it in the state machine ? As part of this removal, can we also remove the IdleHold Timer from the FSM since it is not useful in the absence of peer oscillation damping ? The draft that describes this procedure can then describe the change in the state machine required to do this. Sue replied that: The reason we should not remove the peer oscillation damping from the state machine: 1) Deployed implementations support peer oscillation damping 2) Hooks for the additions in the FSM cannot be added later. These hooks are optional and do not need to be implemented. Siva replied: I understand. I am not trying to object to peer oscillation damping, I think it is a good idea and we have included it in our implementation as well. I was suggesting that instead of a partial description in this draft, it be completely described in the draft on peer oscillation damping. However, I do see your point, and unless there are any objections from others, I think we have consensus on this issue. This was discussed in the "Response to FSM input - Comments 1-10" thread: Comment #1. ---------------------------------------------------------------------------- 21) Session Attributes - IdleHold Timer ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Add the text in the discussion section. Discussion: This discussion began with Siva asking: Why have a Hold Timer and a Hold Time ? Can we replace this with just Hold timer ? Can we also add the following session attributes: a) DelayBgpOpenTimer b) IdleHold Timer (in case we choose not to remove this from the bas = FSM) Can we also add the following flag to the session attributes: a) DelayOpen Flag After some discussion we have this text on the table: Event8: Idle hold timer expires Definition: An Event generated when the Idle Hold Timer expires. The Idle Hold Timer is only used when the persistent peer oscillation damping function is enabled. % % Implementations not implemented persistent % peer oscillations damping functions may not % have the Idle Hold Timer. Sue replied: I will accept the new text for the following total text: Event8: Idle hold timer expires Definition: An event generated when the Idle Hold Timer expires indicating that the session has completed a back-off period to prevent bgp peer oscillation. The Idle Hold Timer is only used when the persistent peer oscillation damping function is enabled. Implementations not implementing the presistent peer oscillation damping functions may not have the Idle Hold Timer. Status: Optional We are at consensus with this. Tom added a couple of minor edits, correcting the spelling of "persistent" in the third paragraph, and pointing out that: oscillation damping functions may not have the Idle Hold ** function ** (because we only have function not functions in the previous sentence) Timer. Sue added the edits. Siva also liked the way this issue has turned out. This was discussed in the "Response to FSM input - Comments 1-10" thread: Comment #2. And in the "Draft 19 - issue #21" thread, alternately the "Draft 19 - Issue 21" thread. ---------------------------------------------------------------------------- 22) Specify New Attributes (Accept Connections/Peer Oscillation Damping) ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Add the text in the discussion section to section 8.0. Discussion: This begain with Siva propsosing: Can we call these out as well: * Accept Connections from unconfigured peers (Enabled/Disabled) * Peer Oscillation Dampening (Enabled/Disabled) (In case we choose not to remove it from base spec) After some discussion we have this text on the table: The following will be added to 8.0 Optional parameters that may be supported either per connection or per implementation: 1) Delay Open flag 2) Delay Open Timer 3) Perform automatic start flag 4) Passive TCP establishment flag 5) BGP stop_peer_flag flag 6) Idle Hold timer 7) Perform automatic stop flag 8) Perform Collision detect in Establish mode flag Sue accepted these changes. Tom added this correction for item 2 in Sue's text: 2) Delay Open Timer ** Open Delay timer ** (for which we have consensus in Issue list v2 item 7) Siva asked, and Sue accepted these additional changes: 9) accept connections from un-configured peers 5) BGP stop_peer_flap flag We are at consensus on this. This was discussed in the "Response to FSM input - Comments 1-10" thread: Comment #3. This was also discussed in the "BGP Draft 19 - Close open items 22" thread. ---------------------------------------------------------------------------- 23) Event1/Event2 Clean Up ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Use "Local system administrator" in both sections. Discussion: Siva proposed that we clean up the text for these Events by selecting either "Administrator" or "Local system" but not both. Sue proposed text using "Local system administrator" that was agreed on. This was discussed in the "Response to FSM input - Comments 1-10" thread: Comment #4. ---------------------------------------------------------------------------- 24) Events 3, 5, 6 & 7 Give Examples ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: Leave the examples out. Discussion: This began with Siva proposing we add examples for these event states. Sue believes this is largely out-of-scope, but did agree to move the example of "automatic stop" to the event description section. She asked for proposed text for additional examples. Sue replied that she has made the following changes, and asked if these worked for Siva. New text: Event7: Automatic stop Definition: Local system automatically stops the BGP connection. An example of an automatic stop event is exceeding the number of prefixes for a given peer and the local system automatically disconnecting the peer. Status: Optional depending on local system Siva thought this for Event 7 was fine. Sue replied to the list, saying that, previously examples had caused dissention, and asked if there was a strong feeling either way. Siva proposed this text for Events 3, 5 & 6: Event 3: Examples of this event are: When a connection is terminated during exchange of Open messages due to version failure Event 5: Examples of this event are: Similar to Event 3 Event 6: Examples of this event are: Similar to Event 3 and b) When a Idle Hold timer expires (within local limit) Sue replied to this: I'm going to leave the examples out of events 3, 4, 6 since I've not heard any strong input on the mail list **and** I had strong comments on prior versions of the draft. I'd like to declare that issue 24 has consensus. Siva agreed, we are at consensus on this issue. This was discussed in the "Response to FSM input - Comments 1-10" thread: Comment #5. This was also in the "Issue 25" thread, and the "Issue 25 - this is really issue 24" threads. This is also in the "Draft 19 - Issue 24" thread. ---------------------------------------------------------------------------- 25) Event 4 & 5 Session Initiation Text ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: Leave the text as is. Discussion: This began with Siva wanting to change: Definition: Local system automatically starts the BGP session with the passive flag=20 enabled. The passive flag indicates=20 that the peer will listen prior to=20 establishing a connection. to: The passive flag indicates that the state machine will wait for specified peer to initiate a connection with the local system. If this does not happen within a specific time (hold time), the local system will then also attempt to initiate connection with the specified peer. Sue replied: The text in 8.2.1.1 indicates the definition of the passive flag. 6a) ========== My understanding of your text is that you want to replace in both sets of text: "The passive flag indicates the peer will listen prior to establishing a connection". with: "The passive flag indicates that the state machine will wait for the specified peer to initiate a connection with a local system. The problem with this sentence is that in the "unconfigured" case the phrase "specified" peer is confusing. I think the original text is clearer. 6b) ========== If this does not happen within a specific time (hold time), the local system will then also attempt to initiate (a) connection with the specified peer. My comments: Again, the "specified peer" term is confusing. Also, the 2nd half of the statement mixes the actions of the state machine with the events. I believe this muddies the text instead of clarifying it. Siva and Sue later agreed to leave the text the same because of the Unconfigured + passive TCP connection + Delay Open situation. This was discussed in the "Response to FSM input - Comments 1-10" thread: Comment #6. ---------------------------------------------------------------------------- 26) Event 4 & 5 - bgp_stop_flap option ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Add new event below. Discussion: This began with Siva asking: Won't a variant of this with bgp_stop_flap option set be requried ? We can also achieve the same by using the bgp_stop-Flap option as a flag that is provided as an input to the state machine. Siva later clarified this to include: We already have Event 3 - Automatic Start Event 5 - Automatic start with bgp_stop_flap option set To make things consistent, shouldn't we either a) Add 3 new events : 1) Manual start with bgp_stop flap option set 2) Manual start with passive TCP establishment and bgp_stop_flap option set 3) Automatic start with passive TCP establishment and bgp_stop_flap option set or b) Remove Event 6, and rely on a flag to tell us wether peer flap damping is to be performed for the session or not. Sue said she prefered option A. And stated that #1 & #2 are infeasible, but that we need to add #3. Tom replied: But if we add an event, then we must add and agree on actions for all six existing states so I think to say that adding a new event settle things might be naive. If we do add 3) Automatic start with passive TCP establishment and bgp_stop_flap option set which I understand is Sue's resolution, then for Idle state the actions are straightforward but for the other five, is the event completely ignored? If so, does it mean that the passive flag and the bgp_stop_flap option are ignored and we carry on as if we were when we were started which may have been without them. Or is the fact of starting ignored but the flags remain set and so color the effect of other events? Needs defining. Jeff replied to this, quoting the existing draft: The start events [Event 1, 3-6] are ignored in connect state. The start events [Event1, 3-6] are ignored in the Active state. The Start events [Event1, 3-6] are ignored in the OpenSent state. Any start event [Event1, 3-6] is ignored in the OpenConfirm state. Any start event (Event 1, 3-6) is ignored in the Established state. And elaborated, saying that: "ignore" means do nothing. This means don't twiddle with the flags. :-) The text that was finally agreed on is: Event 7: Automatic start with bgp_stop flap option set and passive TCP establishment option set Definition: Local system automatically starts the BGP peer connection with peer oscillation damping enabled and passive TCP establishment enabled. The exact method of damping persistent peer oscillations is left up to the implementation, and is outside the scope of this document. Status: Optional, used only if the bgp peer has enabled bgp peer oscillation damping with following optional flags settings below. Optional attributes: 1) Perform automatic start flag SHOULD be set 2) BGP stop_peer_flap flag SHOULD be set I've re-ordered the Timer events to keep the text changes down to a minimum. action 9 - connect retry timer action 10 - Hold Timer expires action 11 - Keepalive timer expires action 13 - Open Delay timer expires action 14 - Idle Hold timer expires All other events are incremented by 1 This was discussed in the "Response to FSM input - Comments 1-10" thread: Comment #7. ---------------------------------------------------------------------------- 27) Event 5 Clarification ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: Leave the text as is. Discussion: This began when Siva asked that in event 5: Is it correct that this event will occur only when we want to restart a connection (after it had been terminated due to some reason beside administrative action) that we had accepted from an unconfigured peer ? Sue replied: The automatic start function is an implementation specific mechanism. This text does not seek to restrict it in any fashion. Siva said that although he felt his original clarification would be more useful to new implementors he is ok with the text as is. This was discussed in the "Response to FSM input - Comments 1-10" thread: Comment #8. ---------------------------------------------------------------------------- 28) Timer Events Definition - Make Consistant ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Change text to use "generate" across the board. Discussion: Can we use similar language for Events 8-12 to make them consistant? It was agreed that we will use "generate" i.e.: Event 8: An event generated when the Idle Hold timer expires. Event 9: An event generated when the ConnectRetry timer expires. Event 10: An event generated when the Hold timer expires. Event 11: An event generated when the Keepalive timer expires Event 12: An event generated when the Delay BGP Open timer expires. This is at consensus. This was discussed in the "Response to FSM input - Comments 1-10" thread Comment #9. ---------------------------------------------------------------------------- 29) Event 8 - Clean Up ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Clean up first sentance. New text below. Discussion: Siva began this by asking if we could clean up the wording of Event 8. After some discussion with Sue we are at this change for the first sentance: An event trigerred by the expiry of the Idle Hold timer, indicating that the session has completed waiting for a back-off period to prevent bgp peer oscillation. This was discussed in the "Response to FSM input - Comments 1-10" thread: Comment #10. ---------------------------------------------------------------------------- 30) Hold Timer - Split? ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: Keep the hold timer text as is. Discussion: Siva proposed that since: We use the hold timer for two purposes * Waiting for an open message (with a default value of 240 seconds) * Waiting for Keepalives (with a default value of 90 seconds) Can we use two different timers (or at least call them two different timer events) ? Sue replied that this is not how it is implemented currently. Siva replied that we have two conceptually different timers, but that it would certainly work to only have one, since only one needs to be running at any given time. Tom agreed that we can keep things as is. This was discussed in the "Comments 11-20" thread: Comment #11. ---------------------------------------------------------------------------- 31) OpenDelay Timer Definition ---------------------------------------------------------------------------- Status: Consensus Change: Yes - See issue 28 Summary: This is fixed by the fixing of issue 28. Discussion: This began with Siva's request that we add something to Event 12 to specify what to do when the timer expires. This seems to have been addressed in issue 28. This was discussed in the "Comments 11-20" thread: Comment #12. ---------------------------------------------------------------------------- 32) Definition of TCP Connection Accept (Event 13) ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Change "Definition" text as indicated below. Discussion: Siva proposed that we change text from refering to "TCP connection request" to "receiving a TCP connection". This led to this proposed text: Definition: Event indicating the reception of a TCP connection request with a valid source IP address and TCP port, and valid destination IP address and TCP Port. The definition of invalid source address and port and invalid destination address is left to the implementation. This met with agreement. This thread also discussed the idea of filtering the incomming address/port. It was decided that this was implementation dependant. This was discussed in the "Comments 11-20" thread: Comment #13. ---------------------------------------------------------------------------- 33) Event 13 & 14 - Valid Addresses & Ports ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: See text at the end of the discussion. Discussion: With regard to Event 13 & 14, Siva raised questions about: 1) What does it mean to validate a port, and 2) Should we state what we consider an invalid IP addres to be? Sue replied that this is local policy and is implementation dependant. Siva agreed regarding the source port & IP address, but disagreed about the destination port. He argued that we need to know the destination port for interoperability. Sue asked Siva to provide some text. After a long lull, Sue replied with: I would like to keep the current text of "Should" in the following text "BGP's destination port SHOULD be port 179 as defined by IANA." Should indicates that it normally should be 179. If an implementation allows for an alternative TCP port, it is still valid as the "MUST" is not indicated. There have been no further comments on this, the chairs have decided to close it. This was discussed in the "Comments 11-20" thread: Comment #14. This was also in the "BGP-19: Issue 33" thread. ---------------------------------------------------------------------------- 34) Event 17 - TCP Connection Fails to TCP Connection Termination ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Change the text to "fails." Discussion: This began with Siva observing: This event can occur even when the transport connection is closed by the other end. Since this does not reflect a 'failure ', can we change the event name to % Event17: TCP connection termination Sue replied that: Discussion: It both terminates from the remote site and can "timeout" - fail. Suggestions? I can use "disconnect", what do you think. Siva replied that this was a minor issue, and on further reflection, either "fails" or "disconnect" would be acceptable. Sue replied that she has accepted Siva's comments, and the text will be changed to "fails". This was discussed in the "Comments 11-20" thread: Comment #15. This was also discussed in the "BGP-19: Issue 34-35, 40-48" thread. ---------------------------------------------------------------------------- 35) Making Definition Style Consistant ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Adpot consistant style for the definition of events. Discussion: This started with Siva asking if we could make the definition style consistant across eventsr. Sue replied to this with text for 13-17, Siva clarified that he was talking more about 18-21, and proposed text. We are agreed on the text for 13-17: Event13: TCP connection indication and valid remote peer Definition: Event indicating the local system reception of a TCP connection request with a valid source IP address and TCP port, and valid destination IP address and TCP Port. The definition of invalid source, and invalid destination IP address is left to the implementation. BGP's destination port SHOULD be port 179 as defined by IANA. TCP connection request is denoted by the local system receiving a TCP SYN. Status: Mandatory (Optional) Event14: RCV TCP connection indication with invalid source or destination Definition: Event indicating the local system reception of a TCP connection request with either an invalid source address or port number or an invalid destination address or port number. BGP destination port number SHOULD be 179 as defined by IANA. Again, a TCP connection request denoted by local system receiving a TCP SYN. Status: Mandatory (Optional) Event15: TCP connection request sent received an ACK. Definition: Event indicating the Local system's request to establish a TCP connection to the remote peer. The local system's TCP session sent a TCP SYN, and received a TCP SYN, ACK pair of messages, and Sent a TCP ACK. Status: Mandatory Event16: TCP connection confirmed Definition: Event indicates that the local system receiving a confirmation that the TCP connection has been established by the remote site. The remote peer's TCP engine sent a TCP SYN. The local peer's TCP engine sent a SYN, ACK pair, and now has received a final ACK. Status: Mandatory Event17: TCP connection fails Definition: Event indicates that the local system has received a TCP connection failure notice. The remote BGP peer's TCP machine could have sent a FIN. The local peer would respond with a FIN-ACK. Another alternative is that the local peer indicated a timeout in the TCP session and downed the connection. Status: Mandatory Siva proposed these changes for 18-21: > Event18: BGPOpen > > Definition: An event indicating that a valid Open > message has been received. with % Event18: BGPOpen % % Definition: An event is generated when a valid Open % message has been received. > Event19: BGPOpen with BGP Delay Open Timer running > > Definition: An event indicating that a valid Open > message has been successful > established for a peer that is > currently delaying the sending of an > BGP Open message. with % Event19: BGPOpen with BGP Open Delay Timer running % % Definition: An event is generated when a valid Open % message has been received for a peer that % is currently delaying the sending of a % BGP Open message. Editorial Note: "Delay Open Timer" replaced with "Open Delay Timer" per issue 7. > Event20: BGPHeaderErr > > Definition: BGP message header is not valid. with % Event20: BGPHeaderErr % % Definition: An event is generated when a received BGP % message header is not valid. > Event21: BGPOpenMsgErr > > Definition: An BGP Open message has been received > with errors. with % Event21: BGPOpenMsgErr % % Definition: An event is generated when BGP Open message % with errors has been received. Sue replied that she accepted Siva's comments, so we are at consensus here. This was discussed in the "Comments 11-20" thread: Comment #16. This also came up in the "BGP-19: Issue 34-35, 40-48" thread. ---------------------------------------------------------------------------- 36) Event 19 - Definition Cleanup ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Replace definition for Event 19 with the text in the discussion. Discussion: Siva propsosed we replace: > Definition: An event indicating that a valid Open=20 > Message has been successful=20 > established for a peer that is=20 > currently delaying the sending of an=20 > BGP Open message.=20 with: % Definition: An event indicating that a valid OPEN % Message has been received for a peer % that has a successfully established % transport connection and is currently % delaying the seending of a BGP open % message in Event 19. Sue agreed to the changes. This was discussed in the "Comments 11-20" thread: Comment #17. ---------------------------------------------------------------------------- 37) Event 22 - Cleanup ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Replace Event 22 definition with the text from the discussion. Discussion: Siva began with observing: > Event22: Open collision discard > > Definition: An event generated administratively=20 > when a connection Collision has been=20 > detected while processing an incoming =20 > Open message. This connection has been=20 Isn't this event 'automatically' generated, since it is a system generated event ?=20 Sue replied that: response: How this generated is implementation specific. The "administratively" is to cover policy. Siva also proposed an editorial fix with: > Event 22 is an administrative could=20 > occur if FSM is implemented as two=20 > The word event is missing. How about % Event 22 is an automatic event that % could occur if FSM is implemented as two=20 Sue replied with this rewritten text: Event22: Open collision dump Definition: An event generated administratively when a connection collision has been detected while processing an incoming OPEN message and this connection has been selected to disconnected. See Section 6.8 for more information on collision detection. Event22 is an administrative based only implementation specific policy. This Event may occur if the FSM is implemented as two linked state machines. Sive agreed with this new text. This was discussed in the "Comments 11-20" thread: Comment #18. ---------------------------------------------------------------------------- 38) FSM Description - ConnectRetry Count ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: Leave the counter text alone, since it is used in peer oscillation and will be in the MIB. Discussion: Siva opened with this question: The Connect Retry count is updated by the FSM but never used. In the absence of peer oscillation damping, will this be used to stop connection establishment attempts after a certain maximum number ? Yes, this is either implementation specific or is it based on the peer oscillation damping draft. Can we include the use of this counter in some place ? Connect retry counter 1) Will be utilized by the peer oscillation damping drat. 2) Will be included in bgp-4-mibv2-xx. I just check and I didn't find it. Do you still want text in the main? To which Siva replied that he believes we can leave the main text alone. This was discussed in the "Comments 11-20" thread: Comment #19. ---------------------------------------------------------------------------- 39) Handling Event 7 (Auto Stop) to Idle State processing ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Fix the text as indicated in the discussion. Discussion: Siva began with: The handling of Event 7 is missing from the Idle State processing. Can we add this ? How about replacing > An manual stop event (Event2) is ignored in the Idle state. with % Manual stop (Event 2) and Auto stop (Event 7) events are ignored % in the Idle state Sue replied that she would add the text. This was discussed in the "Comments 11-20" thread: Comment #20. ---------------------------------------------------------------------------- 40) Clearing the Connection Retry Timer ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: Leave things alone, since it is better to be redundant than to let something slip through. Discussion: Siva opend with the observation: There are a few sections where the FSM draft states that the Connection Retry timer needs to be reset, wheras the conenct retry timer had been cleared prior to entering that state. We can remove these instructions to clear the connect retry timer. List of places where the connect retry timer need not be cleared a) Handling of Event 19 in the Connect State b) Handling of Events 12 in the Active State c) All cases where it is refered to in the OpenSent, OpenConfirm and Established states Sue replied: Comment: 1) Does it hurt to have the connect retry timer cleared at these points, since it has already been cleared. I felt it eased the implementations to allow the action routines to be shared across as many states as possible. You can see this a bit more actively. Tom replied to this: I propose we leave it in and close this issue. 1) To take out an action as redundant you need to be supremely confident that it really cannot make a difference. I am not (supremely confident); rather, the more I look at the FSM, the more places I find where actions are missing, as I have posted to the list, from obscure yet possible sequences of events and timing. And there is an outstanding issue of mine which flagged seven places where the next state was missing and so I think it impossible for any one to be confident that any particular action is redundant until that is cleared up and that is proving complex in some cases. So, play safe, keep them in. 2) The argument for removing them is that the number of possible distinct action lists is increased. True - it will mean that an implementor will have to code more code when first implementing BGP. For me this is no contest; keeping it safe at the possible cost of redundancy outweighs the one-off cost of additional implementation. So keep the actions in and close the issue. Jeff replied that he agreed with Tom on this. Siva concurred, that this approach was acceptable. Unless someone objects, this issue is at consensus. This was discussed in the "Comments 21-30" thread: Comment #21. This is also discussed in the "BGP-draft-19: Issue 40 Clear Connect retry timer" thread. ---------------------------------------------------------------------------- 41) Handling of Event 14 in the Connect State ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Make event 14 optional. Discussion: Siva opened the discussion with: > If the transport connection receives an indication > that is invalid or unconfigured. [Event 14]: > - the TCP connection is rejected. I don't understand how we would get this event while in this state. Sue replied: See my earlier comments (1-10) on the connection state. It happens in implementations which track the TCP state more closely. I suggest that Event 14 become optional. Sue also suggested we fold this into the discussion about events 13-17, which is tracked in issue 13.4. Sue proposed: My resolution: Let event 14 be optional. Not all BGP implementations support it. And asked if this let us reach consensus on this issue. Siva agreed with this, we are at consensus on this. This was discussed in the "Comments 21-30" thread: Comment #22. This was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. ---------------------------------------------------------------------------- 42) Handling events 20, 21 in the Connect State and Active State ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Use the text Tom proposed in the discussion section. Discussion: Siva began this with: We need to consider the case where we receive events 20 (message header error) and 21 (Open message error) when the delay timer is running. Since the connection has been established at this point, we need to send a Notification message and then terminate the connection. To which Sue replied: Alternative comments: 1) We have not sent an Open statement. 2) Why do we have to send an Notification? I see no justification for it. Suggestion: Do you have implementations that send notification? Do you know of others that don't. Jeff saw this as indicative of an issue with section 4.2 the way it is currently written: >From section 4.2 of -18: : 4.2 OPEN Message Format : : After a TCP is established, the first message sent by each side is an : OPEN message. If the OPEN message is acceptable, a KEEPALIVE message : confirming the OPEN is sent back. Once the OPEN is confirmed, UPDATE, : KEEPALIVE, and NOTIFICATION messages may be exchanged. This text implies that NOTIFICATIONs can only be sent once we have sent an open and then a keepalive, generally meaning we're in the Established state. Anyone suggestions for modifying the wording? Section 6.1 (Message header error) is one situation that implies that a NOTIFICATION can be sent without sending even an OPEN message. Note that since the base FSM implies that we send an OPEN message immediately when we have a completed trasnport connection, we SHOULD be in at least OpenSent. However, the DelayOpen timer means that we MAY send a NOTIFICATION when we are in the Connect state. GateD, at least, will not send a NOTIFICATION without first sending an OPEN. We need to pick one: You can send NOTIFICATIONS before OPEN or before OPEN if the OpenDelay timer is running. However, we MUST fix the text above. Tom opined: A NOTIFICATION without a preceding OPEN is rather hard to interpret; it is the OPEN that gives the recipient what it needs to know about its potential peer (Version, AS number, ID, options etc) so it makes sense to send an OPEN even if it is followed by a NOTIFICATION to say goodbye :-( as opposed to a KEEPALIVE which says hello:-). But as ever, what is implemented? Yakov suggested these modifications to the text to resolve this: 1. Delete the last sentence in the above paragraph or 2. Delete "and NOTIFICATION" in the last sentence in the above paragraph Jeff replied that he prefered the first option, and that the second could be interpreted as NOTIFICAITONs not being legal, when, in fact, they may. So the text on the table to resolve this is: 4.2 OPEN Message Format After a TCP is established, the first message sent by each side is an OPEN message. If the OPEN message is acceptable, a KEEPALIVE message confirming the OPEN is sent back. However, this does not entirely clear up the original point about the FSM. If we reveive an error in Connect/Active, do we send a NOTIFY? Do we preface it with an OPEN, so that OPEN/NOTIFY are sent in immediete succession? Sue replied: I suggest we don't send a "NOTIFICATION" when Event 20 or Event 21 is received in Conect or Active state. Tom responded to this issue with: Issue 42 queries whether or not we can send a NOTIFICATION when we have not sucessfully exchanged OPENs. I propose we should, following the suggestions of Jeff and Yakov. As Yakov suggested, this requires the removal of the second sentence, first paragraph, of 4.2 which implies a NOTIFICATION can only be sent after a succesful exchange of OPENs. I think this fits best with the other references to the uses of NOTIFICATION in the draft. In terms of the FSM, it means that in Connect and Active states, on receipt of events 20 or 21, we should send a NOTIFICATION so that the last section starting In response to any other event............. is replaced by (and noting we have agreed to drop references to MIB actions) If the BGP message header checking or OPEN message checking detect an error (see Section 6.2) [Events 20 or 21], the local system: - sends a NOTIFICATION message with the appropriate error code, - resets the connect retry timer (sets to zero), - releases all BGP resources, - drops the TCP connection - increments the ConnectRetryCnt (connect retry count) by 1, - [optionally] performs peer oscillation damping - and goes to the Idle state. In response to any other event (Events 7-8, 10-11,18, 22-27), the local system: - resets the connect retry timer (sets to zero), - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by one, - [optionally] performs peer oscillation damping, - and goes to the Idle state (Note that this text is not quite watertight. Suppose we are in Active state, having been started with CRT running, receive an SYN (event 13), send SYN-ACK and then get a malformed message (events 20/21). We have not yet received an ACK and so should not send anything over TCP; I would expect TCP to buffer this awaiting the ACK except we then take down the TCP connection - or try to; I don't know what happens next but regard it as sufficiently obscure not to be concerned). (My other concern is greater; why do we now not send NOTIFICATIONs for other events; in Open Sent, Open Confirm or Established, we send one for the 'default event list' so what makes events 20 and 21 in Active and Connect so special? I can justify the absence of a NOTIFICATION for events 7, 8, 10, 11, 18, 22 since there is no evidence of a TCP connection to send it on; but events 23-27 in Active or Connect say we have received an erroneous message, the TCP connection is there so why not send a NOTIFICATION? Event7: Automatic stop Event8: Idle hold timer expires Event10: Hold timer expires Event11: Keepalive timer expires Event18: BGPOpen Event22: Open collision dump Event23: NotifMsgVerErr Event24: NotifMsg Event25: KeepAliveMsg Event26: UpdateMsg Event27: UpdateMsgErr Sue accepted Tom's text, so barring any objections, we are at consensus on this. This was discussed in the "Comments 21-30" thread: Comment #23. This was also brought up in the "BGP-19: Issue 34-35, 40-48" thread, and the "Draft bgp19 - issue #42 NOTIFICATION before OPEN" thread. ---------------------------------------------------------------------------- 43) Handling the default events in the Connect state ---------------------------------------------------------------------------- Status: No Consensus Change: Potentially Summary: Discussion: Siva opened this with: The Open Delay timer [original: BGP Delay OpenTimers) needs to be cleared if it is running. How about adding this: % - If the ConnectRetry Timer is running % - Clear the Connect Retry timer % - Otherwise % - Clear the Open Delay timer [original: BGP Delay Open Timer] Sue replied that: By the default you mean the text: In response to any other events[Events 7-8, 10-11, 18, 20-27], the local system: "resets" to me implies stops and clears. I think the text is clear than the text above. ------------ Is this the replacement text you imply above: - resets the connect retry timer (sets to zero), - clears the Open Delay timer [original: BGP Delay timer] (sets to zero), - increments the ConnectRetryCnt (connect retry count) by 1, - [optionally] performs bgp peer oscillation damping, and - goes to Idle text: Editor's note: various incarnations of "Open Delay timer" have been replaced with "Open Delay timer". See issue 7. Sue replied that she accepted Siva's changes with these editorial changes: old text: - resets the connect retry timer (sets to zero) - clears the open delay timer new text: - if the connect retry timer is running, clear the connect retry timer (set to zero). - if the open delay timer is running, clear the open delay timer (set to zero). Since the substantive changes have been accepted, unless someone objects, this issue is at consensus. This was discussed in the "Comments 21-30" thread: Comment #24. This was also brought up in the "BGP-19: Issue 34-35, 40-48" ---------------------------------------------------------------------------- 44) Handling Event 23 in Connect and OpenSent ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Adopt text at the end of the discussion section. Discussion: This began with Siva saying: This is currently being handled in the default event processing section. However, we do not need to go through the peer oscillation damping process in this case. Can we change the wordings to reflect this, or move this out of peer oscillation damping processing ? Sue replied: 1) There is no default event handling process in the text, you will need to specify the text. 2) The state table below (hares-statemt-03.txt) states shows the changes ------------- Event 23 states: current Idle Connect Active Open-Sent Open-Cnf Establish ---------------------------------------------------- next state Idle Idle Idle Idle Idle Idle ----------------------------------------------- action V D D Y Y T ============================================== V - Indicate FSM errors and ignore. D - 1) resets the connect retry timer (sets to zero), 2) drops the TCP connection, 2) releases all BGP resources, 3) increments the ConnectRetryCnt (connect retry count) by 1, 4) [optionally] performs the bgp peer oscillation damping, and Goes to Idle state. Y 1) resets the connect retry timer (sets to zero), 2) Drops the TCP connection, 3) releases all BGP resources, 4) [optionally] In an exchange between Siva and Sue, this came up: Siva: "Default event handling" was perhaps a poor choice of words. What I meant is this Event 23 (Notify Message Version error) only indicates a version mismatch. By going through action sequence D, we will be performing peer oscillation damping. Should we perform damping, since this is not really a cause for persistent oscillation ? Also, since we have a distinct event to indicate a version error event, can include text indicating that version negotiation processing should take place upon receipt of this event ? Sue: Yes, we can change the "D" in state machine to a "y". The issue is what if Connect state occurs and there is not a TCP connection. Should an OPEN with wrong version be accepted? If the Open Delay flag is off, the connection state should not be getting an Open. The "D" action below works for "open delay flag off". The "y" action you suggest can occur if the open delay timer is on. If this is the issue, please confirm. We could say: if open delay flag is on -> y action if open delay flag is off -> D action Please let me know if this is the concern, and suggest text. Prior to this exhange, this issue was at consensus. The only thing that is firm in this exchange is changing "D" to "y". There seems to be some open discussion still, so we'll reopen it. After some discussion, this is the text we have settled on: If a NOTIFICATION message is received with a version error[Event24], the local system checks the Open Delay timer. If the Open Delay timer is running, the local system: - resets the connect retry timer (sets to zero), - stops and reset the Open Delay timer (sets to zero, - releases all BGP resources, - drops the TCP connection, - changes its state to Idle. If the Open Delay timer is not running, the local system: - resets the connect retry timer (sets to zero), - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, - optionally performs peer oscillation damping, and - changes its state to Idle. N.B. This is now event 24 (see issue 26). We are at consensus with this. This was discussed in the "Comments 21-30" thread: Comment #25. This was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. ---------------------------------------------------------------------------- 45) Event 17 in the Connect state ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Adopt text at the end of the discussion section. Discussion: This began with Siva asking: > If the transport connection fails (timeout or transport > disconnect) [Event17], the local system: > - changes its state to Active. If the transport connection fails when the Open Delay timer [original: BGP Open Delay timer] is running, should we still be going into the Active state ? Sue replied refering to the disussion tracked in issue 13.4. Jeff responded that: In this particular case, I think the issue is separate from the issues for events 13-17 since this isn't particular to how deep the BGP implementation meddles in the TCP implementation. If we are in the Connect state, because we have an incoming transport connection that has completed, but we have the OpenDelay timer running and the transport connection is closed, we can simply drop into Active after resetting the ConnectRetry timer and clearing the OpenDelay timer (if set/exists). In the case of an unconfigured peer, we can discard the FSM instance. Tom replied that he agreed with this. Tom then proposed this text: If the TCP connection fails[Event 17] and the Open Delay timer is running, the local system: - restarts the connect retry timer, - clears the Open Delay timer - continues to listen for a connection that may be initiated by the remote BGP peer, and - changes its state to Active. If the TCP connection fails [Event17] and the Open Delay timer is not running, the local system: - drops the TCP connection, - releases all BGP resources, - sets ConnectRetryCnt (the connect retry count) to zero - resets the connect retry timer (sets to zero), and - goes to Idle state. to replace If the TCP connection fails (timeout or disconnect) [Event17], the local system: - restarts the connect retry timer, - continues to listen for a connection that may be initiated by the remote BGP peer, and - changes its state to Active. Sue agreed to change the text to reflect the comments. o Jeff brought out a couple of other concerns, and Tom replied: > If the TCP connection fails [Event17] and the Open Delay > timer is not running, the local system: > - drops the TCP connection, > - releases all BGP resources, There are no resources to release while in the connect state. (Unless we're using this as shorthand for something else - I forget.) Tom: I was unsure about this action. It is present for Active state event 17 which is why I put it in, it does include sub-actions such as clear Open Delay timer (not running), clear Connect Retry timer (could be running) so I think it right to play safe and include it. Jeff: > - sets ConnectRetryCnt (the connect retry count) to zero I'm forgetting if this action is consistant with everything else. I don't have a current copy of the FSM and I don't trust -18 to be current enough. :-) This said, why do we go to zero? I could see not incrementing it and letting the normal decay process deal with it. The same would apply for the above. Tom: Again, I was unsure about this so put it in and waited for comment. I have a chart of 27 events and 6 states in which I have colored in the connect retry and peer oscillation damping actions and it looks like measles; I could not divine the underlying logic. Incrementing the connect retry count would make as much if not more sense to me. (It is zeroed for Manual Stop). But the action '[optionally] perform peer oscillation damping' is yet more erratic (eg for event 10 - Hold Timer expired - it is performed exiting Connect, Active, Established but not Open Confirm or Open Sent) so I left it out. Again, it might make more sense put it in. Sue replied to this: The connect state could have a few resources (minimum peer footprint) as the FSM goes from Idle to Connected state. While this amount of BGP resources is not as much as the final amount, it still needs to get released. 2nd - I think the connectretrycount should be removed; Thanks for catching that. Please confirm that part #1 is OK with you so we can put issue 45 into consensus state. Sue accpeted Tom's solution, for the following text: If the TCP connection fails [Event18], the local system checks the Open Delay Timer. If the Open Delay timer is running, the local system: - restarts the connect retry timer, - stops the Open Delay timer and resets value to zero, - continues to listen for a connection that may be initiated by the remote BGP peer, and - changes its state to Active. If the open Delay timer is not running, the locla system: - resets the connect retry timer (sets to zero), and - Drops the TCP connection, - Releases all BGP resources, - and goes to Idle State. N.B. This is now event 18 (see issue 26). We are at consensus with this. This was discussed in the "Comments 21-30" thread: Comment #26. This was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. ---------------------------------------------------------------------------- 46) Handling of Event 17 in Active state ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: See issue 13.4, this issue closed in favor of that one. Discussion: This began with Siva saying: We should now move into Idle state. Can we add % - Goes to Idle state Sue replied that she thought this should be bundled in with the issue tracked in 13.4. Since no one objected, this issue has been closed in favor of that one. This was discussed in the "Comments 21-30" thread: Comment #27. ---------------------------------------------------------------------------- 47) Handling of Event 19 in Active state ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Add the new text in the discussion section. Discussion: This began with Siva suggesting: > - Set the Hold timer to a large value (4 minutes), Since OPEN messages have been exchanged, can we change this to % - If the negotiated Hold time is not 0, set the Hold time to % - the negotiated value Sue replied that: The text in Active and Open Sent needs to be the same. The text in Open Sent is: - sets the Hold timer according to the negotiated value (see section 4.2), and Which text do you prefer? Sue replied that this text would be added to the next draft: New text - if the hold timer value is non-zero, - starts the keepalive timer to initial value, - resets the hold timer to the negotiated value, - else if the hold timer is zero - resets the keepalive timer (set to zero), - resets the hold timer to zero. This seems to address Siva's concerns, this issue is at consensus, if there are objections, we can reopen it. This was discussed in the "Comments 21-30" thread: Comment #28. This was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. ---------------------------------------------------------------------------- 48) Handling of Event 2 in Active state ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Update the draft with the text at the end of the discussion section. Discussion: Siva opened with: > A manual stop event[Event2], the local system: > - Sends a notification with a Cease, > - drops the Transport connection These two actions are possible only if a transport connection had already been established. How about changing the text to % - If a transport connection had been successfully established % - Send a Notification with a Cease % - Drop the Transport Connection Sue counter suggested: A manual stop event [Event 2], the local system - Drop the TCP connection, - Release all BGP resources, - resets the connection retry timer [sets to zero], - goes to Idle. Jeff replied: I'm rather confused. Under exactly what circumstances can we be in the Active state and have an active TCP connection at all? Ditto for having any BGP resources? Going to Idle is fine. Tom offered this example: eg start with passive flag, TCP SYN received, SYN-ACK sent, ACK received, Delay Open flag set and there we are. Most events are now possible either from a well-implemented remote peer or a badly implemented remote peer. Sue asked if there were any additional comments, if not, the text will be: A manual stop event[Event2], the local system: - Sends a NOTIFICATION with a Cease, - releases all BGP resources including - stopping the OPen delay timer - drops the TCP connection, - sets ConnectRetryCnt (connect retry count) to zero - resets the connect retry timer (sets to zero), - changes its state to Idle. There have been no additional comments, we will use the text Sue proposed. This was discussed in the "Comments 21-30" thread: Comment #29. This was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. ---------------------------------------------------------------------------- 49) Default Event handling in Active state ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: No routes in active. Discussion: Siva began with: To ensure consistencey with E2 handling, can we add % - If any BGP Routes exist, delete the routes Sue replied: Comment: Yakov and Jeff noted, there are no routes in Active state. Since there were no responses disagreeing, we'll consider this closed unless someone wants to open it back up. This was discussed in the "Comments 21-30" thread: Comment #30. ---------------------------------------------------------------------------- 50) Clearing Hold timer in OpenSent, OpenConfirm and Established State ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: This issue is addressed in the "Clear BGP resources" Discussion: This began with Siva stating: In all event handling where we go to Idle state, we need to clear the Hold Timer as well. Sue replied that: issue resolve one way last Jan - March Clearing of keep alive timer included in Clear BGP resources No response to this yet, but since this seems to be resolved it is at consensus unless someone objects. This was discussed in the "Comments 30-36" thread: Comment #31. ---------------------------------------------------------------------------- 51) Clearing Keepalive timer in OpenConfirm and Established State ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: This issue is addressed in the "Clear BGP resources" Discussion: This began with Siva stating: In all event handling where we go to Idle state, we need to clear the Keepalive Timer as well. Sue replied that: issue resolve one way last Jan - March Clearing of keep alive timer included in Clear BGP resources No response to this yet, but since this seems to be resolved it is at consensus unless someone objects. This was discussed in the "Comments 30-36" thread: Comment #32. ---------------------------------------------------------------------------- 52) Handling Event 18 in the OpenSent state (Keepalive Timer) ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Make the event optional. Discussion: This began with Siva asking: Why do we start the Keepalive timer at this stage ? Isn't it sufficient to do so when we move into Established state ? Sue replied: An earlier comment from Tom (and you) requested the following: <---Open [Open sent state] Open--> [Event 18] <---Open <---Keepalive [Action from Event 18 in Open Sent] [Open Confirm] Keepalive -> [Event 25] [established] What do implementations do? We'll have to query implementations. Jeff added: I'm assuming the second OPEN going from right to left is a typo. If it isn't, thats a FSM error to the peer on the left. Theoretically, an implementation that utilizes its keepalive timer to send the first keepalive to transition to Established is still interoperable. However: o Keepalives can be disabled by negotiating hold time of zero o We really shouldn't need to restart the Keepalive timer. If there is a delay in the keepalive that transitions from OpenConfirm to Established, its due to the transport connection. It should be reliable and it *should* get through. If it doesn't, there's other problems and the hold timer for the peer on the right should do the Right Thing and drop the connection. > What do implementations do? We'll have to query implementations. GateD at least waits to enter the Established state prior to starting the KeepAlive timer. Tom also added: My comment was that if we do not send a KeepAlive (and start the KeepAlive timer), on exiting from Active with Event 19 to OpenConfirm then we never will and the connection will die. Open Confirm state means valid Open received so we must send a KeepAlive to acknowledge the Open (as pointed out in Jeff's other posting) and we never do it in OpenConfirm state itself (unless the KeepAlive timer expires which it cannot because we have not started it). So for me, OpenSent state Event 18 was and is correct, sending the KeepAlive without which the connection goes no further and Active state Event 19 needs to be brought into line. To say that the timer is started when entering Established state is fine except for a slight problem; we have no way in this FSM of defining actions that are taken on entering a state, only actions to be taken on leaving another state so that is why the KeepAlive actions need to be where they are (or are not in the case of Active state Event 19). Sue replied, asking more implementors to chime in on what they do for this part of the FSM. Curits replied that we should: Make it optional. Timing out in open or open-sent has never been much of an issue, so whether one or three keepalive get sent shouldn't be a hot topic. Sue said that this was fine, and she would work on text specifying optional. Jeff replied regarding GateD's behavior: GateD will start its keepalive timer while in this state, so multiple keepalives will be sent. As someone previously said, this is a "yawn" issue. But to choose one way or the other, we may potentially make someone in non-compliance. >From the closure of issue 12, we have this text, which discusses Keepalives to consider in relation to the other keepalive issue here: Change 1: new text Active state - event 19 If an Open is received with the Open Delay timer is running [Event 19], the local system - clears the connect retry timer (cleared to zero), - stops and clears the Open Delay timer - completes the BGP initialization, - stops and clears the Open Delay timer - sends an OPEN message, - send a Keepalive message, - if the hold timer value is non-zero, - starts the keepalive timer to initial value, - resets the hold timer to the negotiated value, else if the hold timer is zero - resets the keepalive timer (set to zero), - resets the hold timer to zero. - changes its state to OpenConfirm. If the value of the autonomous system field is the same as the local Autonomous System number, set the connection status to an internal connection; otherwise it is "external". Sicne there were no more comments, this is at consensus. This was discussed in the "Comments 30-36" thread: Comment #33. And in the "BGP-draft-19: Issue 52 - Event 18 in OpenSent State (Keepalive timer set)" thread. ---------------------------------------------------------------------------- 53) Established State MIB ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: MIB references pulled in favor of having them in the MIB document. See issue 8. Discussion: This began with Siva asking: Some event handling in the Established state do not set the MIB Reason when handling an event that causes an error. Can we add this ? Sue replied that we have pulled the MIB wording from the FSM. See issue 8. This was discussed in the "Comments 30-36" thread: Comment #34. ---------------------------------------------------------------------------- 54) State impact of not supporting Optional Events ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Add the text at the end of the discussion section. Discussion: Siva stated that: For the events whose status is optional, can we state the impact of not supporting them (in terms of any interoperability issues). I understand that most of the optional events will not have such an impact; but a clarification statement for the optional events would benefit new implementors. Sue responded: Much of the support of optional parameters depends on policy. I could put a short note about the optional events and parameters as part of 8.1.5 or 8.2.1.3 I think it fits better in 8.1.5. Optional: Events: 3-8, 12, 13-14[my suggestion] 19, 22 Timers: Idle Hold Timer Open Delay Timer Required flags for optional parameters: Open Delay Flag BGP Stop Flap Sue said she would try to work up more if it is agreed that this is on the right track. Sue provided this text to clarify the behavior associated with Optional Attributes: 8.2.1.3 FSM and Optional Attributes Optional Attributes specify either flags that augment the normal processing of the BGP FSM, or optional timers. If a Optional attribute can be set on a system, the Events and the BGP FSM actions must be support. For example, if the following options can be set in a BGP implementation: AutoStart and Passive TCP connection Establishment flag, then the events 3, 4 and 5 must be supported. If an Optional attribute cannot be set (that is declared always off logically), the events supporting that set of options do not have to be supported. This was discussed in the "Comments 30-36" thread: Comment #35. ---------------------------------------------------------------------------- 55) New DelayOpen State ---------------------------------------------------------------------------- Status: Consensus Change: No Summary: We've chosen not to reopen the debate about adding a DelayOpen State to the FSM. Discussion: Siva began with asking: Is delaying the sending of an OPEN message a standrad industry practice ? Also, in the FSM, this has been handled by practically implementing a sub-state each, within the CONNECT and ACTIVE states. Won't the FSM look more simple if we just had a new DelayOpen state that we could move into ? Sue responded that this was something we have tried to do before, but that it spawned some degree of rabid response on both sides. Given our current mandate to stick with what is implemented, it is probably best not to reopen this debate. Unless someone badly wants to reopen this debate, the issue is at Consenus. This was discussed in the "Comments 21-30" thread: Comment #22. This was discussed in the "Comments 21-30" thread: Comment #26. This was discussed in the "Comments 30-36" thread: Comment #36. ---------------------------------------------------------------------------- 56) Clarify what is covered in the base document. ---------------------------------------------------------------------------- Status: Consensus Change: Yes Summary: Add the text at the end of the discussion to clarify what is documented where with regard to BGP and its extentions. Discussion: This grew out of a discussion on how to use BGP Identifiers in an IPv6-only environment. In that discussion it became clear that the way the documents are currently structured it is not clear to new readers that extention specifications can and do specify behavior that superseeds the behavior specified in the base spec. To that end it was agreed that this text should be added: This document specifies the base behavior of the BGP protocol. This behavior can and is modified by extention specifications. When the protocol is extended the new behavior is fully documented in the extention specifications. This was discussed in the "Next-Hop in IPv6 only environments" thread. --Izn7cH1Com+I3R9J Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="Changelog-v2.txt" CHANGELOG ---------------------------------------------------------------------------- v2.2 to v2.3 2003-02-26 ---------------------------------------------------------------------------- Added: 56) Clarify what is covered in the base document. Updated: 18) MED Removal Text 24) Events 3, 5, 6 & 7 Give Examples 26) Event 4 & 5 - bgp_stop_flap option 33) Event 13 & 14 - Valid Addresses & Ports 41) Handling of Event 14 in the Connect State 42) Handling events 20, 21 in the Connect State and Active State 44) Handling Event 23 in Connect and OpenSent 45) Event 17 in the Connect state 52) Handling Event 18 in the OpenSent state (Keepalive Timer) 54) State impact of not supporting Optional Events Moved to Consensus: 18) MED Removal Text 24) Events 3, 5, 6 & 7 Give Examples 26) Event 4 & 5 - bgp_stop_flap option 33) Event 13 & 14 - Valid Addresses & Ports 41) Handling of Event 14 in the Connect State 42) Handling events 20, 21 in the Connect State and Active State 44) Handling Event 23 in Connect and OpenSent 45) Event 17 in the Connect state 52) Handling Event 18 in the OpenSent state (Keepalive Timer) 54) State impact of not supporting Optional Events 56) Clarify what is covered in the base document. ---------------------------------------------------------------------------- v2.1 to v2.2 2003-01-30 ---------------------------------------------------------------------------- Updated: 12) Entering OpenConfirm / Adding "Stop OpenDelay" action 13) FSM Missing Next States 13.2) FSM Missing Next States - Event 14 (Connect State) 13.4) FSM Missing Next States - Event 13-17 (TCP Connection) 13.6) FSM Missing Next States - Event 18 (Open Confirm) 17) Section 3, Page 8, Paragraph 3 - Obsolete? 18) MED Removal Text 21) Session Attributes - IdleHold Timer 22) Specify New Attributes (Accept Connections/Peer Oscillation Damping) 24) Events 3, 5, 6 & 7 Give Examples 26) Event 4 & 5 - bgp_stop_flap option 34) Event 17 - TCP Connection Fails to TCP Connection Termination 35) Making Definition Style Consistant 40) Clearing the Connection Retry Timer 41) Handling of Event 14 in the Connect State 42) Handling events 20, 21 in the Connect State and Active State 43) Handling the default events in the Connect state 44) Handling Event 23 in Connect and OpenSent 45) Event 17 in the Connect state 47) Handling of Event 19 in Active state 48) Handling of Event 2 in Active state 52) Handling Event 18 in the OpenSent state (Keepalive Timer) Moved to Consensus: 12) Entering OpenConfirm / Adding "Stop OpenDelay" action 13) FSM Missing Next States 13.2) FSM Missing Next States - Event 14 (Connect State) 13.4) FSM Missing Next States - Event 13-17 (TCP Connection) 13.6) FSM Missing Next States - Event 18 (Open Confirm) 17) Section 3, Page 8, Paragraph 3 - Obsolete? 34) Event 17 - TCP Connection Fails to TCP Connection Termination 35) Making Definition Style Consistant 40) Clearing the Connection Retry Timer 43) Handling the default events in the Connect state 47) Handling of Event 19 in Active state 48) Handling of Event 2 in Active state ---------------------------------------------------------------------------- v2.0 to v2.1 2003-01-20 ---------------------------------------------------------------------------- Updated: 2) MUST/SHOULD Capitalization 13.2) FSM Missing Next States - Event 14 (Connect State) 13.4) FSM Missing Next States - Event 13-17 (TCP Connection) 13.5) FSM Missing Next States - Event 17 (Connect State) 13.6) FSM Missing Next States - Event 18 (Open Confirm) 15) FSM - Consistent FSM Event Names 17) Section 3, Page 8, Paragraph 3 - Obsolete? 21) Session Attributes - IdleHold Timer 22) Specify New Attributes (Accept Connections/Peer Oscillation Damping) 24) Events 3, 5, 6 & 7 Give Examples 26) Event 4 & 5 - bgp_stop_flap option 33) Event 13 & 14 - Valid Addresses & Ports 45) Event 17 in the Connect state Moved to Consensus: 13.5) FSM Missing Next States - Event 17 (Connect State) 15) FSM - Consistent FSM Event Names 21) Session Attributes - IdleHold Timer 22) Specify New Attributes (Accept Connections/Peer Oscillation Damping) --Izn7cH1Com+I3R9J-- 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 MAA26613 for ; Wed, 26 Feb 2003 12:53:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4688D9128E; Wed, 26 Feb 2003 12:52:44 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0FF6E9128F; Wed, 26 Feb 2003 12:52:43 -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 BFA969128E for ; Wed, 26 Feb 2003 12:52:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9685B5E13E; Wed, 26 Feb 2003 12:52:42 -0500 (EST) Delivered-To: idr@merit.edu Received: from ganesh.ctd.hctech.com (Ganesh.hcltech.com [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id 4569B5DF30 for ; Wed, 26 Feb 2003 12:52:41 -0500 (EST) Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Feb 2003 23:22:34 +0530 Message-ID: <60F922ABE8BE9C428E806F43C0EC73680B40E1@HARITHA> From: "Sivananda Ramnath - CTD, Chennai." To: idr@merit.edu Cc: Susan Hares Subject: RE: Open FSM issues Date: Wed, 26 Feb 2003 23:22:32 +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 Hello, > - 42 - I accept Tom's text with the additions to make > send the Notification based on a new > optional attribute > in Connect and Open Sent I don't think this should be optional. When we are in the Connect/Open Sent state with OpenDelay timer running and we identify problems with the OPEN message tat is received, a NOTIFICATION must be sent to the peer to indicate the problem. Failing this may cause connect loops in some circumstances such as version errors. Siva (siva@ctd.hcltech.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 IAA17407 for ; Wed, 26 Feb 2003 08:16:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C5E069126B; Wed, 26 Feb 2003 08:16:01 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 873EC91274; Wed, 26 Feb 2003 08:16: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 D71449126B for ; Wed, 26 Feb 2003 08:15:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id B3BC05DF91; Wed, 26 Feb 2003 08:15:54 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id C73F15DE76 for ; Wed, 26 Feb 2003 08:15:53 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.11.3/8.11.1) id h1QDFrC95141 for idr@merit.edu; Wed, 26 Feb 2003 08:15:53 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.nexthop.com (8.11.3/8.11.1) with ESMTP id h1QDFl595124 for ; Wed, 26 Feb 2003 08:15:47 -0500 (EST) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: FW: Open FSM issues X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 26 Feb 2003 08:15:46 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open FSM issues Thread-Index: AcLdIXGj2wgW12mJQxqxWp03eFh4ugAd1ZkA From: "Susan Hares" To: Cc: X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id IAA17407 Andrew: Please note that issue 54 was included below, but mis-numbered as 52. I will be sending the draft FSM text to Yakov once I get your final list. Sue Hares > -----Original Message----- > From: Susan Hares > Sent: Tuesday, February 25, 2003 5:59 PM > To: 'idr@merit.edu' > Cc: 'yakov@juniper.net' > Subject: Open FSM issues > > > Here's the current open issues (please check Andrew): > > - 24 - consensus, no change (Siva agrees) > - 26 - consensus, I added a new event per Siva request, see text below > - 33 - Yakov and Sue declare consensus, stay with current text > - 41 - Old event 14 is now optional based on the Track TCP flag > - 42 - I accept Tom's text with the additions to make > send the Notification based on a new optional attribute > in Connect and Open Sent > > - 44 - Now event 24 (due to issue 26) I accept Tom's solution and > I'll put the text in Connect and Open Sent > > - 45 - Event 18 (due to issue 26) in Connect State - I accept Tom's solution and > I'll put the text below in connect state. > > - 52 - Yakov and Sue declare consensus, no changes > - 54 - consensus, I'll accept Tom's comments and put in comment below > in section 8.1.3 > > Please consider these items closed. > > Sue Hares > > =============== > Event 26 > > > > Event 7: Automatic start with bgp_stop flap option set and passive > TCP establishment option set > > Definition: Local system automatically starts the > BGP peer connection with peer oscillation > damping enabled and passive TCP establishment > enabled. The exact method of damping > persistent peer oscillations is left up to the > implementation, and is outside the scope of > this document. > > Status: Optional, used only if the bgp peer has enabled > bgp peer oscillation damping with following optional flags > settings below. > > Optional > attributes: 1) Perform automatic start flag SHOULD be set > 2) BGP stop_peer_flap flag SHOULD be set > > I've re-ordered the Timer events to keep the text changes down > to a minimum. > > action 9 - connect retry timer > action 10 - Hold Timer expires > action 11 - Keepalive timer expires > action 13 - Open Delay timer expires > action 14 - Idle Hold timer expires > > All other events are incremented by 1 > > ================== > > Issue 42 > > New text in optional section: > > Next text in > > If BGP message header checking detects an error [Event 21] or Open message > checking detects an error [Event 22] (see section 6.2), the > local system: > - (optionally) If the Notification without OPen flag is set > and sends a NOTIFICATION message with the appropriate error code, > - resets the connect retry timer (sets to zero), > - releases all BGP resources, > - drops the TCP connection, > - increments the ConnectRetryCnt (connect retry count) by 1, > - [optionally] performs peer oscillation damping, > - and goes to Idle. > > =========== > Issue 44 > > If a NOTIFICATION message is received with a version > error[Event24], the local system checks the Open Delay timer. > If the Open Delay timer is running, the local system: > - resets the connect retry timer (sets to zero), > - stops and reset the Open Delay timer (sets to zero, > - releases all BGP resources, > - drops the TCP connection, > - changes its state to Idle. > If the Open Delay timer is not running, the local system: > - resets the connect retry timer (sets to zero), > - releases all BGP resources, > - drops the TCP connection, > - increments the ConnectRetryCnt (connect retry count) by 1, > - optionally performs peer oscillation damping, and > - changes its state to Idle.> > > ------------ > issue 45 text > > If the TCP connection fails [Event18], the local system checks > the Open Delay Timer. If the Open Delay timer is running, > the local system: > - restarts the connect retry timer, > - stops the Open Delay timer and resets value to zero, > - continues to listen for a connection that may be > initiated by the remote BGP peer, and > - changes its state to Active. > If the open Delay timer is not running, the locla system: > - resets the connect retry timer (sets to zero), and > - Drops the TCP connection, > - Releases all BGP resources, > - and goes to Idle State. > > > issue [Susan Hares] 54 > -------- > > 8.2.1.3 FSM and Optional Attributes > .sp > .in4 > Optional Attributes specify either flags that augment the normal > processing of the BGP FSM, or optional timers. If a Optional > attribute can be set on a system, the Events and the BGP FSM actions > must be support. For example, if the following options can > be set in a BGP implementation: AutoStart and Passive TCP connection > Establishment flag, then the events 3, 4 and 5 must be supported. > .sp > .in 4 > If an Optional attribute is cannot be set (that is declared always off > logically), the events supporting that set of options do not > have to be supported. 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 EAA11847 for ; Wed, 26 Feb 2003 04:50:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3BB1C91234; Wed, 26 Feb 2003 04:50:24 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F17CB9123A; Wed, 26 Feb 2003 04:50:23 -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 9A2E091234 for ; Wed, 26 Feb 2003 04:50:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 866E85DDD0; Wed, 26 Feb 2003 04:50:22 -0500 (EST) Delivered-To: idr@merit.edu Received: from pengo.systems.pipex.net (pengo.systems.pipex.net [62.241.160.193]) by segue.merit.edu (Postfix) with ESMTP id 2F0745DDC8 for ; Wed, 26 Feb 2003 04:50:22 -0500 (EST) Received: from tom3 (userbm66.uk.uudial.com [62.188.145.18]) by pengo.systems.pipex.net (Postfix) with SMTP id DA4334C0032B; Wed, 26 Feb 2003 09:50:18 +0000 (GMT) Message-ID: <00a301c2dd7c$29d1e560$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: , "Susan Hares" Cc: , Subject: Re: Open FSM issues Date: Wed, 26 Feb 2003 09:47:15 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-idr@merit.edu Precedence: bulk I still have open issues with next states. Connect state event 14 has no next state; the discussion became one of what action to take (issue13.2) with proposals for going to Active or staying in Connect and I am not clear from the issue list what the answer is. Likewise Active state events 13 and14, the discussion became (Issue 13.4) should the events be optional? Don't care but whether they are or are not optional, the fsm needs a next state and I do not see it in the issue list. Tom Petch nwnetworks@dial.pipex.com -----Original Message----- From: andrewl@xix-w.bengi.exodus.net To: Susan Hares Cc: idr@merit.edu ; yakov@juniper.net Date: 26 February 2003 05:44 Subject: Re: Open FSM issues >Sue, > >I've updated the issues' list and what is below generally jives with what >I have, exceptions are noted below: > >> Here's the current open issues (please check Andrew): >> >> - 24 - consensus, no change (Siva agrees) >> - 26 - consensus, I added a new event per Siva request, see text below >> - 33 - Yakov and Sue declare consensus, stay with current text >> - 41 - Old event 14 is now optional based on the Track TCP flag >> - 42 - I accept Tom's text with the additions to make >> send the Notification based on a new optional attribute >> in Connect and Open Sent >> >> - 44 - Now event 24 (due to issue 26) I accept Tom's solution and >> I'll put the text in Connect and Open Sent > >I assume, you mean Siva's solution? I didn't see Tom's comments in the >issue log, although I could have missed something. The issue has been updated >as at consensus, with the text you've supplied below. > >> - 45 - Event 18 (due to issue 26) in Connect State - I accept Tom's solution and >> I'll put the text below in connect state. >> >> - 52 - Yakov and Sue declare consensus, no changes > >I added the text you have below, section 8.2.1.3 to the issues list. I'm >not sure that this completely resolves the original issue, which focused >on when we need to start the Keepalive timer, however, since there have been >a lot of changes to the FSM, let's call it at consensus, and we if a problem >remains we can address it then. > >Also, with this issue, am I correct to assume that the text that issue 12 >produced with regard to keepalive timers, which is also quoted here will >remain in the document? Specifically this text is: > > Change 1: new text > > Active state - event 19 > > If an Open is received with the Open Delay timer is > running [Event 19], the local system > - clears the connect retry timer (cleared to zero), > - stops and clears the Open Delay timer > - completes the BGP initialization, > - stops and clears the Open Delay timer > - sends an OPEN message, > - send a Keepalive message, > - if the hold timer value is non-zero, > - starts the keepalive timer to initial value, > - resets the hold timer to the negotiated value, > else if the hold timer is zero > - resets the keepalive timer (set to zero), > - resets the hold timer to zero. > > - changes its state to OpenConfirm. > > If the value of the autonomous system field is the same as the local > Autonomous System number, set the connection status to an internal > connection; otherwise it is "external". > >> - 54 - consensus, I'll accept Tom's comments and put in comment below >> in section 8.1.3 > >Also, here I don't have Tom's comments in the log. Do we have text for this? > >> Please consider these items closed. >> > ><< snipped >> > >> issue 52 >> -------- >> >> 8.2.1.3 FSM and Optional Attributes >> .sp >> .in4 >> Optional Attributes specify either flags that augment the normal >> processing of the BGP FSM, or optional timers. If a Optional >> attribute can be set on a system, the Events and the BGP FSM actions >> must be support. For example, if the following options can >> be set in a BGP implementation: AutoStart and Passive TCP connection >> Establishment flag, then the events 3, 4 and 5 must be supported. >> .sp >> .in 4 >> If an Optional attribute is cannot be set (that is declared always off > ^^ --> typo?? > >Updated the issue, without the "is" above. > >> logically), the events supporting that set of options do not >> have to be supported. > >Andrew 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 AAA04249 for ; Wed, 26 Feb 2003 00:44:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 29C629127E; Wed, 26 Feb 2003 00:43:54 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB98E9127F; Wed, 26 Feb 2003 00:43: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 B8FC29127E for ; Wed, 26 Feb 2003 00:43:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8B5665DEAA; Wed, 26 Feb 2003 00:43:52 -0500 (EST) Delivered-To: idr@merit.edu Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 2FAB95DD91 for ; Wed, 26 Feb 2003 00:43:52 -0500 (EST) Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id VAA17797; Tue, 25 Feb 2003 21:40:52 -0800 (PST) Date: Tue, 25 Feb 2003 21:40:52 -0800 From: andrewl@xix-w.bengi.exodus.net To: Susan Hares Cc: idr@merit.edu, yakov@juniper.net Subject: Re: Open FSM issues Message-ID: <20030225214052.K5760@demiurge.exodus.net> 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 shares@nexthop.com on Tue, Feb 25, 2003 at 05:58:43PM -0500 Sender: owner-idr@merit.edu Precedence: bulk Sue, I've updated the issues' list and what is below generally jives with what I have, exceptions are noted below: > Here's the current open issues (please check Andrew): > > - 24 - consensus, no change (Siva agrees) > - 26 - consensus, I added a new event per Siva request, see text below > - 33 - Yakov and Sue declare consensus, stay with current text > - 41 - Old event 14 is now optional based on the Track TCP flag > - 42 - I accept Tom's text with the additions to make > send the Notification based on a new optional attribute > in Connect and Open Sent > > - 44 - Now event 24 (due to issue 26) I accept Tom's solution and > I'll put the text in Connect and Open Sent I assume, you mean Siva's solution? I didn't see Tom's comments in the issue log, although I could have missed something. The issue has been updated as at consensus, with the text you've supplied below. > - 45 - Event 18 (due to issue 26) in Connect State - I accept Tom's solution and > I'll put the text below in connect state. > > - 52 - Yakov and Sue declare consensus, no changes I added the text you have below, section 8.2.1.3 to the issues list. I'm not sure that this completely resolves the original issue, which focused on when we need to start the Keepalive timer, however, since there have been a lot of changes to the FSM, let's call it at consensus, and we if a problem remains we can address it then. Also, with this issue, am I correct to assume that the text that issue 12 produced with regard to keepalive timers, which is also quoted here will remain in the document? Specifically this text is: Change 1: new text Active state - event 19 If an Open is received with the Open Delay timer is running [Event 19], the local system - clears the connect retry timer (cleared to zero), - stops and clears the Open Delay timer - completes the BGP initialization, - stops and clears the Open Delay timer - sends an OPEN message, - send a Keepalive message, - if the hold timer value is non-zero, - starts the keepalive timer to initial value, - resets the hold timer to the negotiated value, else if the hold timer is zero - resets the keepalive timer (set to zero), - resets the hold timer to zero. - changes its state to OpenConfirm. If the value of the autonomous system field is the same as the local Autonomous System number, set the connection status to an internal connection; otherwise it is "external". > - 54 - consensus, I'll accept Tom's comments and put in comment below > in section 8.1.3 Also, here I don't have Tom's comments in the log. Do we have text for this? > Please consider these items closed. > << snipped >> > issue 52 > -------- > > 8.2.1.3 FSM and Optional Attributes > .sp > .in4 > Optional Attributes specify either flags that augment the normal > processing of the BGP FSM, or optional timers. If a Optional > attribute can be set on a system, the Events and the BGP FSM actions > must be support. For example, if the following options can > be set in a BGP implementation: AutoStart and Passive TCP connection > Establishment flag, then the events 3, 4 and 5 must be supported. > .sp > .in 4 > If an Optional attribute is cannot be set (that is declared always off ^^ --> typo?? Updated the issue, without the "is" above. > logically), the events supporting that set of options do not > have to be supported. Andrew 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 RAA21308 for ; Tue, 25 Feb 2003 17:59:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 13ECA91272; Tue, 25 Feb 2003 17:58:53 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF99891273; Tue, 25 Feb 2003 17:58:52 -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 4BD9991272 for ; Tue, 25 Feb 2003 17:58:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 273075DEF4; Tue, 25 Feb 2003 17:58:51 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 7D13A5DED8 for ; Tue, 25 Feb 2003 17:58:50 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.11.3/8.11.1) id h1PMwnL81282 for idr@merit.edu; Tue, 25 Feb 2003 17:58:49 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.nexthop.com (8.11.3/8.11.1) with ESMTP id h1PMwh581269 for ; Tue, 25 Feb 2003 17:58:43 -0500 (EST) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Open FSM issues X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 25 Feb 2003 17:58:43 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open FSM issues Thread-Index: AcLdIXGj2wgW12mJQxqxWp03eFh4ug== From: "Susan Hares" To: Cc: X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id RAA21308 Here's the current open issues (please check Andrew): - 24 - consensus, no change (Siva agrees) - 26 - consensus, I added a new event per Siva request, see text below - 33 - Yakov and Sue declare consensus, stay with current text - 41 - Old event 14 is now optional based on the Track TCP flag - 42 - I accept Tom's text with the additions to make send the Notification based on a new optional attribute in Connect and Open Sent - 44 - Now event 24 (due to issue 26) I accept Tom's solution and I'll put the text in Connect and Open Sent - 45 - Event 18 (due to issue 26) in Connect State - I accept Tom's solution and I'll put the text below in connect state. - 52 - Yakov and Sue declare consensus, no changes - 54 - consensus, I'll accept Tom's comments and put in comment below in section 8.1.3 Please consider these items closed. Sue Hares =============== Event 26 Event 7: Automatic start with bgp_stop flap option set and passive TCP establishment option set Definition: Local system automatically starts the BGP peer connection with peer oscillation damping enabled and passive TCP establishment enabled. The exact method of damping persistent peer oscillations is left up to the implementation, and is outside the scope of this document. Status: Optional, used only if the bgp peer has enabled bgp peer oscillation damping with following optional flags settings below. Optional attributes: 1) Perform automatic start flag SHOULD be set 2) BGP stop_peer_flap flag SHOULD be set I've re-ordered the Timer events to keep the text changes down to a minimum. action 9 - connect retry timer action 10 - Hold Timer expires action 11 - Keepalive timer expires action 13 - Open Delay timer expires action 14 - Idle Hold timer expires All other events are incremented by 1 ================== Issue 42 New text in optional section: Next text in If BGP message header checking detects an error [Event 21] or Open message checking detects an error [Event 22] (see section 6.2), the local system: - (optionally) If the Notification without OPen flag is set and sends a NOTIFICATION message with the appropriate error code, - resets the connect retry timer (sets to zero), - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, - [optionally] performs peer oscillation damping, - and goes to Idle. =========== Issue 44 If a NOTIFICATION message is received with a version error[Event24], the local system checks the Open Delay timer. If the Open Delay timer is running, the local system: - resets the connect retry timer (sets to zero), - stops and reset the Open Delay timer (sets to zero, - releases all BGP resources, - drops the TCP connection, - changes its state to Idle. If the Open Delay timer is not running, the local system: - resets the connect retry timer (sets to zero), - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, - optionally performs peer oscillation damping, and - changes its state to Idle. ------------ issue 45 text If the TCP connection fails [Event18], the local system checks the Open Delay Timer. If the Open Delay timer is running, the local system: - restarts the connect retry timer, - stops the Open Delay timer and resets value to zero, - continues to listen for a connection that may be initiated by the remote BGP peer, and - changes its state to Active. If the open Delay timer is not running, the locla system: - resets the connect retry timer (sets to zero), and - Drops the TCP connection, - Releases all BGP resources, - and goes to Idle State. issue 52 -------- 8.2.1.3 FSM and Optional Attributes .sp .in4 Optional Attributes specify either flags that augment the normal processing of the BGP FSM, or optional timers. If a Optional attribute can be set on a system, the Events and the BGP FSM actions must be support. For example, if the following options can be set in a BGP implementation: AutoStart and Passive TCP connection Establishment flag, then the events 3, 4 and 5 must be supported. .sp .in 4 If an Optional attribute is cannot be set (that is declared always off logically), the events supporting that set of options do not have to be supported. 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 MAA10110 for ; Tue, 25 Feb 2003 12:10:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DDE6291269; Tue, 25 Feb 2003 12:10:18 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D54C9126A; Tue, 25 Feb 2003 12:10: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 54F9F91269 for ; Tue, 25 Feb 2003 12:10:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 33D005DDBC; Tue, 25 Feb 2003 12:10:16 -0500 (EST) Delivered-To: idr@merit.edu Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id E8BAF5DD9D for ; Tue, 25 Feb 2003 12:10:15 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18niaj-000PA4-00; Tue, 25 Feb 2003 09:10:05 -0800 Date: Tue, 25 Feb 2003 09:09:41 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <92128389073.20030225090941@psg.com> To: Curtis Villamizar Cc: Yakov Rekhter , "Susan Hares" , andrewl@xix-w.bengi.exodus.net, "Manav Bhatia" , "Enke Chen" , "Jeffrey Haas" , , Subject: Re: Next-Hop in IPv6 only environment In-Reply-To: <200302251654.LAA14107@workhorse.fictitious.org> References: <200302251654.LAA14107@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk While something like this definitely wouldn't harm the spec, I don't think it is really required--a situation where the base spec is more recent than the extensions is absolutely normal and happens quite often. A higher number of the base RFC does not mean it obsoletes the extension spec, whatever RFC number that is. Example: OSPFv2 spec: RFC2328; the demand circuit extension to it suppressing Hello's on a link: RFC1793... and no disclaimers that extensions may modify the described behavior, and no confusion :) Then again, it's a minor question. If you guys believe it's a good idea to have something like this in the text--sure. -- Alex Tuesday, February 25, 2003, 8:54:02 AM, Curtis Villamizar wrote: > In message <200302251607.h1PG7WS85809@merlot.juniper.net>, Yakov Rekhter writes > : >> > >> > My understanding from the ADs is that >> > we are completing the Base specification >> > first without any additions. >> > >> > After we have completed the 1st version of >> > the base specification, I believe the ADs >> > will re-open the charter to these additions. >> > It is my understanding that we will deal >> > with IPv6 issues after this point. >> > >> > Yakov, Bill and Alex - am I correct? >> >> I think that adding the text suggested by Andrew would be fine. >> >> Yakov. > A worthwhile clarification since it keeps coming up on the list. I > agree that it is worth adding Andrew's text either to the front or as > an additional "Protocol Extensions" appendix at the very end. > Curtis >> > If there is confusion on this issue, I would suggest we add a statement >> > like this: >> > >> > This document specifies the base behavior of the BGP protocol. This >> > behavior can and is modified by extention specifications. When the >> > protocol is extended the new behavior is fully documented in the >> > extention specifications. >> > >> > to the beginning of the document somewhere. >> > >> > Andrew 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 LAA09603 for ; Tue, 25 Feb 2003 11:55:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B525E91267; Tue, 25 Feb 2003 11:55:04 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C66B91269; Tue, 25 Feb 2003 11:55: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 1968391267 for ; Tue, 25 Feb 2003 11:55:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1C8B85DE6F; Tue, 25 Feb 2003 11:55:02 -0500 (EST) Delivered-To: idr@merit.edu Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 6AE6F5DDBC for ; Tue, 25 Feb 2003 11:55:00 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA14107; Tue, 25 Feb 2003 11:54:02 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302251654.LAA14107@workhorse.fictitious.org> To: Yakov Rekhter Cc: "Susan Hares" , andrewl@xix-w.bengi.exodus.net, "Manav Bhatia" , "Enke Chen" , "Jeffrey Haas" , mjh@icir.org, idr@merit.edu Reply-To: curtis@fictitious.org Subject: Re: Next-Hop in IPv6 only environment In-reply-to: Your message of "Tue, 25 Feb 2003 08:07:32 PST." <200302251607.h1PG7WS85809@merlot.juniper.net> Date: Tue, 25 Feb 2003 11:54:02 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <200302251607.h1PG7WS85809@merlot.juniper.net>, Yakov Rekhter writes : > > > > My understanding from the ADs is that > > we are completing the Base specification > > first without any additions. > > > > After we have completed the 1st version of > > the base specification, I believe the ADs > > will re-open the charter to these additions. > > It is my understanding that we will deal > > with IPv6 issues after this point. > > > > Yakov, Bill and Alex - am I correct? > > I think that adding the text suggested by Andrew would be fine. > > Yakov. A worthwhile clarification since it keeps coming up on the list. I agree that it is worth adding Andrew's text either to the front or as an additional "Protocol Extensions" appendix at the very end. Curtis > > If there is confusion on this issue, I would suggest we add a statement > > like this: > > > > This document specifies the base behavior of the BGP protocol. This > > behavior can and is modified by extention specifications. When the > > protocol is extended the new behavior is fully documented in the > > extention specifications. > > > > to the beginning of the document somewhere. > > > > Andrew 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 LAA08789 for ; Tue, 25 Feb 2003 11:30:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 727DD91262; Tue, 25 Feb 2003 11:29:51 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4026591267; Tue, 25 Feb 2003 11:29: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 29FBF91262 for ; Tue, 25 Feb 2003 11:29:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0416F5E1F4; Tue, 25 Feb 2003 11:29:50 -0500 (EST) Delivered-To: idr@merit.edu Received: from nomad.tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by segue.merit.edu (Postfix) with ESMTP id C93585DD9D for ; Tue, 25 Feb 2003 11:29:49 -0500 (EST) Received: by nomad.tcb.net (Postfix, from userid 500) id C0D1155F62; Tue, 25 Feb 2003 09:30:22 -0700 (MST) Received: from nomad.tcb.net (localhost [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id BE1E23E83 for ; Tue, 25 Feb 2003 09:30:22 -0700 (MST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: MED in practise Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Feb 2003 09:30:17 -0700 Message-Id: <20030225163022.C0D1155F62@nomad.tcb.net> Sender: owner-idr@merit.edu Precedence: bulk > This is a little unclear to me ... AFAIK till some time IS-IS would > only support narrow metrics (the WIDE metrics extensions just came about > some time back!). This way the MED advertised by an AS running IS-IS > would always be smaller than one running OSPF .. which would > cause the upstream ISP to always select the AS running IS-IS. > > This is rather unfair for an ISP running OSPF in its network !!! > (Atleast in theory!) Indeed. Of benefit or unfair, depending on where you sit. > > I've seen MEDs work as prescribed in many scenarios. However, be wary: > > > > o aggregation breaks MEDs > > How? Can you give me one example? Many service providers only announce their aggregates from redundantly- connected core routers in order to avoid blackholing traffic (e.g., if an edge were announcing them and became isolated). The announcements for the aggregates are often sourced from many (or even all) core routers, so the metric that's used to derive the MED value is the IGP cost from the edge to the local core router, and is often a fixed value between all edge-core connections. Peers then employ the MED associated with the aggregate to reach some specific network within the aggregate. This can result in making bad routing decisions that without MED would have been much more optimal. It'd work OK if the more specifics and MEDs associated associated with internal NEXT_HOPS were made available to the peer, but this isn't a viable alternative. > Is this coz some IGP cost would change and we would re-advertise > our BGP Updates with that new MED i.e. if we are directly importing > IGP costs into BGP as MED! Isnt it? Yes, so link flaps, new metrics, etc.. that would otherwise remain internal now result in new external BGP updates, per "dynamically derived" MEDs. -danny 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 LAA08108 for ; Tue, 25 Feb 2003 11:08:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F0AB09125E; Tue, 25 Feb 2003 11:07:54 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE5A791262; Tue, 25 Feb 2003 11:07: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 50DE39125E for ; Tue, 25 Feb 2003 11:07:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C73A5DE0D; Tue, 25 Feb 2003 11:07:52 -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 BF4E85DDA7 for ; Tue, 25 Feb 2003 11:07:51 -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 h1PG7WS85809; Tue, 25 Feb 2003 08:07:32 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200302251607.h1PG7WS85809@merlot.juniper.net> To: "Susan Hares" Cc: andrewl@xix-w.bengi.exodus.net, "Manav Bhatia" , "Enke Chen" , "Jeffrey Haas" , mjh@icir.org, idr@merit.edu Subject: Re: Next-Hop in IPv6 only environment In-Reply-To: Your message of "Mon, 24 Feb 2003 14:01:14 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22419.1046189252.1@juniper.net> Date: Tue, 25 Feb 2003 08:07:32 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Sue, > Andrew: > > My understanding from the ADs is that > we are completing the Base specification > first without any additions. > > After we have completed the 1st version of > the base specification, I believe the ADs > will re-open the charter to these additions. > It is my understanding that we will deal > with IPv6 issues after this point. > > Yakov, Bill and Alex - am I correct? I think that adding the text suggested by Andrew would be fine. Yakov. > > Sue Hares > > -----Original Message----- > From: andrewl@xix-w.bengi.exodus.net > [mailto:andrewl@xix-w.bengi.exodus.net] > Sent: Saturday, February 22, 2003 6:28 PM > To: Manav Bhatia > Cc: Enke Chen; Jeffrey Haas; mjh@icir.org; idr@merit.edu > Subject: Re: Next-Hop in IPv6 only environment > > > Going through the entire base spec and adding a caveat in every place where > an extention document modifies it, is almost as much work as documenting all the > varriant behavior in the base spec. > > If there is confusion on this issue, I would suggest we add a statement > like this: > > This document specifies the base behavior of the BGP protocol. This > behavior can and is modified by extention specifications. When the > protocol is extended the new behavior is fully documented in the > extention specifications. > > to the beginning of the document somewhere. > > Andrew > > On Fri, Feb 14, 2003 at 10:28:55AM +0530, Manav Bhatia wrote: > > Delivered-To: idr-outgoing@trapdoor.merit.edu > > Delivered-To: idr@trapdoor.merit.edu > > Delivered-To: idr@merit.edu > > Date: Fri, 14 Feb 2003 10:28:55 +0530 > > From: Manav Bhatia > > Subject: Re: Next-Hop in IPv6 only environment > > To: Enke Chen > > Cc: Jeffrey Haas , mjh@icir.org, idr@merit.edu > > Reply-To: Manav Bhatia > > X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 > > X-Mailer: Microsoft Outlook Express 6.00.2720.3000 > > X-Priority: 3 > > X-MSMail-priority: Normal > > Precedence: bulk > > X-Spam-Status: No, hits=0.1 required=5.0 > > tests=AWL,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, > > USER_AGENT_OE > > version=2.43 > > X-OriginalArrivalTime: 14 Feb 2003 04:59:52.0087 (UTC) FILETIME=[E876DA70:0 1C2D3E5] > > > > Enke, > > > > > An UPDATE message that carries no NLRI, other than the one encoded in > > > the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute. > > > If such a message contains the NEXT_HOP attribute, the BGP speaker > > > that receives the message should ignore this attribute. > > > > Yes it indeed is. > > > > However it would be really nice if a similar thing is mentioned somewhere > > in the base spec too OR once again, a pointer to the fact that NEXT_HOP > > attribute is not always *mandatory* is mentioned to remove any later > > confusions amongst the implementers. > > > > I have a gut feeling that this issue will crop up again some time later > > down the line. The confusion will be all the more aggravated when your base > > spec RFC is greater than your extensions RFC nos. > > > > Thanks, > > Manav > > > > P.S. > > Once again, the issue isn't that RFC 2858 isn't clear .. its just that it > > defies what the base spec mandates any implementation to do! > > > > It just gets all the more skewed when the base spec is more recent than the > > extensions draft/RFC! > > :-) 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 JAA04477 for ; Tue, 25 Feb 2003 09:22:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2EFAC91249; Tue, 25 Feb 2003 09:22:35 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EAA0A9124D; Tue, 25 Feb 2003 09:22:34 -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 BC28391249 for ; Tue, 25 Feb 2003 09:22:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8F7AE5DFA5; Tue, 25 Feb 2003 09:22:33 -0500 (EST) Delivered-To: idr@merit.edu Received: from web20309.mail.yahoo.com (web20309.mail.yahoo.com [216.136.226.90]) by segue.merit.edu (Postfix) with SMTP id F35805DF4A for ; Tue, 25 Feb 2003 09:22:32 -0500 (EST) Message-ID: <20030225142232.50072.qmail@web20309.mail.yahoo.com> Received: from [203.200.20.226] by web20309.mail.yahoo.com via HTTP; Tue, 25 Feb 2003 06:22:32 PST Date: Tue, 25 Feb 2003 06:22:32 -0800 (PST) From: Mareline Sheldon Subject: Re: MED in practise To: idr@merit.edu Cc: danny@tcb.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Danny, > If you replace "destination" with NEXT_HOP, sure... I'm sorry .. that is what i had meant ! > > > If this is done then the ISP which is connected to two other ISPs > > can decide amongst the better one by choosing the lower MED advertised > > by both and sending all the traffic through it! > > Sure, and thereby always selecting the ISP with the metric allocation > policy that results in lower values for IGP metrics. Or, perhaps always > selecting the ISP with the IGP that provides a smaller range of available > metrics (e.g., IS-IS pre-deployment/"wide metrics"). This is a little unclear to me ... AFAIK till some time IS-IS would only support narrow metrics (the WIDE metrics extensions just came about some time back!). This way the MED advertised by an AS running IS-IS would always be smaller than one running OSPF .. which would cause the upstream ISP to always select the AS running IS-IS. This is rather unfair for an ISP running OSPF in its network !!! (Atleast in theory!) > I've seen MEDs work as prescribed in many scenarios. However, be wary: > > o aggregation breaks MEDs How? Can you give me one example? > o comparing MEDs between different ASs with different policies > isn't typically a good idea > o MEDs are a primary trigger of route oscillation > o MEDs often result in superfluous route advertisements per > IGP link/node/cost changes Is this coz some IGP cost would change and we would re-advertise our BGP Updates with that new MED i.e. if we are directly importing IGP costs into BGP as MED! Isnt it? > o Most notably, accepting MEDs from peers can have a visible impact on the > economics of carrying bits, depending on which network is carrying traffic, > how far, etc.. > > Also note that while many service providers send (often by request only) and > accept MEDs from customers, they typically reset MEDs to some fixed value on > routes learned from peers. This would solve most of the problems !! Thanks a lot! Mareline S. __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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 PAA00302 for ; Mon, 24 Feb 2003 15:46:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 86AF29124B; Mon, 24 Feb 2003 15:46:20 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 39EDA9124F; Mon, 24 Feb 2003 15:46: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 B94C09124B for ; Mon, 24 Feb 2003 15:46:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 17DCF5E00F; Mon, 24 Feb 2003 15:46:01 -0500 (EST) Delivered-To: idr@merit.edu Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id AA76B5DE5B for ; Mon, 24 Feb 2003 15:45:57 -0500 (EST) Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id MAA24068; Mon, 24 Feb 2003 12:42:40 -0800 (PST) Date: Mon, 24 Feb 2003 12:42:40 -0800 From: andrewl@xix-w.bengi.exodus.net To: Susan Hares Cc: Manav Bhatia , Enke Chen , Jeffrey Haas , mjh@icir.org, idr@merit.edu Subject: Re: Next-Hop in IPv6 only environment Message-ID: <20030224124240.E5760@demiurge.exodus.net> 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 shares@nexthop.com on Mon, Feb 24, 2003 at 02:01:14PM -0500 Sender: owner-idr@merit.edu Precedence: bulk Sue, The paragaph below would be part of the base spec. I don't think it would violate the charter, since it would basically say "if you are interested in bgp foo, look in the bgp foo document, since bgp foo is beyond the scope of this document". However, I certainly do NOT want to hold up the process. I proposed that text because there was some indication on the list that it was not clear how the BGP specifications interrelated. I was trying to take the view of someone who was not a list veteren and was reading the BGP documents for the first time. If you, as the document editor, feel that this is not necessary, I'm happy to defer to your editorial judgement on this. Andrew > Andrew: > > My understanding from the ADs is that > we are completing the Base specification > first without any additions. > > After we have completed the 1st version of > the base specification, I believe the ADs > will re-open the charter to these additions. > It is my understanding that we will deal > with IPv6 issues after this point. > > Yakov, Bill and Alex - am I correct? > > Sue Hares > > -----Original Message----- > From: andrewl@xix-w.bengi.exodus.net > [mailto:andrewl@xix-w.bengi.exodus.net] > Sent: Saturday, February 22, 2003 6:28 PM > To: Manav Bhatia > Cc: Enke Chen; Jeffrey Haas; mjh@icir.org; idr@merit.edu > Subject: Re: Next-Hop in IPv6 only environment > > > Going through the entire base spec and adding a caveat in every place where > an extention document modifies it, is almost as much work as documenting all the > varriant behavior in the base spec. > > If there is confusion on this issue, I would suggest we add a statement > like this: > > This document specifies the base behavior of the BGP protocol. This > behavior can and is modified by extention specifications. When the > protocol is extended the new behavior is fully documented in the > extention specifications. > > to the beginning of the document somewhere. > > Andrew > > On Fri, Feb 14, 2003 at 10:28:55AM +0530, Manav Bhatia wrote: > > Delivered-To: idr-outgoing@trapdoor.merit.edu > > Delivered-To: idr@trapdoor.merit.edu > > Delivered-To: idr@merit.edu > > Date: Fri, 14 Feb 2003 10:28:55 +0530 > > From: Manav Bhatia > > Subject: Re: Next-Hop in IPv6 only environment > > To: Enke Chen > > Cc: Jeffrey Haas , mjh@icir.org, idr@merit.edu > > Reply-To: Manav Bhatia > > X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 > > X-Mailer: Microsoft Outlook Express 6.00.2720.3000 > > X-Priority: 3 > > X-MSMail-priority: Normal > > Precedence: bulk > > X-Spam-Status: No, hits=0.1 required=5.0 > > tests=AWL,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, > > USER_AGENT_OE > > version=2.43 > > X-OriginalArrivalTime: 14 Feb 2003 04:59:52.0087 (UTC) FILETIME=[E876DA70:01C2D3E5] > > > > Enke, > > > > > An UPDATE message that carries no NLRI, other than the one encoded in > > > the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute. > > > If such a message contains the NEXT_HOP attribute, the BGP speaker > > > that receives the message should ignore this attribute. > > > > Yes it indeed is. > > > > However it would be really nice if a similar thing is mentioned somewhere > > in the base spec too OR once again, a pointer to the fact that NEXT_HOP > > attribute is not always *mandatory* is mentioned to remove any later > > confusions amongst the implementers. > > > > I have a gut feeling that this issue will crop up again some time later > > down the line. The confusion will be all the more aggravated when your base > > spec RFC is greater than your extensions RFC nos. > > > > Thanks, > > Manav > > > > P.S. > > Once again, the issue isn't that RFC 2858 isn't clear .. its just that it > > defies what the base spec mandates any implementation to do! > > > > It just gets all the more skewed when the base spec is more recent than the > > extensions draft/RFC! > > :-) 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 OAA26905 for ; Mon, 24 Feb 2003 14:04:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B7E7291238; Mon, 24 Feb 2003 14:01:54 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7380591239; Mon, 24 Feb 2003 14:01: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 D483291238 for ; Mon, 24 Feb 2003 14:01:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3DBE35DFB6; Mon, 24 Feb 2003 14:01:36 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 6AFCE5DDA5 for ; Mon, 24 Feb 2003 14:01:31 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1OJ1Sj38069 for idr@merit.edu; Mon, 24 Feb 2003 14:01:28 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id h1OJ1EC38031 for ; Mon, 24 Feb 2003 14:01:14 -0500 (EST) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Next-Hop in IPv6 only environment X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 24 Feb 2003 14:01:14 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Next-Hop in IPv6 only environment Thread-Index: AcLayu40m+zK+fM2QZi3lCnF4s0QuABa+S3w From: "Susan Hares" To: , "Manav Bhatia" Cc: "Enke Chen" , "Jeffrey Haas" , , X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id OAA26905 Andrew: My understanding from the ADs is that we are completing the Base specification first without any additions. After we have completed the 1st version of the base specification, I believe the ADs will re-open the charter to these additions. It is my understanding that we will deal with IPv6 issues after this point. Yakov, Bill and Alex - am I correct? Sue Hares -----Original Message----- From: andrewl@xix-w.bengi.exodus.net [mailto:andrewl@xix-w.bengi.exodus.net] Sent: Saturday, February 22, 2003 6:28 PM To: Manav Bhatia Cc: Enke Chen; Jeffrey Haas; mjh@icir.org; idr@merit.edu Subject: Re: Next-Hop in IPv6 only environment Going through the entire base spec and adding a caveat in every place where an extention document modifies it, is almost as much work as documenting all the varriant behavior in the base spec. If there is confusion on this issue, I would suggest we add a statement like this: This document specifies the base behavior of the BGP protocol. This behavior can and is modified by extention specifications. When the protocol is extended the new behavior is fully documented in the extention specifications. to the beginning of the document somewhere. Andrew On Fri, Feb 14, 2003 at 10:28:55AM +0530, Manav Bhatia wrote: > Delivered-To: idr-outgoing@trapdoor.merit.edu > Delivered-To: idr@trapdoor.merit.edu > Delivered-To: idr@merit.edu > Date: Fri, 14 Feb 2003 10:28:55 +0530 > From: Manav Bhatia > Subject: Re: Next-Hop in IPv6 only environment > To: Enke Chen > Cc: Jeffrey Haas , mjh@icir.org, idr@merit.edu > Reply-To: Manav Bhatia > X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 > X-Mailer: Microsoft Outlook Express 6.00.2720.3000 > X-Priority: 3 > X-MSMail-priority: Normal > Precedence: bulk > X-Spam-Status: No, hits=0.1 required=5.0 > tests=AWL,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, > USER_AGENT_OE > version=2.43 > X-OriginalArrivalTime: 14 Feb 2003 04:59:52.0087 (UTC) FILETIME=[E876DA70:01C2D3E5] > > Enke, > > > An UPDATE message that carries no NLRI, other than the one encoded in > > the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute. > > If such a message contains the NEXT_HOP attribute, the BGP speaker > > that receives the message should ignore this attribute. > > Yes it indeed is. > > However it would be really nice if a similar thing is mentioned somewhere > in the base spec too OR once again, a pointer to the fact that NEXT_HOP > attribute is not always *mandatory* is mentioned to remove any later > confusions amongst the implementers. > > I have a gut feeling that this issue will crop up again some time later > down the line. The confusion will be all the more aggravated when your base > spec RFC is greater than your extensions RFC nos. > > Thanks, > Manav > > P.S. > Once again, the issue isn't that RFC 2858 isn't clear .. its just that it > defies what the base spec mandates any implementation to do! > > It just gets all the more skewed when the base spec is more recent than the > extensions draft/RFC! > :-) 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 KAA19058 for ; Mon, 24 Feb 2003 10:06:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3E77791248; Mon, 24 Feb 2003 10:05:50 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B787391244; Mon, 24 Feb 2003 10:05: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 0118A91247 for ; Mon, 24 Feb 2003 10:05:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id DF1745DFC1; Mon, 24 Feb 2003 10:05:43 -0500 (EST) Delivered-To: idr@merit.edu Received: from nomad.tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by segue.merit.edu (Postfix) with ESMTP id A3EC75DFB4 for ; Mon, 24 Feb 2003 10:05:43 -0500 (EST) Received: by nomad.tcb.net (Postfix, from userid 500) id 6FBD855F62; Mon, 24 Feb 2003 08:06:05 -0700 (MST) Received: from nomad.tcb.net (localhost [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id 6B6493E83 for ; Mon, 24 Feb 2003 08:06:05 -0700 (MST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: MED in practise Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Feb 2003 08:06:00 -0700 Message-Id: <20030224150605.6FBD855F62@nomad.tcb.net> Sender: owner-idr@merit.edu Precedence: bulk > I want to know if this is a general practise followed by the > ISPs to advertise in their MED thier internal IGP costs to reach > the destination to their upstream peers. If you replace "destination" with NEXT_HOP, sure... > If this is done then the ISP which is connected to two other ISPs > can decide amongst the better one by choosing the lower MED advertised > by both and sending all the traffic through it! Sure, and thereby always selecting the ISP with the metric allocation policy that results in lower values for IGP metrics. Or, perhaps always selecting the ISP with the IGP that provides a smaller range of available metrics (e.g., IS-IS pre-deployment/"wide metrics"). > On the other hand, if we have the option to compare MEDs only from the > same AS then i can use MED to choose a lesser congested link. Sure, as with many other BGP attributes, if you manually configure MEDs or employ some dynamic router configuration technique (to configure MEDs). > Is this how MED is set or is some other logic followed? And finally > why is MED considered so fatal and there were talks sometime back to > get rid of it. I've seen MEDs work as prescribed in many scenarios. However, be wary: o aggregation breaks MEDs o comparing MEDs between different ASs with different policies isn't typically a good idea o MEDs are a primary trigger of route oscillation o MEDs often result in superfluous route advertisements per IGP link/node/cost changes o Most notably, accepting MEDs from peers can have a visible impact on the economics of carrying bits, depending on which network is carrying traffic, how far, etc.. Also note that while many service providers send (often by request only) and accept MEDs from customers, they typically reset MEDs to some fixed value on routes learned from peers. -danny 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 JAA18187 for ; Mon, 24 Feb 2003 09:38:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8BADD9123E; Mon, 24 Feb 2003 09:38:23 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5570791240; Mon, 24 Feb 2003 09:38:23 -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 577179123E for ; Mon, 24 Feb 2003 09:38:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3DD775DFB4; Mon, 24 Feb 2003 09:38:22 -0500 (EST) Delivered-To: idr@merit.edu Received: from nomad.tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by segue.merit.edu (Postfix) with ESMTP id 10A0A5DE4E for ; Mon, 24 Feb 2003 09:38:22 -0500 (EST) Received: by nomad.tcb.net (Postfix, from userid 500) id 74E4755F62; Mon, 24 Feb 2003 07:38:53 -0700 (MST) Received: from nomad.tcb.net (localhost [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id 73FE23E83 for ; Mon, 24 Feb 2003 07:38:53 -0700 (MST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: ORIGINATOR_ID in Route Reflectors Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Feb 2003 07:38:48 -0700 Message-Id: <20030224143853.74E4755F62@nomad.tcb.net> Sender: owner-idr@merit.edu Precedence: bulk > If a RR Client sends an UPDATE without an ORIGINATOR_ID attribute, what is > the value of the ORIGINATOR_ID that the RR should use, before advertising > the UPDATE to its RR peers? Should it be its own Router ID or the RR > client's (which sent the UPDATE) Router ID? Note that an RR client does NOT add the ORIGINATOR_ID attribute, it's added by the route reflector and set to the ROTUER_ID of the client. This initially provided the ability for deployments where a client didn't need to know it was a client. However, RFC 2796 changed things slightly (perhaps in order to accommodate implementations where for performance purposes the RR reflected routes learned from a client back to that client) by requiring that clients "ignore" received routes if the ORIGINATOR_ID is equal to the local ROUTER_ID. In addition to adding the ORIGINATOR_ID attribute to the route, the RR also creates a CLUSTER_LIST and places the local CLUSTER_ID value (which is by default usually the RR's ROUTER_ID or otherwise some explicitly configured value) in the list. RFC 2796 is clear about these behaviors. -danny 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 EAA09725 for ; Mon, 24 Feb 2003 04:39:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 57DC291221; Mon, 24 Feb 2003 04:38:35 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1DA2E91237; Mon, 24 Feb 2003 04:38:35 -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 BE74D91221 for ; Mon, 24 Feb 2003 04:38:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9F8DC5DF78; Mon, 24 Feb 2003 04:38:33 -0500 (EST) Delivered-To: idr@merit.edu Received: from ganesh.ctd.hctech.com (Ganesh.hcltech.com [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id 495F25DE0F for ; Mon, 24 Feb 2003 04:38:32 -0500 (EST) Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Feb 2003 15:08:29 +0530 Message-ID: <60F922ABE8BE9C428E806F43C0EC7368066BA9@HARITHA> From: "Sivananda Ramnath - CTD, Chennai." To: Susan Hares Cc: idr@merit.edu Subject: RE: Issue 24 Date: Mon, 24 Feb 2003 15:08:25 +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 Hello, Agreed. We can consider this issue closed without any changes to the text. Siva (siva@ctd.hcltech.com) > -----Original Message----- > From: Susan Hares [mailto:shares@nexthop.com] > Sent: Thursday, February 20, 2003 11:07 PM > To: Sivananda Ramnath - CTD, Chennai. > Cc: idr@merit.edu > Subject: Issue 24 > > > Siva: > > Issue 24 was holding on some comments from the mail > group on adding examples to events 3,4 and 6. > > I'm going to leave the examples out of events 3, 4, 6 since > I've not heard any strong input on the mail list **and** > I had strong comments on prior versions of the draft. > > I'd like to declare that issue 24 has consensus. > Will you agree to this? > > Sue > 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 CAA05508 for ; Mon, 24 Feb 2003 02:20:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4A0CF9122B; Mon, 24 Feb 2003 02:19:44 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 910B891235; Mon, 24 Feb 2003 02:19: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 58B1A9122B for ; Mon, 24 Feb 2003 02:19:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4512C5DDF2; Mon, 24 Feb 2003 02:19:39 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailout3.samsung.com (unknown [203.254.224.33]) by segue.merit.edu (Postfix) with ESMTP id E78015DDA4 for ; Mon, 24 Feb 2003 02:19:38 -0500 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HAS00E01XMVDQ@mailout3.samsung.com> for idr@merit.edu; Mon, 24 Feb 2003 16:18:31 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HAS0060CXMV6M@mailout3.samsung.com> for idr@merit.edu; Mon, 24 Feb 2003 16:18:31 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HAS00IV2YADKV@mmp2.samsung.com> for idr@merit.edu; Mon, 24 Feb 2003 16:32:40 +0900 (KST) Date: Mon, 24 Feb 2003 12:48:36 +0530 From: Manav Bhatia Subject: Re: ORIGINATOR_ID in Route Reflectors To: anandn@future.futsoft.com, idr@merit.edu Reply-To: Manav Bhatia Message-id: <033d01c2dbd4$f3bf37a0$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <002c01c2dbd3$aef6fdc0$2204060a@future.futsoft.com> Sender: owner-idr@merit.edu Precedence: bulk Anand, The RR should use the RID of the client which sent the UPDATE. - Manav ----- Original Message ----- From: "Anand Nagarajan" To: Sent: Monday, February 24, 2003 12:39 PM Subject: ORIGINATOR_ID in Route Reflectors > > If a RR Client sends an UPDATE without an ORIGINATOR_ID attribute, what is > the value of the ORIGINATOR_ID that the RR should use, before advertising > the UPDATE to its RR peers? Should it be its own Router ID or the RR > client's (which sent the UPDATE) Router ID? > > TIA > - Anand Nagarajan > -- Say what you do and Do what you say -- > 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 CAA05239 for ; Mon, 24 Feb 2003 02:12:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 751E59120C; Mon, 24 Feb 2003 02:12:13 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D1A291227; Mon, 24 Feb 2003 02:12: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 EDFD99120C for ; Mon, 24 Feb 2003 02:12:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id CFB965DEFF; Mon, 24 Feb 2003 02:12:11 -0500 (EST) Delivered-To: idr@merit.edu Received: from fsnt.future.futsoft.com (unknown [203.197.140.35]) by segue.merit.edu (Postfix) with ESMTP id 0697F5DDA4 for ; Mon, 24 Feb 2003 02:12:10 -0500 (EST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 24 Feb 2003 12:48:34 +0530 Received: from anandn (anandn.future.futsoft.com [10.6.4.34]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h1O79cxj005020 for ; Mon, 24 Feb 2003 12:39:38 +0530 Reply-To: From: "Anand Nagarajan" To: Subject: ORIGINATOR_ID in Route Reflectors Date: Mon, 24 Feb 2003 12:39:32 +0530 Message-Id: <002c01c2dbd3$aef6fdc0$2204060a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk If a RR Client sends an UPDATE without an ORIGINATOR_ID attribute, what is the value of the ORIGINATOR_ID that the RR should use, before advertising the UPDATE to its RR peers? Should it be its own Router ID or the RR client's (which sent the UPDATE) Router ID? TIA - Anand Nagarajan -- Say what you do and Do what you say -- *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** 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 BAA02923 for ; Mon, 24 Feb 2003 01:00:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E2A3491226; Mon, 24 Feb 2003 00:50:28 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 295F691302; Mon, 24 Feb 2003 00:50:08 -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 C5DCC91304 for ; Mon, 24 Feb 2003 00:48:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id B68D35DF34; Mon, 24 Feb 2003 00:48:10 -0500 (EST) Delivered-To: idr@merit.edu Received: from web20309.mail.yahoo.com (web20309.mail.yahoo.com [216.136.226.90]) by segue.merit.edu (Postfix) with SMTP id EA3565DF00 for ; Mon, 24 Feb 2003 00:48:09 -0500 (EST) Message-ID: <20030224054809.26568.qmail@web20309.mail.yahoo.com> Received: from [203.200.20.226] by web20309.mail.yahoo.com via HTTP; Sun, 23 Feb 2003 21:48:09 PST Date: Sun, 23 Feb 2003 21:48:09 -0800 (PST) From: Mareline Sheldon Subject: MED in practise To: idr@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Hello, I want to know if this is a general practise followed by the ISPs to advertise in their MED thier internal IGP costs to reach the destination to their upstream peers. If this is done then the ISP which is connected to two other ISPs can decide amongst the better one by choosing the lower MED advertised by both and sending all the traffic through it! On the other hand, if we have the option to compare MEDs only from the same AS then i can use MED to choose a lesser congested link. Is this how MED is set or is some other logic followed? And finally why is MED considered so fatal and there were talks sometime back to get rid of it. And help in this regard will be appreciated. Thanks, Mareline S. __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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 WAA26954 for ; Sun, 23 Feb 2003 22:05:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F40FC91203; Sun, 23 Feb 2003 22:04:38 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9CD891206; Sun, 23 Feb 2003 22:04: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 2FB7891203 for ; Sun, 23 Feb 2003 22:04:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 034975DF63; Sun, 23 Feb 2003 22:04:36 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailout1.samsung.com (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 9BE745DF5F for ; Sun, 23 Feb 2003 22:04:35 -0500 (EST) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HAS00I01LU6ZB@mailout1.samsung.com> for idr@merit.edu; Mon, 24 Feb 2003 12:03:42 +0900 (KST) Received: from ep_mmp2 ([127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HAS00FU2LU6HW@mailout1.samsung.com> for idr@merit.edu; Mon, 24 Feb 2003 12:03:42 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HAS00ITEMH7KV@mmp2.samsung.com> for idr@merit.edu; Mon, 24 Feb 2003 12:17:34 +0900 (KST) Date: Mon, 24 Feb 2003 08:33:31 +0530 From: Manav Bhatia Subject: Re: Next-Hop in IPv6 only environment To: andrewl@xix-w.bengi.exodus.net Cc: Enke Chen , Jeffrey Haas , mjh@icir.org, idr@merit.edu Reply-To: Manav Bhatia Message-id: <00d601c2dbb1$519e5320$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20030214044325.AE3E7979C1@popserv2.redback.com> <0c0701c2d3e5$c8bbd640$b4036c6b@sisodomain.com> <20030222152804.B5760@demiurge.exodus.net> Sender: owner-idr@merit.edu Precedence: bulk Yes .. this sounds nice .. and takes care of whatever extensions we might put in some time later .. Manav ----- Original Message ----- From: To: "Manav Bhatia" Cc: "Enke Chen" ; "Jeffrey Haas" ; ; Sent: Sunday, February 23, 2003 4:58 AM Subject: Re: Next-Hop in IPv6 only environment > Going through the entire base spec and adding a caveat in every place where > an extention document modifies it, is almost as much work as documenting all the > varriant behavior in the base spec. > > If there is confusion on this issue, I would suggest we add a statement > like this: > > This document specifies the base behavior of the BGP protocol. This > behavior can and is modified by extention specifications. When the > protocol is extended the new behavior is fully documented in the > extention specifications. > > to the beginning of the document somewhere. > > Andrew > > On Fri, Feb 14, 2003 at 10:28:55AM +0530, Manav Bhatia wrote: > > Delivered-To: idr-outgoing@trapdoor.merit.edu > > Delivered-To: idr@trapdoor.merit.edu > > Delivered-To: idr@merit.edu > > Date: Fri, 14 Feb 2003 10:28:55 +0530 > > From: Manav Bhatia > > Subject: Re: Next-Hop in IPv6 only environment > > To: Enke Chen > > Cc: Jeffrey Haas , mjh@icir.org, idr@merit.edu > > Reply-To: Manav Bhatia > > X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 > > X-Mailer: Microsoft Outlook Express 6.00.2720.3000 > > X-Priority: 3 > > X-MSMail-priority: Normal > > Precedence: bulk > > X-Spam-Status: No, hits=0.1 required=5.0 > > tests=AWL,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, > > USER_AGENT_OE > > version=2.43 > > X-OriginalArrivalTime: 14 Feb 2003 04:59:52.0087 (UTC) FILETIME=[E876DA70:01C2D3E5] > > > > Enke, > > > > > An UPDATE message that carries no NLRI, other than the one encoded in > > > the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute. > > > If such a message contains the NEXT_HOP attribute, the BGP speaker > > > that receives the message should ignore this attribute. > > > > Yes it indeed is. > > > > However it would be really nice if a similar thing is mentioned somewhere > > in the base spec too OR once again, a pointer to the fact that NEXT_HOP > > attribute is not always *mandatory* is mentioned to remove any later > > confusions amongst the implementers. > > > > I have a gut feeling that this issue will crop up again some time later > > down the line. The confusion will be all the more aggravated when your base > > spec RFC is greater than your extensions RFC nos. > > > > Thanks, > > Manav > > > > P.S. > > Once again, the issue isn't that RFC 2858 isn't clear .. its just that it > > defies what the base spec mandates any implementation to do! > > > > It just gets all the more skewed when the base spec is more recent than the > > extensions draft/RFC! > > :-) > 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 SAA18057 for ; Sat, 22 Feb 2003 18:34:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 507549121D; Sat, 22 Feb 2003 18:31:23 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 47EE0912C6; Sat, 22 Feb 2003 18:31:22 -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 079529121D for ; Sat, 22 Feb 2003 18:31:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id AD2AF5DFBF; Sat, 22 Feb 2003 18:31:17 -0500 (EST) Delivered-To: idr@merit.edu Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 40D675DF83 for ; Sat, 22 Feb 2003 18:31:17 -0500 (EST) Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id PAA21533; Sat, 22 Feb 2003 15:28:04 -0800 (PST) Date: Sat, 22 Feb 2003 15:28:04 -0800 From: andrewl@xix-w.bengi.exodus.net To: Manav Bhatia Cc: Enke Chen , Jeffrey Haas , mjh@icir.org, idr@merit.edu Subject: Re: Next-Hop in IPv6 only environment Message-ID: <20030222152804.B5760@demiurge.exodus.net> References: <20030214044325.AE3E7979C1@popserv2.redback.com> <0c0701c2d3e5$c8bbd640$b4036c6b@sisodomain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0c0701c2d3e5$c8bbd640$b4036c6b@sisodomain.com>; from manav@samsung.com on Fri, Feb 14, 2003 at 10:28:55AM +0530 Sender: owner-idr@merit.edu Precedence: bulk Going through the entire base spec and adding a caveat in every place where an extention document modifies it, is almost as much work as documenting all the varriant behavior in the base spec. If there is confusion on this issue, I would suggest we add a statement like this: This document specifies the base behavior of the BGP protocol. This behavior can and is modified by extention specifications. When the protocol is extended the new behavior is fully documented in the extention specifications. to the beginning of the document somewhere. Andrew On Fri, Feb 14, 2003 at 10:28:55AM +0530, Manav Bhatia wrote: > Delivered-To: idr-outgoing@trapdoor.merit.edu > Delivered-To: idr@trapdoor.merit.edu > Delivered-To: idr@merit.edu > Date: Fri, 14 Feb 2003 10:28:55 +0530 > From: Manav Bhatia > Subject: Re: Next-Hop in IPv6 only environment > To: Enke Chen > Cc: Jeffrey Haas , mjh@icir.org, idr@merit.edu > Reply-To: Manav Bhatia > X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 > X-Mailer: Microsoft Outlook Express 6.00.2720.3000 > X-Priority: 3 > X-MSMail-priority: Normal > Precedence: bulk > X-Spam-Status: No, hits=0.1 required=5.0 > tests=AWL,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, > USER_AGENT_OE > version=2.43 > X-OriginalArrivalTime: 14 Feb 2003 04:59:52.0087 (UTC) FILETIME=[E876DA70:01C2D3E5] > > Enke, > > > An UPDATE message that carries no NLRI, other than the one encoded in > > the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute. > > If such a message contains the NEXT_HOP attribute, the BGP speaker > > that receives the message should ignore this attribute. > > Yes it indeed is. > > However it would be really nice if a similar thing is mentioned somewhere > in the base spec too OR once again, a pointer to the fact that NEXT_HOP > attribute is not always *mandatory* is mentioned to remove any later > confusions amongst the implementers. > > I have a gut feeling that this issue will crop up again some time later > down the line. The confusion will be all the more aggravated when your base > spec RFC is greater than your extensions RFC nos. > > Thanks, > Manav > > P.S. > Once again, the issue isn't that RFC 2858 isn't clear .. its just that it > defies what the base spec mandates any implementation to do! > > It just gets all the more skewed when the base spec is more recent than the > extensions draft/RFC! > :-) 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 NAA14268 for ; Thu, 20 Feb 2003 13:30:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9415B91282; Thu, 20 Feb 2003 13:29:55 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F99F91285; Thu, 20 Feb 2003 13:29:55 -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 0891191282 for ; Thu, 20 Feb 2003 13:29:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id E0F4F5E069; Thu, 20 Feb 2003 13:29:53 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 6EB765DDA6 for ; Thu, 20 Feb 2003 13:29:53 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1KITqO51797 for idr@merit.edu; Thu, 20 Feb 2003 13:29:52 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id h1KITgC51772 for ; Thu, 20 Feb 2003 13:29:42 -0500 (EST) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Issue 42 - Siva's comments X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 20 Feb 2003 13:29:42 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 42 - Siva's comments Thread-Index: AcLZDgi2iCdu8SFIRb+ueJFmDizeFQ== From: "Susan Hares" To: "Sivananda Ramnath - CTD, Chennai." Cc: "Tom Petch" , , X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id NAA14268 Tom and Siva: Here's the comments from Siva on issue 42. I'll send comments next. siva's comments. ============= ++ Issue 42 ++ Issue I am unclear as to what is the way to proceed here. Is there consensus that a NOTIFICATION message does need to be sent ? ++ Issue 42 ++ > The issue is what if Connect state occurs and there is not > a TCP connection. Should an OPEN with wrong version > be accepted? If the Open Delay flag is off, the connection > state should not be getting an Open. The "D" action below > works for "open delay flag off". > > The "y" action you suggest can occur if the open delay > timer is on. > > If this is the issue, please confirm. > We could say: if open delay flag is on -> y action > if open delay flag is off -> D action Yes, this is the issue, and the text you have suggested looks good. If this is OK, can we close the issue ? Sivanand (siva@ctd.hcltech.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 MAA12950 for ; Thu, 20 Feb 2003 12:44:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C1EEB9127E; Thu, 20 Feb 2003 12:43:58 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 97AD491280; Thu, 20 Feb 2003 12:43:58 -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 4CBED9127E for ; Thu, 20 Feb 2003 12:43:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2A0885DDFC; Thu, 20 Feb 2003 12:43:57 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 737EE5DDAE for ; Thu, 20 Feb 2003 12:43:56 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1KHhta49950 for idr@merit.edu; Thu, 20 Feb 2003 12:43:55 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id h1KHhgC49913 for ; Thu, 20 Feb 2003 12:43:42 -0500 (EST) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Issue 41 - consensus reached X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 20 Feb 2003 12:43:42 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 41 - consensus reached Thread-Index: AcLZB5uedFO6BtIcSKuK1oOlBHY7UA== From: "Susan Hares" To: "Sivananda Ramnath - CTD, Chennai." Cc: , , X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id MAA12950 Siva: thanks for the note on issue 41. We'll consider it closed Sue ============ Siva's note: ++ Issue 41 ++ > Sue proposed: > > My resolution: Let event 14 be optional. > Not all BGP implementations support it. This issue is still marked as open. What you are saying is fine, so I guess we can move this to consensus. 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 MAA12703 for ; Thu, 20 Feb 2003 12:37:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2772091253; Thu, 20 Feb 2003 12:36:45 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E326D9127E; Thu, 20 Feb 2003 12:36:44 -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 89FA691253 for ; Thu, 20 Feb 2003 12:36:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 71A0C5DF77; Thu, 20 Feb 2003 12:36:43 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id CAD285DF32 for ; Thu, 20 Feb 2003 12:36:42 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1KHafb49654 for idr@merit.edu; Thu, 20 Feb 2003 12:36:41 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id h1KHaZC49640 for ; Thu, 20 Feb 2003 12:36:35 -0500 (EST) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Issue 24 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 20 Feb 2003 12:36:35 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 24 Thread-Index: AcLZBp2c8XuTGTVLSna74g5sxw+uIw== From: "Susan Hares" To: "Sivananda Ramnath - CTD, Chennai." Cc: X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id MAA12703 Siva: Issue 24 was holding on some comments from the mail group on adding examples to events 3,4 and 6. I'm going to leave the examples out of events 3, 4, 6 since I've not heard any strong input on the mail list **and** I had strong comments on prior versions of the draft. I'd like to declare that issue 24 has consensus. Will you agree to this? Sue 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 LAA10488 for ; Thu, 20 Feb 2003 11:19:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DBC2F91278; Thu, 20 Feb 2003 11:18:50 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A144991279; Thu, 20 Feb 2003 11:18: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 503DF91278 for ; Thu, 20 Feb 2003 11:18:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3BC3A5DECD; Thu, 20 Feb 2003 11:18:49 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 8ADE75DDBC for ; Thu, 20 Feb 2003 11:18:48 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1KGIlb46065 for idr@merit.edu; Thu, 20 Feb 2003 11:18:47 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id h1KGIfC46051 for ; Thu, 20 Feb 2003 11:18:41 -0500 (EST) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Issue 33 - Clarification X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 20 Feb 2003 11:18:41 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 33 - Clarification Thread-Index: AcLY+7syroC6pgynRHCMqI10EYgiLQ== From: "Susan Hares" To: "Sivananda Ramnath - CTD, Chennai." Cc: X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id LAA10488 Siva: I would like to keep the current text of "Should" in the following text "BGP's destination port SHOULD be port 179 as defined by IANA." Should indicates that it normally should be 179. If an implementation allows for an alternative TCP port, it is still valid as the "MUST" is not indicated. Sue Siva's comment ========================= ++ Issue 33 ++ > I propose that we remove any mention of valid destination TCP port. > > Since BGP will not be listening on this 'invalid' port on which the > connection request was received, it will be handled by the system's > TCP stack, and not communicated as an event to BGP. That was my last comment on this issue. Is this OK, or am I missing something here ? 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 LAA10049 for ; Thu, 20 Feb 2003 11:03:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B087591272; Thu, 20 Feb 2003 11:03:27 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F3A191278; Thu, 20 Feb 2003 11:03: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 500F291272 for ; Thu, 20 Feb 2003 11:03:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 288715DF24; Thu, 20 Feb 2003 11:03:24 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 807605DDBC for ; Thu, 20 Feb 2003 11:03:23 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1KG3Mw45591 for idr@merit.edu; Thu, 20 Feb 2003 11:03:22 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id h1KG3EC45570 for ; Thu, 20 Feb 2003 11:03:14 -0500 (EST) (envelope-from shares@nexthop.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: FSM issue 26 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 20 Feb 2003 11:03:14 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on FSM Issues Thread-Index: AcLSfg2oOgKuybpgSzG7lOaTKdj+4gGa7s+w From: "Susan Hares" To: "Sivananda Ramnath - CTD, Chennai." Cc: X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id LAA10049 Siva: On your request to: > > a) Add 3 new events : 1) Manual start with bgp_stop flap option set > 2) Manual start with passive TCP establishment > and bgp_stop_flap option set > 3) Automatic start with passive TCP establishment > and bgp_stop_flap option set > Events 1 and 2: Let me clarify "not feasible": We have the following options 1) Delay Open flag 2) Automatic Start flag 3) Passive TCP Establishment Flag 4) BGP stop_peer_flap flag 5) automatic stop flag 6) Perform Collision detect in Established mode 7) Accept connections from un-configured peers If we create an Manual start event with all of these options, we will expand the state machine dramatically. The two specified options: 1) Manual start with no Passive TCP Establishment Flag set 2) Manual start with Passive TCP Establishment Flag Are you looking for a clarification of Event 1? If so, please confirm this text is acceptable to add to Event 1: "If the optional Passive TCP Establishment flag and the optional Event 4 is supported, the Passive TCP Establishment Flag should not be set in Event 1." Please confirm that this is sufficient for events 1 and 2. =========== Part 2: new-event 3: Automatic Start with Passive TCP Establishment and bgp_stop_flag flag set The Automatic start events are: Event 3: Automatic start 1) No passive flag set 2) No bgp stop_peer_flap flag set Event 5: Automatic start with Passive TCP Establishment state state 1) No bgp stop_peer_flap flag set Event 6: Automatic start & BGP stop_peer_flap flag set I will revise Event 6 and add a new Event 7 and rename all other events 1 down. Here's the new automatic start events: Event 3: Automatic start 1) Passive TCP Establishment flag is not set 2) BGP stop_peer_flap flag is not set Event 5: Automatic start iwth Passive TCP Establishment flag set 1) BGP stop_peer_flap flag is not set Event 6: Automatic start & BGP stop peer flap flag is set 1) Passive TCP Establishment flag is not set Event 7: Automatic start & BGP stop_peer_flap & passive TCP The following flags are set: 1) Perform automatic start flag 2) BGP stop_peer_flap flag is set 3) Passicve TCP establishment flag is set The current event 7 will be renumbered to Event 8. Event 8 will be Moved to event 13. Events 13-27 will be renumbered to 14-28. Please confirm that you agree to this change and that we have consensus at this point. Sue Hares Siva's comments: =========== > > a) Add 3 new events : 1) Manual start with bgp_stop flap option set > 2) Manual start with passive TCP establishment > and bgp_stop_flap option set > 3) Automatic start with passive TCP establishment > and bgp_stop_flap option set > -----Original Message----- From: Sivananda Ramnath - CTD, Chennai. [mailto:siva@ctd.hcltech.com] Sent: Wednesday, February 12, 2003 5:06 AM To: Susan Hares Cc: Sivananda Ramnath (E-mail) Subject: Comments on FSM Issues Hello, My comments on open issues as per 2.2 of issue list: ++ Issue 26 ++ > We already have > Event 3 - Automatic Start > Event 5 - Automatic start with bgp_stop_flap option set > To make things consistent, shouldn't we either > > a) Add 3 new events : 1) Manual start with bgp_stop flap option set > 2) Manual start with passive TCP establishment > and bgp_stop_flap option set > 3) Automatic start with passive TCP establishment > and bgp_stop_flap option set > > or > > b) Remove Event 6, and rely on a flag to tell us whether peer flap damping > is to be performed for the session or not. > > Sue said she preferred option A. And stated that #1 & #2 are infeasible, > but that we need to add #3. I don't understand why #1 and #2 are unfeasible. Also, because we have the stop_flap as an optional session attribute, I think we are better of reducing the number of events. If that is unacceptable, I am OK with adding the events. However, I do think #1 and #2 need to be incorporated in some fashion. 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 LAA19481 for ; Fri, 14 Feb 2003 11:31:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 04EB49123F; Fri, 14 Feb 2003 11:31:40 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2408A91242; Fri, 14 Feb 2003 11:31: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 99A509123F for ; Fri, 14 Feb 2003 11:31:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5BDCA5DED1; Fri, 14 Feb 2003 11:31:12 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id E8AC15DFE6 for ; Fri, 14 Feb 2003 11:31:11 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1EGUvV04815; Fri, 14 Feb 2003 11:30:57 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) 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 h1EGUsC04808; Fri, 14 Feb 2003 11:30:54 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h1EGUs729208; Fri, 14 Feb 2003 11:30:54 -0500 (EST) Date: Fri, 14 Feb 2003 11:30:53 -0500 From: Jeffrey Haas To: "Krishnan, Vijay G." Cc: "'Mathew Richardson'" , Manav Bhatia , idr@merit.edu Subject: Re: BGP Identifier in draft-ietf-idr-bgp4-18.txt Message-ID: <20030214113053.A28677@nexthop.com> References: <313680C9A886D511A06000204840E1CF3EA3EE@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <313680C9A886D511A06000204840E1CF3EA3EE@whq-msgusr-02.pit.comms.marconi.com>; from Vijay.G.Krishnan@marconi.com on Fri, Feb 14, 2003 at 11:24:41AM -0500 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Fri, Feb 14, 2003 at 11:24:41AM -0500, Krishnan, Vijay G. wrote: > Is this true for a BGP/MPLS case, where each BGP peer will be attached to a > VRF? This starts to be very edgy. > Each VRF will have a Router_ID (used by IGPs like OSPF). Should the BGP > Identfier be the same as this Router ID. This would mean that we should have > different BGP Identifier for each VRF and one for the internet VRF. IMO (and likely contradicted by some implementations), a given router will have a common router-id/bgp identifier which is applied to all VRF's for that router. In cases where you have a "virtual router" where resources are internally disjoint, you are likely to have more than one router-id/bgp identifier. > -Vijay -- 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 LAA19465 for ; Fri, 14 Feb 2003 11:29:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 66C5F91239; Fri, 14 Feb 2003 11:29:20 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2E43F9123F; Fri, 14 Feb 2003 11:29: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 1A3AF91239 for ; Fri, 14 Feb 2003 11:29:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id EEDC55E058; Fri, 14 Feb 2003 11:29:18 -0500 (EST) Delivered-To: idr@merit.edu Received: from nomad.tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by segue.merit.edu (Postfix) with ESMTP id C2A305DE43 for ; Fri, 14 Feb 2003 11:29:18 -0500 (EST) Received: by nomad.tcb.net (Postfix, from userid 500) id 4BCC655F62; Fri, 14 Feb 2003 09:30:11 -0700 (MST) Received: from nomad.tcb.net (localhost [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id 48C3B3E83 for ; Fri, 14 Feb 2003 09:30:11 -0700 (MST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: BGP Identifier in draft-ietf-idr-bgp4-18.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Feb 2003 09:30:06 -0700 Message-Id: <20030214163011.4BCC655F62@nomad.tcb.net> Sender: owner-idr@merit.edu Precedence: bulk That's a "virtual router" sort of implementation issue, and shouldn't be addressed in the base BGP specification. -danny > > From the text that you quoted: "The value of the BGP Identifier is > determined on startup and is the same for every local interface and every > BGP peer." > > > Is this true for a BGP/MPLS case, where each BGP peer will be attached to a > VRF? Each VRF will have a Router_ID (used by IGPs like OSPF). Should the BGP > Identfier be the same as this Router ID. This would mean that we should have > different BGP Identifier for each VRF and one for the internet VRF. > > -Vijay > > 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 LAA19438 for ; Fri, 14 Feb 2003 11:25:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1E0DC91233; Fri, 14 Feb 2003 11:24:47 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D390D91239; Fri, 14 Feb 2003 11:24: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 C553991233 for ; Fri, 14 Feb 2003 11:24:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id AD2F55E058; Fri, 14 Feb 2003 11:24:45 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 145CA5E055 for ; Fri, 14 Feb 2003 11:24:45 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA02908; Fri, 14 Feb 2003 11:24:42 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA02060; Fri, 14 Feb 2003 11:24:43 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Feb 2003 11:24:43 -0500 Message-ID: <313680C9A886D511A06000204840E1CF3EA3EE@whq-msgusr-02.pit.comms.marconi.com> From: "Krishnan, Vijay G." To: "'Mathew Richardson'" , Manav Bhatia Cc: idr@merit.edu Subject: RE: BGP Identifier in draft-ietf-idr-bgp4-18.txt Date: Fri, 14 Feb 2003 11:24:41 -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 >From the text that you quoted: "The value of the BGP Identifier is determined on startup and is the same for every local interface and every BGP peer." Is this true for a BGP/MPLS case, where each BGP peer will be attached to a VRF? Each VRF will have a Router_ID (used by IGPs like OSPF). Should the BGP Identfier be the same as this Router ID. This would mean that we should have different BGP Identifier for each VRF and one for the internet VRF. -Vijay 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 LAA19333 for ; Fri, 14 Feb 2003 11:15:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8BDFA9122F; Fri, 14 Feb 2003 11:15:07 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 07EDC91233; Fri, 14 Feb 2003 11:15: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 DF1F69122F for ; Fri, 14 Feb 2003 11:15:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C7865DE43; Fri, 14 Feb 2003 11:15:04 -0500 (EST) Delivered-To: idr@merit.edu Received: from nomad.tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by segue.merit.edu (Postfix) with ESMTP id 62B7F5DE0D for ; Fri, 14 Feb 2003 11:15:03 -0500 (EST) Received: by nomad.tcb.net (Postfix, from userid 500) id 91F5955F62; Fri, 14 Feb 2003 09:15:55 -0700 (MST) Received: from nomad.tcb.net (localhost [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id 6C7603E83 for ; Fri, 14 Feb 2003 09:15:55 -0700 (MST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: BGP Identifier in draft-ietf-idr-bgp4-18.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Feb 2003 09:15:50 -0700 Message-Id: <20030214161555.91F5955F62@nomad.tcb.net> Sender: owner-idr@merit.edu Precedence: bulk > > I don't think it's possible to get much clearer than that. > > mrr I agree, I think the current text is more than sufficient. -danny 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 LAA19318 for ; Fri, 14 Feb 2003 11:12:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E7BC49121B; Fri, 14 Feb 2003 11:12:35 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A153D9122F; Fri, 14 Feb 2003 11:12:35 -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 4E0369121B for ; Fri, 14 Feb 2003 11:12:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 342DA5DED1; Fri, 14 Feb 2003 11:12:34 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id C8E5F5DE43 for ; Fri, 14 Feb 2003 11:12:33 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1EGCUk04339; Fri, 14 Feb 2003 11:12:30 -0500 (EST) (envelope-from mrr@mrichardson.nexthop.com) 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 h1EGCQC04332; Fri, 14 Feb 2003 11:12:26 -0500 (EST) (envelope-from mrr@mrichardson.nexthop.com) Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id h1EGCQ015095; Fri, 14 Feb 2003 11:12:26 -0500 (EST) Date: Fri, 14 Feb 2003 11:12:26 -0500 From: Mathew Richardson To: Manav Bhatia Cc: idr@merit.edu Subject: Re: BGP Identifier in draft-ietf-idr-bgp4-18.txt Message-ID: <20030214161226.GA27013@nexthop.com> References: <0b2901c2d3dd$b256eeb0$b4036c6b@sisodomain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0b2901c2d3dd$b256eeb0$b4036c6b@sisodomain.com> User-Agent: Mutt/1.4i X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk > Manav Bhatia [Fri, Feb 14, 2003 at 09:31:03AM +0530]: >Hi, >draft-ietf-idr-bgp4-18.txt explains the BGP Identifier as : > >" A 4-octet unsigned integer indicating the BGP Identifier of the > sender of BGP messages. A given BGP speaker sets the value of its > BGP Identifier to an IP address assigned to that BGP speaker. The > value of the BGP Identifier is determined on startup and is the > same for every local interface and every BGP peer." > >I think that the current definition is a little ambiguous and can be >re-worded. > >BGP Identifier is generally taken as the Loopback address and not >necessarily the "IP address assigned to that BGP speaker". It says "_an_ IP address assigned to that BGP speaker", not _the_. > I could have two >interfaces 1.1.1.1/24 and 1.1.2.1/24 and i could have BGP peerings over >these two interfaces. For one peer the IP address assigned to this BGP >speaker is 1.1.1.1 while for the other one it is 1.1.2.1. > >So by the current definition the BGP ID wouldn't be the same for every >local interface and every BGP peer. No. If those were the only two IP addresses assigned to the BGP speaker then the BGP Identifier would be one of those. It would be determined on startup, and be the same for every local interface and every BGP peer. >We need to stress more on the fact that it needs to be unique and same for >all the peers on every local interface. >From the text that you quoted: "The value of the BGP Identifier is determined on startup and is the same for every local interface and every BGP peer." I don't think it's possible to get much clearer than that. 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 AAA07287 for ; Fri, 14 Feb 2003 00:00:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4F5D69121E; Thu, 13 Feb 2003 23:59:40 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1CEB091222; Thu, 13 Feb 2003 23:59: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 B1A189121E for ; Thu, 13 Feb 2003 23:59:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8C1025DFAD; Thu, 13 Feb 2003 23:59:38 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailout1.samsung.com (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 3B7835DDC0 for ; Thu, 13 Feb 2003 23:59:38 -0500 (EST) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HAA00L058I88B@mailout1.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 13:58:56 +0900 (KST) Received: from ep_mmp2 ([127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HAA00D3T8I777@mailout1.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 13:58:55 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HAA001NT946GE@mmp2.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 14:12:09 +0900 (KST) Date: Fri, 14 Feb 2003 10:28:55 +0530 From: Manav Bhatia Subject: Re: Next-Hop in IPv6 only environment To: Enke Chen Cc: Jeffrey Haas , mjh@icir.org, idr@merit.edu Reply-To: Manav Bhatia Message-id: <0c0701c2d3e5$c8bbd640$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20030214044325.AE3E7979C1@popserv2.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Enke, > An UPDATE message that carries no NLRI, other than the one encoded in > the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute. > If such a message contains the NEXT_HOP attribute, the BGP speaker > that receives the message should ignore this attribute. Yes it indeed is. However it would be really nice if a similar thing is mentioned somewhere in the base spec too OR once again, a pointer to the fact that NEXT_HOP attribute is not always *mandatory* is mentioned to remove any later confusions amongst the implementers. I have a gut feeling that this issue will crop up again some time later down the line. The confusion will be all the more aggravated when your base spec RFC is greater than your extensions RFC nos. Thanks, Manav P.S. Once again, the issue isn't that RFC 2858 isn't clear .. its just that it defies what the base spec mandates any implementation to do! It just gets all the more skewed when the base spec is more recent than the extensions draft/RFC! :-) 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 XAA06677 for ; Thu, 13 Feb 2003 23:44:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B35069121A; Thu, 13 Feb 2003 23:43:28 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B54C9121E; Thu, 13 Feb 2003 23:43: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 877EA9121A for ; Thu, 13 Feb 2003 23:43:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 750A85DF39; Thu, 13 Feb 2003 23:43:27 -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 3C5D35DDE7 for ; Thu, 13 Feb 2003 23:43:27 -0500 (EST) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id A4461263681; Thu, 13 Feb 2003 20:43:26 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv2.redback.com (Postfix) with ESMTP id AE3E7979C1; Thu, 13 Feb 2003 20:43:24 -0800 (PST) To: Manav Bhatia Cc: Jeffrey Haas , idr@merit.edu, enke@redback.com Subject: Re: Next-Hop in IPv6 only environment In-Reply-To: Message from Manav Bhatia of "Fri, 14 Feb 2003 09:16:31 +0530." <0b1d01c2d3db$aaf5f6e0$b4036c6b@sisodomain.com> Date: Thu, 13 Feb 2003 20:43:24 -0800 From: Enke Chen Message-Id: <20030214044325.AE3E7979C1@popserv2.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Manav, > Date: Fri, 14 Feb 2003 09:16:31 +0530 > From: Manav Bhatia > Subject: Re: Next-Hop in IPv6 only environment > To: Jeffrey Haas > Cc: idr@merit.edu > Reply-To: Manav Bhatia > Message-id: <0b1d01c2d3db$aaf5f6e0$b4036c6b@sisodomain.com> > > Jeff, > > > I'm not fond of our current mechanism for doing this since it will > > lead potentially to a base specification with a higher RFC number than > > the extensions which would lead to similar confusion that you are having. > > I believe that adding a small pointer in the base spec is much better than > having others spend cycles trying to understand the apparent contradiction > in the base spec and the extensions. A small note saying that this is not > necessarily true anymore or something like that can very easily be > accomodated for greater clarity and perspecuity of the RFC. Reading RFC 2858 again, it actually has the explicit text on the NEXT_HOP attribute: An UPDATE message that carries no NLRI, other than the one encoded in the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute. If such a message contains the NEXT_HOP attribute, the BGP speaker that receives the message should ignore this attribute. -- Enke > > > > > However, I'm also not fond of the idea of trying to do all of the > > extensions and the base spec in one document. > > I agree. > > > If I suggested such a > > thing, I expect that Yakov would nail my hide to an IBM DASD chassis > > as a warning to all others and Sue would gleefully seize all of my > > office supplies. > > And the IDR community will also loose a very good reviewer :-) > > Regards > -- > Manav Bhatia > Samsung Electronics. > > 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 XAA05272 for ; Thu, 13 Feb 2003 23:04:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E442A91225; Thu, 13 Feb 2003 23:04:17 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7301D9121E; Thu, 13 Feb 2003 23:04: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 8AD279129C for ; Thu, 13 Feb 2003 23:01:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 59B2F5E045; Thu, 13 Feb 2003 23:01:45 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailout3.samsung.com (unknown [203.254.224.33]) by segue.merit.edu (Postfix) with ESMTP id 05A235DF5C for ; Thu, 13 Feb 2003 23:01:45 -0500 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HAA003015TB5Y@mailout3.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 13:00:47 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HAA00MZ85TBUZ@mailout3.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 13:00:47 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HAA00G5M6FQ1F@mmp2.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 13:14:16 +0900 (KST) Date: Fri, 14 Feb 2003 09:31:03 +0530 From: Manav Bhatia Subject: BGP Identifier in draft-ietf-idr-bgp4-18.txt To: idr@merit.edu Reply-To: Manav Bhatia Message-id: <0b2901c2d3dd$b256eeb0$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Sender: owner-idr@merit.edu Precedence: bulk Hi, draft-ietf-idr-bgp4-18.txt explains the BGP Identifier as : " A 4-octet unsigned integer indicating the BGP Identifier of the sender of BGP messages. A given BGP speaker sets the value of its BGP Identifier to an IP address assigned to that BGP speaker. The value of the BGP Identifier is determined on startup and is the same for every local interface and every BGP peer." I think that the current definition is a little ambiguous and can be re-worded. BGP Identifier is generally taken as the Loopback address and not necessarily the "IP address assigned to that BGP speaker". I could have two interfaces 1.1.1.1/24 and 1.1.2.1/24 and i could have BGP peerings over these two interfaces. For one peer the IP address assigned to this BGP speaker is 1.1.1.1 while for the other one it is 1.1.2.1. So by the current definition the BGP ID wouldn't be the same for every local interface and every BGP peer. We need to stress more on the fact that it needs to be unique and same for all the peers on every local interface. Regards, Manav ---- Senior Software Engineer Samsung India Software Operations Bangalore - 560 001 +91-80-5550555/6 (1120) 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 WAA04733 for ; Thu, 13 Feb 2003 22:49:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8BBFC91212; Thu, 13 Feb 2003 22:48:56 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25C4F91216; Thu, 13 Feb 2003 22:48: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 4300191212 for ; Thu, 13 Feb 2003 22:47:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1980F5DE5B; Thu, 13 Feb 2003 22:47:14 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailout2.samsung.com (unknown [203.254.224.25]) by segue.merit.edu (Postfix) with ESMTP id BC2445DE12 for ; Thu, 13 Feb 2003 22:47:13 -0500 (EST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HAA00I0154P23@mailout2.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 12:46:01 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HAA0042954OMM@mailout2.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 12:46:01 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HAA00F6M5RIK4@mmp2.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 12:59:44 +0900 (KST) Date: Fri, 14 Feb 2003 09:16:31 +0530 From: Manav Bhatia Subject: Re: Next-Hop in IPv6 only environment To: Jeffrey Haas Cc: idr@merit.edu Reply-To: Manav Bhatia Message-id: <0b1d01c2d3db$aaf5f6e0$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20030214031310.A6CD615D3C1@popserv1.redback.com> <0aec01c2d3d8$a3996150$b4036c6b@sisodomain.com> <20030213223726.A27200@nexthop.com> Sender: owner-idr@merit.edu Precedence: bulk Jeff, > I'm not fond of our current mechanism for doing this since it will > lead potentially to a base specification with a higher RFC number than > the extensions which would lead to similar confusion that you are having. I believe that adding a small pointer in the base spec is much better than having others spend cycles trying to understand the apparent contradiction in the base spec and the extensions. A small note saying that this is not necessarily true anymore or something like that can very easily be accomodated for greater clarity and perspecuity of the RFC. > > However, I'm also not fond of the idea of trying to do all of the > extensions and the base spec in one document. I agree. > If I suggested such a > thing, I expect that Yakov would nail my hide to an IBM DASD chassis > as a warning to all others and Sue would gleefully seize all of my > office supplies. And the IDR community will also loose a very good reviewer :-) Regards -- Manav Bhatia Samsung Electronics. 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 WAA04293 for ; Thu, 13 Feb 2003 22:38:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5DCF89120D; Thu, 13 Feb 2003 22:37:36 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2FC9E91212; Thu, 13 Feb 2003 22:37: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 278F39120D for ; Thu, 13 Feb 2003 22:37:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0F4CA5DFAD; Thu, 13 Feb 2003 22:37:35 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id A2C725DE5B for ; Thu, 13 Feb 2003 22:37:34 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1E3bTr93385; Thu, 13 Feb 2003 22:37:29 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) 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 h1E3bQC93378; Thu, 13 Feb 2003 22:37:26 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h1E3bQR27217; Thu, 13 Feb 2003 22:37:26 -0500 (EST) Date: Thu, 13 Feb 2003 22:37:26 -0500 From: Jeffrey Haas To: Manav Bhatia Cc: Enke Chen , idr@merit.edu Subject: Re: Next-Hop in IPv6 only environment Message-ID: <20030213223726.A27200@nexthop.com> References: <20030214031310.A6CD615D3C1@popserv1.redback.com> <0aec01c2d3d8$a3996150$b4036c6b@sisodomain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0aec01c2d3d8$a3996150$b4036c6b@sisodomain.com>; from manav@samsung.com on Fri, Feb 14, 2003 at 08:54:45AM +0530 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Fri, Feb 14, 2003 at 08:54:45AM +0530, Manav Bhatia wrote: > Then why does the draft-ietf-idr-bgp4-18.txt still mention the NEXT_HOP > field as a well-known mandatory attribute. If it isn't required for some > extensions then i believe we must mention it somewhere. The general idea is that this is the basic specification. The extensions alter the base specification. I'm not fond of our current mechanism for doing this since it will lead potentially to a base specification with a higher RFC number than the extensions which would lead to similar confusion that you are having. However, I'm also not fond of the idea of trying to do all of the extensions and the base spec in one document. If I suggested such a thing, I expect that Yakov would nail my hide to an IBM DASD chassis as a warning to all others and Sue would gleefully seize all of my office supplies. -- 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 WAA03789 for ; Thu, 13 Feb 2003 22:26:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 338E2912B3; Thu, 13 Feb 2003 22:25:35 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 052A1912B6; Thu, 13 Feb 2003 22:25:34 -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 8A2A8912B3 for ; Thu, 13 Feb 2003 22:25:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7825C5DFAD; Thu, 13 Feb 2003 22:25:33 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailout1.samsung.com (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 2710E5DFA4 for ; Thu, 13 Feb 2003 22:25:33 -0500 (EST) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HAA00H0145EHZ@mailout1.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 12:24:50 +0900 (KST) Received: from ep_mmp2 ([127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HAA00D3Y45D77@mailout1.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 12:24:49 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HAA00GBM4RD1F@mmp2.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 12:38:03 +0900 (KST) Date: Fri, 14 Feb 2003 08:54:45 +0530 From: Manav Bhatia Subject: Re: Next-Hop in IPv6 only environment To: Enke Chen Cc: Jeffrey Haas , idr@merit.edu Reply-To: Manav Bhatia Message-id: <0aec01c2d3d8$a3996150$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20030214031310.A6CD615D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Enke, Then why does the draft-ietf-idr-bgp4-18.txt still mention the NEXT_HOP field as a well-known mandatory attribute. If it isn't required for some extensions then i believe we must mention it somewhere. Moreover, i have never come across any implementation which doesn't look for this attribute when it receives an UPDATE message! Regards, Manav ----- Original Message ----- From: "Enke Chen" To: "Manav Bhatia" Cc: "Jeffrey Haas" ; ; "Mareline Sheldon" ; Sent: Friday, February 14, 2003 8:43 AM Subject: Re: Next-Hop in IPv6 only environment > Hi, Manav: > > > Date: Fri, 14 Feb 2003 08:29:44 +0530 > > From: Manav Bhatia > > Subject: Re: Next-Hop in IPv6 only environment > > To: Jeffrey Haas , > > Mareline Sheldon > > Cc: idr@merit.edu > > Reply-To: Manav Bhatia > > Message-id: <0ab901c2d3d5$2417ceb0$b4036c6b@sisodomain.com> > > > > Jeff, > > If you are not running a dual stack you still need an IPv4 address as a > > next-hop (even though it wont be used) which will be used as a mandatory > > path attribute along with the ORIGIN and AS-PATH. > > This is not correct. As the nexthop value is carried in the MP_REACH_NLRI > filed, the NEXTHOP attribute is not needed at all. Please See the following > text from RFC 2858: > > ------------------------------------------------------------------- > 2. Multiprotocol Reachable NLRI - MP_REACH_NLRI (Type Code 14): > > An UPDATE message that carries the MP_REACH_NLRI must also carry the > ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP > exchanges). Moreover, in IBGP exchanges such a message must also > carry the LOCAL_PREF attribute. If such a message is received from an > external peer, the local system shall check whether the leftmost AS > in the AS_PATH attribute is equal to the autonomous system number of > the peer than sent the message. If that is not the case, the local > system shall send the NOTIFICATION message with Error Code UPDATE > Message Error, and the Error Subcode set to Malformed AS_PATH. > --------------------------------------------------------------------- > > -- Enke > > > > > -- > > Manav > > > > ----- Original Message ----- > > From: "Jeffrey Haas" > > To: "Mareline Sheldon" > > Cc: > > Sent: Thursday, February 13, 2003 11:43 PM > > Subject: Re: Next-Hop in IPv6 only environment > > > > > > > On Thu, Feb 13, 2003 at 06:59:59AM -0800, Mareline Sheldon wrote: > > > > If your network is IPv6 only then you must somehow give some IPv4 > > address which this router > > > > may use as the next-hop when advertising BGP UPDATE messages. One way > > could be through CLI. > > > > > > If the boxes, as shown below, are NOT running dual stack, then an > > > IPv4 nexthop is nonsense. IPv4 reachability should be discarded. > > > > > > > Mareline S. > > > > > > > > --- Manav Bhatia wrote: > > > > > Hi, > > > > > I guess in case of IPv6 only environment then one necessarily needs > > to > > > > > configure a Router ID which will be filled in the mandatory fields. > > But > > > > > then if the Router ID is non-routable then one cant advertise IPv4 > > > > > reachability information using that peering !!! > > > > > > > > > > Is this correct? > > > > > > > > > > Regards, > > > > > Manav > > > > > > > > > > ----- Original Message ----- > > > > > From: "Manav Bhatia" > > > > > To: > > > > > Sent: Thursday, February 13, 2003 2:36 PM > > > > > Subject: Next-Hop in IPv6 only environment > > > > > > > > > > > > > > > > Hello, > > > > > > I have a very basic doubt in implementing BGP extensions for IPv6 > > > > > > Inter-Domain Routing. > > > > > > > > > > > > Consider two routers (not running dual stack) as shown in the > > figure. > > > > > > > > > > > > ----------- -------------- > > > > > > | | | | > > > > > > | peer 1 | IPv6 | peer2 | > > > > > > | | ------------ | | > > > > > > | | | | > > > > > > ----------- --------------- > > > > > > 3ffe :: aa 3ffe :: bb > > > > > > > > > > > > They are peered up using IPv6 addresses using TCP over IPv6. Which > > is > > > > > then > > > > > > the IPv4 next-hop which shall be used in all the BGP UPDATE > > messages. > > > > > Does > > > > > > it need to be explicitly configured or is one of the global/local > > IPv6 > > > > > > addresses converted into IPv4 and used. How is it done? > > > > > > > > > > > > In case of dual stack one can look into the interface over which > > the > > > > > > peering takes place and use that IP address as the next-hop. But > > what > > > > > > happens in case of IPv6 only? > > > > > > > > > > > > Regards, > > > > > > Manav > > > > > > -- > > > 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 WAA03329 for ; Thu, 13 Feb 2003 22:13:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8F362912B1; Thu, 13 Feb 2003 22:13:23 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CC33912B3; Thu, 13 Feb 2003 22:13:23 -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 346C8912B1 for ; Thu, 13 Feb 2003 22:13:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1C99C5DFA4; Thu, 13 Feb 2003 22:13:22 -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 CD01A5DE3A for ; Thu, 13 Feb 2003 22:13:21 -0500 (EST) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 0AD43A8906; Thu, 13 Feb 2003 19:13:21 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id A6CD615D3C1; Thu, 13 Feb 2003 19:13:10 -0800 (PST) To: Manav Bhatia Cc: Jeffrey Haas , enke@redback.com, Mareline Sheldon , idr@merit.edu Subject: Re: Next-Hop in IPv6 only environment In-Reply-To: Message from Manav Bhatia of "Fri, 14 Feb 2003 08:29:44 +0530." <0ab901c2d3d5$2417ceb0$b4036c6b@sisodomain.com> Date: Thu, 13 Feb 2003 19:13:10 -0800 From: Enke Chen Message-Id: <20030214031310.A6CD615D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Manav: > Date: Fri, 14 Feb 2003 08:29:44 +0530 > From: Manav Bhatia > Subject: Re: Next-Hop in IPv6 only environment > To: Jeffrey Haas , > Mareline Sheldon > Cc: idr@merit.edu > Reply-To: Manav Bhatia > Message-id: <0ab901c2d3d5$2417ceb0$b4036c6b@sisodomain.com> > > Jeff, > If you are not running a dual stack you still need an IPv4 address as a > next-hop (even though it wont be used) which will be used as a mandatory > path attribute along with the ORIGIN and AS-PATH. This is not correct. As the nexthop value is carried in the MP_REACH_NLRI filed, the NEXTHOP attribute is not needed at all. Please See the following text from RFC 2858: ------------------------------------------------------------------- 2. Multiprotocol Reachable NLRI - MP_REACH_NLRI (Type Code 14): An UPDATE message that carries the MP_REACH_NLRI must also carry the ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP exchanges). Moreover, in IBGP exchanges such a message must also carry the LOCAL_PREF attribute. If such a message is received from an external peer, the local system shall check whether the leftmost AS in the AS_PATH attribute is equal to the autonomous system number of the peer than sent the message. If that is not the case, the local system shall send the NOTIFICATION message with Error Code UPDATE Message Error, and the Error Subcode set to Malformed AS_PATH. --------------------------------------------------------------------- -- Enke > > -- > Manav > > ----- Original Message ----- > From: "Jeffrey Haas" > To: "Mareline Sheldon" > Cc: > Sent: Thursday, February 13, 2003 11:43 PM > Subject: Re: Next-Hop in IPv6 only environment > > > > On Thu, Feb 13, 2003 at 06:59:59AM -0800, Mareline Sheldon wrote: > > > If your network is IPv6 only then you must somehow give some IPv4 > address which this router > > > may use as the next-hop when advertising BGP UPDATE messages. One way > could be through CLI. > > > > If the boxes, as shown below, are NOT running dual stack, then an > > IPv4 nexthop is nonsense. IPv4 reachability should be discarded. > > > > > Mareline S. > > > > > > --- Manav Bhatia wrote: > > > > Hi, > > > > I guess in case of IPv6 only environment then one necessarily needs > to > > > > configure a Router ID which will be filled in the mandatory fields. > But > > > > then if the Router ID is non-routable then one cant advertise IPv4 > > > > reachability information using that peering !!! > > > > > > > > Is this correct? > > > > > > > > Regards, > > > > Manav > > > > > > > > ----- Original Message ----- > > > > From: "Manav Bhatia" > > > > To: > > > > Sent: Thursday, February 13, 2003 2:36 PM > > > > Subject: Next-Hop in IPv6 only environment > > > > > > > > > > > > > Hello, > > > > > I have a very basic doubt in implementing BGP extensions for IPv6 > > > > > Inter-Domain Routing. > > > > > > > > > > Consider two routers (not running dual stack) as shown in the > figure. > > > > > > > > > > ----------- -------------- > > > > > | | | | > > > > > | peer 1 | IPv6 | peer2 | > > > > > | | ------------ | | > > > > > | | | | > > > > > ----------- --------------- > > > > > 3ffe :: aa 3ffe :: bb > > > > > > > > > > They are peered up using IPv6 addresses using TCP over IPv6. Which > is > > > > then > > > > > the IPv4 next-hop which shall be used in all the BGP UPDATE > messages. > > > > Does > > > > > it need to be explicitly configured or is one of the global/local > IPv6 > > > > > addresses converted into IPv4 and used. How is it done? > > > > > > > > > > In case of dual stack one can look into the interface over which > the > > > > > peering takes place and use that IP address as the next-hop. But > what > > > > > happens in case of IPv6 only? > > > > > > > > > > Regards, > > > > > Manav > > > > -- > > 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 WAA02900 for ; Thu, 13 Feb 2003 22:01:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8D82D912AA; Thu, 13 Feb 2003 22:01:09 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 269E5912B1; Thu, 13 Feb 2003 22:01: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 245BD912AA for ; Thu, 13 Feb 2003 22:00:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id ABCDF5E032; Thu, 13 Feb 2003 22:00:31 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailout3.samsung.com (unknown [203.254.224.33]) by segue.merit.edu (Postfix) with ESMTP id E835E5DE8C for ; Thu, 13 Feb 2003 22:00:30 -0500 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HAA001052Z9TN@mailout3.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 11:59:33 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HAA000DL2Z87X@mailout3.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 11:59:33 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HAA00FDM3LJK4@mmp2.samsung.com> for idr@merit.edu; Fri, 14 Feb 2003 12:13:01 +0900 (KST) Date: Fri, 14 Feb 2003 08:29:44 +0530 From: Manav Bhatia Subject: Re: Next-Hop in IPv6 only environment To: Jeffrey Haas , Mareline Sheldon Cc: idr@merit.edu Reply-To: Manav Bhatia Message-id: <0ab901c2d3d5$2417ceb0$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <09e401c2d35e$2fbf7be0$b4036c6b@sisodomain.com> <20030213145959.86191.qmail@web20310.mail.yahoo.com> <20030213131303.A24336@nexthop.com> Sender: owner-idr@merit.edu Precedence: bulk Jeff, If you are not running a dual stack you still need an IPv4 address as a next-hop (even though it wont be used) which will be used as a mandatory path attribute along with the ORIGIN and AS-PATH. -- Manav ----- Original Message ----- From: "Jeffrey Haas" To: "Mareline Sheldon" Cc: Sent: Thursday, February 13, 2003 11:43 PM Subject: Re: Next-Hop in IPv6 only environment > On Thu, Feb 13, 2003 at 06:59:59AM -0800, Mareline Sheldon wrote: > > If your network is IPv6 only then you must somehow give some IPv4 address which this router > > may use as the next-hop when advertising BGP UPDATE messages. One way could be through CLI. > > If the boxes, as shown below, are NOT running dual stack, then an > IPv4 nexthop is nonsense. IPv4 reachability should be discarded. > > > Mareline S. > > > > --- Manav Bhatia wrote: > > > Hi, > > > I guess in case of IPv6 only environment then one necessarily needs to > > > configure a Router ID which will be filled in the mandatory fields. But > > > then if the Router ID is non-routable then one cant advertise IPv4 > > > reachability information using that peering !!! > > > > > > Is this correct? > > > > > > Regards, > > > Manav > > > > > > ----- Original Message ----- > > > From: "Manav Bhatia" > > > To: > > > Sent: Thursday, February 13, 2003 2:36 PM > > > Subject: Next-Hop in IPv6 only environment > > > > > > > > > > Hello, > > > > I have a very basic doubt in implementing BGP extensions for IPv6 > > > > Inter-Domain Routing. > > > > > > > > Consider two routers (not running dual stack) as shown in the figure. > > > > > > > > ----------- -------------- > > > > | | | | > > > > | peer 1 | IPv6 | peer2 | > > > > | | ------------ | | > > > > | | | | > > > > ----------- --------------- > > > > 3ffe :: aa 3ffe :: bb > > > > > > > > They are peered up using IPv6 addresses using TCP over IPv6. Which is > > > then > > > > the IPv4 next-hop which shall be used in all the BGP UPDATE messages. > > > Does > > > > it need to be explicitly configured or is one of the global/local IPv6 > > > > addresses converted into IPv4 and used. How is it done? > > > > > > > > In case of dual stack one can look into the interface over which the > > > > peering takes place and use that IP address as the next-hop. But what > > > > happens in case of IPv6 only? > > > > > > > > Regards, > > > > Manav > > -- > 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 NAA13999 for ; Thu, 13 Feb 2003 13:13:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D58AD9127C; Thu, 13 Feb 2003 13:13:10 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A7511912B0; Thu, 13 Feb 2003 13:13: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 8AFE79127C for ; Thu, 13 Feb 2003 13:13:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 65E5F5DE41; Thu, 13 Feb 2003 13:13:09 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id C30F85DE2F for ; Thu, 13 Feb 2003 13:13:08 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1DID6M82246; Thu, 13 Feb 2003 13:13:06 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) 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 h1DID3C82239; Thu, 13 Feb 2003 13:13:03 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h1DID3Q25171; Thu, 13 Feb 2003 13:13:03 -0500 (EST) Date: Thu, 13 Feb 2003 13:13:03 -0500 From: Jeffrey Haas To: Mareline Sheldon Cc: idr@merit.edu Subject: Re: Next-Hop in IPv6 only environment Message-ID: <20030213131303.A24336@nexthop.com> References: <09e401c2d35e$2fbf7be0$b4036c6b@sisodomain.com> <20030213145959.86191.qmail@web20310.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030213145959.86191.qmail@web20310.mail.yahoo.com>; from marelines@yahoo.com on Thu, Feb 13, 2003 at 06:59:59AM -0800 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Thu, Feb 13, 2003 at 06:59:59AM -0800, Mareline Sheldon wrote: > If your network is IPv6 only then you must somehow give some IPv4 address which this router > may use as the next-hop when advertising BGP UPDATE messages. One way could be through CLI. If the boxes, as shown below, are NOT running dual stack, then an IPv4 nexthop is nonsense. IPv4 reachability should be discarded. > Mareline S. > > --- Manav Bhatia wrote: > > Hi, > > I guess in case of IPv6 only environment then one necessarily needs to > > configure a Router ID which will be filled in the mandatory fields. But > > then if the Router ID is non-routable then one cant advertise IPv4 > > reachability information using that peering !!! > > > > Is this correct? > > > > Regards, > > Manav > > > > ----- Original Message ----- > > From: "Manav Bhatia" > > To: > > Sent: Thursday, February 13, 2003 2:36 PM > > Subject: Next-Hop in IPv6 only environment > > > > > > > Hello, > > > I have a very basic doubt in implementing BGP extensions for IPv6 > > > Inter-Domain Routing. > > > > > > Consider two routers (not running dual stack) as shown in the figure. > > > > > > ----------- -------------- > > > | | | | > > > | peer 1 | IPv6 | peer2 | > > > | | ------------ | | > > > | | | | > > > ----------- --------------- > > > 3ffe :: aa 3ffe :: bb > > > > > > They are peered up using IPv6 addresses using TCP over IPv6. Which is > > then > > > the IPv4 next-hop which shall be used in all the BGP UPDATE messages. > > Does > > > it need to be explicitly configured or is one of the global/local IPv6 > > > addresses converted into IPv4 and used. How is it done? > > > > > > In case of dual stack one can look into the interface over which the > > > peering takes place and use that IP address as the next-hop. But what > > > happens in case of IPv6 only? > > > > > > Regards, > > > Manav -- 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 KAA07100 for ; Thu, 13 Feb 2003 10:00:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8A0B991281; Thu, 13 Feb 2003 10:00:09 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1586C91296; Thu, 13 Feb 2003 10:00:08 -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 78D2091281 for ; Thu, 13 Feb 2003 10:00:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id CBE735DF74; Thu, 13 Feb 2003 10:00:04 -0500 (EST) Delivered-To: idr@merit.edu Received: from web20310.mail.yahoo.com (web20310.mail.yahoo.com [216.136.226.91]) by segue.merit.edu (Postfix) with SMTP id F31E15DD8E for ; Thu, 13 Feb 2003 10:00:03 -0500 (EST) Message-ID: <20030213145959.86191.qmail@web20310.mail.yahoo.com> Received: from [203.200.20.226] by web20310.mail.yahoo.com via HTTP; Thu, 13 Feb 2003 06:59:59 PST Date: Thu, 13 Feb 2003 06:59:59 -0800 (PST) From: Mareline Sheldon Subject: Re: Next-Hop in IPv6 only environment To: idr@merit.edu In-Reply-To: <09e401c2d35e$2fbf7be0$b4036c6b@sisodomain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Exactly. If your network is IPv6 only then you must somehow give some IPv4 address which this router may use as the next-hop when advertising BGP UPDATE messages. One way could be through CLI. Mareline S. --- Manav Bhatia wrote: > Hi, > I guess in case of IPv6 only environment then one necessarily needs to > configure a Router ID which will be filled in the mandatory fields. But > then if the Router ID is non-routable then one cant advertise IPv4 > reachability information using that peering !!! > > Is this correct? > > Regards, > Manav > > ----- Original Message ----- > From: "Manav Bhatia" > To: > Sent: Thursday, February 13, 2003 2:36 PM > Subject: Next-Hop in IPv6 only environment > > > > Hello, > > I have a very basic doubt in implementing BGP extensions for IPv6 > > Inter-Domain Routing. > > > > Consider two routers (not running dual stack) as shown in the figure. > > > > ----------- -------------- > > | | | | > > | peer 1 | IPv6 | peer2 | > > | | ------------ | | > > | | | | > > ----------- --------------- > > 3ffe :: aa 3ffe :: bb > > > > They are peered up using IPv6 addresses using TCP over IPv6. Which is > then > > the IPv4 next-hop which shall be used in all the BGP UPDATE messages. > Does > > it need to be explicitly configured or is one of the global/local IPv6 > > addresses converted into IPv4 and used. How is it done? > > > > In case of dual stack one can look into the interface over which the > > peering takes place and use that IP address as the next-hop. But what > > happens in case of IPv6 only? > > > > Regards, > > Manav > > > > > __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.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 HAA03070 for ; Thu, 13 Feb 2003 07:50:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4CCA791273; Thu, 13 Feb 2003 07:49:45 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8A349126F; Thu, 13 Feb 2003 07:49:44 -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 908C49127C for ; Thu, 13 Feb 2003 07:49:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6BAFB5DF66; Thu, 13 Feb 2003 07:49:04 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailout1.samsung.com (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 1C5D85DF65 for ; Thu, 13 Feb 2003 07:49:04 -0500 (EST) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HA800901ZKEL8@mailout1.samsung.com> for idr@merit.edu; Thu, 13 Feb 2003 21:48:14 +0900 (KST) Received: from ep_mmp2 ([127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HA80062HZKENG@mailout1.samsung.com> for idr@merit.edu; Thu, 13 Feb 2003 21:48:14 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HA900F4G06CK4@mmp2.samsung.com> for idr@merit.edu; Thu, 13 Feb 2003 22:01:27 +0900 (KST) Date: Thu, 13 Feb 2003 18:18:17 +0530 From: Manav Bhatia Subject: Re: Next-Hop in IPv6 only environment To: idr@merit.edu Reply-To: Manav Bhatia Message-id: <09e401c2d35e$2fbf7be0$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <053501c2d33f$2d5d8820$b4036c6b@sisodomain.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, I guess in case of IPv6 only environment then one necessarily needs to configure a Router ID which will be filled in the mandatory fields. But then if the Router ID is non-routable then one cant advertise IPv4 reachability information using that peering !!! Is this correct? Regards, Manav ----- Original Message ----- From: "Manav Bhatia" To: Sent: Thursday, February 13, 2003 2:36 PM Subject: Next-Hop in IPv6 only environment > Hello, > I have a very basic doubt in implementing BGP extensions for IPv6 > Inter-Domain Routing. > > Consider two routers (not running dual stack) as shown in the figure. > > ----------- -------------- > | | | | > | peer 1 | IPv6 | peer2 | > | | ------------ | | > | | | | > ----------- --------------- > 3ffe :: aa 3ffe :: bb > > They are peered up using IPv6 addresses using TCP over IPv6. Which is then > the IPv4 next-hop which shall be used in all the BGP UPDATE messages. Does > it need to be explicitly configured or is one of the global/local IPv6 > addresses converted into IPv4 and used. How is it done? > > In case of dual stack one can look into the interface over which the > peering takes place and use that IP address as the next-hop. But what > happens in case of IPv6 only? > > 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 EAA26076 for ; Thu, 13 Feb 2003 04:07:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6F53F91214; Thu, 13 Feb 2003 04:07:07 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B30991216; Thu, 13 Feb 2003 04: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 D5EB691214 for ; Thu, 13 Feb 2003 04:07:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id BC4C05DF43; Thu, 13 Feb 2003 04:07:05 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailout3.samsung.com (unknown [203.254.224.33]) by segue.merit.edu (Postfix) with ESMTP id 6D86D5DF36 for ; Thu, 13 Feb 2003 04:07:05 -0500 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HA800001PA2QF@mailout3.samsung.com> for idr@merit.edu; Thu, 13 Feb 2003 18:06:02 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HA800KY5PA20I@mailout3.samsung.com> for idr@merit.edu; Thu, 13 Feb 2003 18:06:02 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HA8004PHPWFH8@mmp2.samsung.com> for idr@merit.edu; Thu, 13 Feb 2003 18:19:29 +0900 (KST) Date: Thu, 13 Feb 2003 14:36:19 +0530 From: Manav Bhatia Subject: Next-Hop in IPv6 only environment To: idr@merit.edu Reply-To: Manav Bhatia Message-id: <053501c2d33f$2d5d8820$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Sender: owner-idr@merit.edu Precedence: bulk Hello, I have a very basic doubt in implementing BGP extensions for IPv6 Inter-Domain Routing. Consider two routers (not running dual stack) as shown in the figure. ----------- -------------- | | | | | peer 1 | IPv6 | peer2 | | | ------------ | | | | | | ----------- --------------- 3ffe :: aa 3ffe :: bb They are peered up using IPv6 addresses using TCP over IPv6. Which is then the IPv4 next-hop which shall be used in all the BGP UPDATE messages. Does it need to be explicitly configured or is one of the global/local IPv6 addresses converted into IPv4 and used. How is it done? In case of dual stack one can look into the interface over which the peering takes place and use that IP address as the next-hop. But what happens in case of IPv6 only? 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 MAA22636 for ; Wed, 12 Feb 2003 12:04:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2C06691240; Wed, 12 Feb 2003 12:04:27 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E66291242; Wed, 12 Feb 2003 12:04: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 E2EB391240 for ; Wed, 12 Feb 2003 12:02:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id B7D2C5DED4; Wed, 12 Feb 2003 12:02:33 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 298F95DE39 for ; Wed, 12 Feb 2003 12:02:33 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h1CH2Be56347; Wed, 12 Feb 2003 12:02:11 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) 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 h1CH25C56336; Wed, 12 Feb 2003 12:02:05 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h1CH25R19658; Wed, 12 Feb 2003 12:02:05 -0500 (EST) Date: Wed, 12 Feb 2003 12:02:05 -0500 From: Jeffrey Haas To: Micah Bartell Cc: Mareline Sheldon , "John G. Scudder" , idr@merit.edu Subject: Re: Route Reflectors and IPv6 Message-ID: <20030212120205.A19313@nexthop.com> References: <20030212133726.87383.qmail@web20302.mail.yahoo.com> <4A280A7E-3EA3-11D7-A673-000A95765246@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4A280A7E-3EA3-11D7-A673-000A95765246@cisco.com>; from mbartell@cisco.com on Wed, Feb 12, 2003 at 10:01:47AM -0600 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Wed, Feb 12, 2003 at 10:01:47AM -0600, Micah Bartell wrote: > I would think that explicitly configuring BGP IDs is a good best > practice. I haven't had the time nor the data to analyze a live network. However, I have a large suspicion that on a router with a reasonable number of external peering sessions that the tie-breaking will get down to routerid in a significant number of cases. This means that choosing a router-id intelligently may seriously affect route selection. This is a gentle reminder to implementors that having some way to extra at what point a route was selected in the tie-breaking process would be a damned handy thing to have in your CLI. > /mpb -- 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 LAA20665 for ; Wed, 12 Feb 2003 11:02:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DA5E591235; Wed, 12 Feb 2003 11:01:47 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7FB0A91236; Wed, 12 Feb 2003 11:01: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 64C4691235 for ; Wed, 12 Feb 2003 11:01:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id E2E3C5DDAA; Wed, 12 Feb 2003 11:01:43 -0500 (EST) Delivered-To: idr@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id 6BAFF5DD96 for ; Wed, 12 Feb 2003 11:01:43 -0500 (EST) Received: from cisco.com (sjc-vpn4-18.cisco.com [10.21.80.18]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1CG1XB6025799; Wed, 12 Feb 2003 08:01:33 -0800 (PST) Date: Wed, 12 Feb 2003 10:01:47 -0600 Subject: Re: Route Reflectors and IPv6 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "John G. Scudder" , idr@merit.edu To: Mareline Sheldon From: Micah Bartell In-Reply-To: <20030212133726.87383.qmail@web20302.mail.yahoo.com> Message-Id: <4A280A7E-3EA3-11D7-A673-000A95765246@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-idr@merit.edu Precedence: bulk I would think that explicitly configuring BGP IDs is a good best practice. I know that having the router automatically use one of the IPv4 addresses on the router could result in problems such as when anycast RP is used for multicast. In the case of IPv6 only, there is no way to guarantee that any 32-bit integer generated based on internal information is unique in the domain. I think in the long run, separating the BGP ID from the actual addressing is beneficial with BGP being used in a multiprotocol fashion. /mpb On Wednesday, Feb 12, 2003, at 07:37 US/Central, Mareline Sheldon wrote: > okay .. so then it becomes mandatory for everyone to explicitly > configure a BGP ID which needs > to be unique in an AS! This is somewhat problematic coz till now we > were not necessarily > explicitly configuring BGP IDs for if none was given then it would > automatically pick out one > from its interfaces. > > This will not be possible in an IPv6 network now coz all the > interfaces will be assigned IPv6 > addresses. > > Mareline S. > --- "John G. Scudder" wrote: >> At 6:05 AM -0800 2/11/03, Mareline Sheldon wrote: >>> Hello, >>> The standard says that if the remote router ID is not configured >>> then a router may include its IP address in sending the originator >>> id. >> >> It's not clear what the referent of "the standard" is here. I'm >> assuming RFC 1966, but RFC 1966 doesn't say anything about using your >> IP address as the originator ID, it says to use your router ID. With >> our new focus on correct use of terminology, this would more >> accurately be "BGP Identifier." >> >>> What will happen in case when i have peering using >>> IPv6? In that case i will not be having an IPv4 address to fill. >> >> draft-ietf-idr-bgp-identifier-01.txt >> >>> Has any thought gone on this? >>> >>> Regards, >>> Mareline S. >>> >>> __________________________________________________ >>> Do you Yahoo!? >> >> I do not Yahoo. >> >> --John > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Shopping - Send Flowers for Valentine's Day > http://shopping.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 IAA15830 for ; Wed, 12 Feb 2003 08:37:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EDBFD91221; Wed, 12 Feb 2003 08:37:30 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B595B91229; Wed, 12 Feb 2003 08:37: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 9D65191221 for ; Wed, 12 Feb 2003 08:37:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 830C35DE6D; Wed, 12 Feb 2003 08:37:29 -0500 (EST) Delivered-To: idr@merit.edu Received: from web20302.mail.yahoo.com (web20302.mail.yahoo.com [216.136.226.83]) by segue.merit.edu (Postfix) with SMTP id D5CA95DDA4 for ; Wed, 12 Feb 2003 08:37:28 -0500 (EST) Message-ID: <20030212133726.87383.qmail@web20302.mail.yahoo.com> Received: from [203.200.20.226] by web20302.mail.yahoo.com via HTTP; Wed, 12 Feb 2003 05:37:26 PST Date: Wed, 12 Feb 2003 05:37:26 -0800 (PST) From: Mareline Sheldon Subject: Re: Route Reflectors and IPv6 To: "John G. Scudder" Cc: idr@merit.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk okay .. so then it becomes mandatory for everyone to explicitly configure a BGP ID which needs to be unique in an AS! This is somewhat problematic coz till now we were not necessarily explicitly configuring BGP IDs for if none was given then it would automatically pick out one from its interfaces. This will not be possible in an IPv6 network now coz all the interfaces will be assigned IPv6 addresses. Mareline S. --- "John G. Scudder" wrote: > At 6:05 AM -0800 2/11/03, Mareline Sheldon wrote: > >Hello, > >The standard says that if the remote router ID is not configured > >then a router may include its IP address in sending the originator > >id. > > It's not clear what the referent of "the standard" is here. I'm > assuming RFC 1966, but RFC 1966 doesn't say anything about using your > IP address as the originator ID, it says to use your router ID. With > our new focus on correct use of terminology, this would more > accurately be "BGP Identifier." > > >What will happen in case when i have peering using > >IPv6? In that case i will not be having an IPv4 address to fill. > > draft-ietf-idr-bgp-identifier-01.txt > > >Has any thought gone on this? > > > >Regards, > >Mareline S. > > > >__________________________________________________ > >Do you Yahoo!? > > I do not Yahoo. > > --John __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.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 KAA00011 for ; Tue, 11 Feb 2003 10:21:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0660F9123D; Tue, 11 Feb 2003 10:20:39 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA61991262; Tue, 11 Feb 2003 10:20:38 -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 4B03A9123D for ; Tue, 11 Feb 2003 10:20:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2DEE95DDFB; Tue, 11 Feb 2003 10:20:36 -0500 (EST) Delivered-To: idr@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id B0C365DDD1 for ; Tue, 11 Feb 2003 10:20:35 -0500 (EST) Received: from cisco.com (router.cisco.com [171.69.182.20]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1BFKQB6026500; Tue, 11 Feb 2003 07:20:26 -0800 (PST) Received: from [64.101.214.208] (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA28604; Tue, 11 Feb 2003 10:20:33 -0500 (EST) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <20030211140520.45651.qmail@web20310.mail.yahoo.com> References: <20030211140520.45651.qmail@web20310.mail.yahoo.com> Date: Tue, 11 Feb 2003 10:20:16 -0500 To: Mareline Sheldon From: "John G. Scudder" Subject: Re: Route Reflectors and IPv6 Cc: idr@merit.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idr@merit.edu Precedence: bulk At 6:05 AM -0800 2/11/03, Mareline Sheldon wrote: >Hello, >The standard says that if the remote router ID is not configured >then a router may include its IP address in sending the originator >id. It's not clear what the referent of "the standard" is here. I'm assuming RFC 1966, but RFC 1966 doesn't say anything about using your IP address as the originator ID, it says to use your router ID. With our new focus on correct use of terminology, this would more accurately be "BGP Identifier." >What will happen in case when i have peering using >IPv6? In that case i will not be having an IPv4 address to fill. draft-ietf-idr-bgp-identifier-01.txt >Has any thought gone on this? > >Regards, >Mareline S. > >__________________________________________________ >Do you Yahoo!? I do not Yahoo. --John 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 JAA27306 for ; Tue, 11 Feb 2003 09:05:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2494D91247; Tue, 11 Feb 2003 09:05:24 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC7F091248; Tue, 11 Feb 2003 09:05:23 -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 EEA6791247 for ; Tue, 11 Feb 2003 09:05:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2A1905DF8C; Tue, 11 Feb 2003 09:05:22 -0500 (EST) Delivered-To: idr@merit.edu Received: from web20310.mail.yahoo.com (web20310.mail.yahoo.com [216.136.226.91]) by segue.merit.edu (Postfix) with SMTP id B56F15DE37 for ; Tue, 11 Feb 2003 09:05:21 -0500 (EST) Message-ID: <20030211140520.45651.qmail@web20310.mail.yahoo.com> Received: from [203.200.20.226] by web20310.mail.yahoo.com via HTTP; Tue, 11 Feb 2003 06:05:20 PST Date: Tue, 11 Feb 2003 06:05:20 -0800 (PST) From: Mareline Sheldon Subject: Route Reflectors and IPv6 To: idr@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Hello, The standard says that if the remote router ID is not configured then a router may include its IP address in sending the originator id. What will happen in case when i have peering using IPv6? In that case i will not be having an IPv4 address to fill. Has any thought gone on this? Regards, Mareline S. __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.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 IAA27077 for ; Tue, 11 Feb 2003 08:58:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 15D1B91245; Tue, 11 Feb 2003 08:57:56 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D17F091246; Tue, 11 Feb 2003 08:57:55 -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 B33A691245 for ; Tue, 11 Feb 2003 08:57:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 987C65DF8C; Tue, 11 Feb 2003 08:57:54 -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 E11B35DF6E for ; Tue, 11 Feb 2003 08:57:53 -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 h1BDvrS55018; Tue, 11 Feb 2003 05:57:53 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200302111357.h1BDvrS55018@merlot.juniper.net> To: idr@merit.edu Cc: skh@nexthop.com Subject: agenda for the IDR WG meeting MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46159.1044971873.1@juniper.net> Date: Tue, 11 Feb 2003 05:57:53 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, It is time to start setting the agenda for the San Francisco meeting. If you want to discuss issues with drafts at the San Francisco meeting please request a slot to do so, by sending mail to the wg chairs (skh@nexthop.com, yakov@juniper.net). 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 NAA11727 for ; Thu, 6 Feb 2003 13:14:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3878391213; Thu, 6 Feb 2003 13:14:27 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0045991217; Thu, 6 Feb 2003 13:14: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 EC37391213 for ; Thu, 6 Feb 2003 13:14:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id CFA945DE3F; Thu, 6 Feb 2003 13:14:25 -0500 (EST) Delivered-To: idr@merit.edu Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by segue.merit.edu (Postfix) with ESMTP id 59E655DD9B for ; Thu, 6 Feb 2003 13:14:25 -0500 (EST) Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id h16IEMc01243 for ; Thu, 6 Feb 2003 13:14:22 -0500 (EST) Received: from 192.168.0.185 by tenornet.com; THU, 6 Feb 2003 13:10:18 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Feb 2003 13:10:17 -0500 Message-ID: <6B190B34070BD411ACA000B0D0214E560165B8D2@newman.tenornet.com> From: "Tsillas, Jim" To: "'idr@merit.edu'" Subject: md5 TCP resets Date: Thu, 6 Feb 2003 13:10:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk rfc 2385 states that resets are ignored even when they originate due to a stale connection. If the connection is stale and the md5 digest can still be built, shouldn't the stale end issue the reset with an md5 digest so that the opposite end can receive the reset? Also, does it make sense to send resets with no digest (for the case where there is no listener) when the received packet contained a digest? It seems that would simply be a waste. -Jim. 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 JAA27829 for ; Wed, 5 Feb 2003 09:11:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E27139127C; Wed, 5 Feb 2003 09:10:54 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1DB69127E; Wed, 5 Feb 2003 09:10: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 6D4509127C for ; Wed, 5 Feb 2003 09:10:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 45F0B5DF5F; Wed, 5 Feb 2003 09:10:53 -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 C62845DF4D for ; Wed, 5 Feb 2003 09:10:52 -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 h15EAbS74944; Wed, 5 Feb 2003 06:10:37 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200302051410.h15EAbS74944@merlot.juniper.net> To: curtis@fictitious.org Cc: Mathew Richardson , andrewl@xix-w.bengi.exodus.net, idr@merit.edu Subject: Re: Issue 18 In-Reply-To: Your message of "Mon, 03 Feb 2003 12:11:55 EST." <200302031711.MAA57020@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17708.1044454237.1@juniper.net> Date: Wed, 05 Feb 2003 06:10:37 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Curtis, > > I disagree, but that doesn't matter since I'm fine with your proposed > > text below. In fact, I prefer it because it clarifies the handling > > of the comparison between EBGP and IBGP learned routes in the presence > > of MULTI_EXIT_DISC stripping. > > OK. > > > > If a MULTI_EXIT_DISC attribute is removed before re-advertising a > > > route into IBGP, then comparison based on the received EBGP > > > MULTI_EXIT_DISC attribute MAY still be performed. If an > > > implementation chooses to remove MULTI_EXIT_DISC, then the optional > > > comparison on MULTI_EXIT_DISC if performed at all MUST be performed > > > only among EBGP learned routes. The best EBGP learned route may > > > then be compared with IBGP learned routes after the removal of the > > > MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a > > > subset of EBGP learned routes and the selected "best" EBGP learned > > > route will not have MULTI_EXIT_DISC removed, then the > > > MULTI_EXIT_DISC must be used in the comparison with IBGP learned > > > routes. For IBGP learned routes the MULTI_EXIT_DISC MUST be used > > > in route comparisons which reach this step in the decision process. > > > > > > > > mrr > > > If there is no disagreement about changing our prior near consensus, > then we have no real change in the intent but some additional > clarification and may have converted "not quite concensus" to full > concensus. Full consensus is good if that's what we have. Your text will be incorporated into the next release of the draft. 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 AAA08000 for ; Tue, 4 Feb 2003 00:17:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 341A49123A; Tue, 4 Feb 2003 00:16:44 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1FD79123C; Tue, 4 Feb 2003 00:16:43 -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 583629123A for ; Tue, 4 Feb 2003 00:16:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4760B5DFC5; Tue, 4 Feb 2003 00:16:00 -0500 (EST) Delivered-To: idr@merit.edu Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id C64715DFA7 for ; Tue, 4 Feb 2003 00:15:59 -0500 (EST) Received: from cisco.com (megha.cisco.com [192.122.173.140]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h145FvSQ022840 for ; Mon, 3 Feb 2003 21:15:58 -0800 (PST) Received: from ROJOSEW2K ([10.77.139.156]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id KAA04644 for ; Tue, 4 Feb 2003 10:44:50 +0530 (IST) Message-ID: <062301c2cc0c$7f444690$9c8b4d0a@apac.cisco.com> From: "Roy Jose" To: Subject: Why drafts and RFC's are not shown up in the IDR page Date: Tue, 4 Feb 2003 10:45:56 +0530 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 Thanks, Roy 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 MAA26915 for ; Mon, 3 Feb 2003 12:13:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B4FC891227; Mon, 3 Feb 2003 12:12:25 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86E8A91228; Mon, 3 Feb 2003 12:12: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 3BBCA91227 for ; Mon, 3 Feb 2003 12:12:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 20D9E5DF97; Mon, 3 Feb 2003 12:12:24 -0500 (EST) Delivered-To: idr@merit.edu Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 510805DF5E for ; Mon, 3 Feb 2003 12:12:23 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA57020; Mon, 3 Feb 2003 12:11:55 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302031711.MAA57020@workhorse.fictitious.org> To: Mathew Richardson Cc: Curtis Villamizar , andrewl@xix-w.bengi.exodus.net, idr@merit.edu, yakov@juniper.net Reply-To: curtis@fictitious.org Subject: Re: Issue 18 In-reply-to: Your message of "Mon, 03 Feb 2003 11:50:07 EST." <20030203165007.GA608@nexthop.com> Date: Mon, 03 Feb 2003 12:11:55 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <20030203165007.GA608@nexthop.com>, Mathew Richardson writes: > > > I disagree, but that doesn't matter since I'm fine with your proposed > text below. In fact, I prefer it because it clarifies the handling > of the comparison between EBGP and IBGP learned routes in the presence > of MULTI_EXIT_DISC stripping. OK. > > If a MULTI_EXIT_DISC attribute is removed before re-advertising a > > route into IBGP, then comparison based on the received EBGP > > MULTI_EXIT_DISC attribute MAY still be performed. If an > > implementation chooses to remove MULTI_EXIT_DISC, then the optional > > comparison on MULTI_EXIT_DISC if performed at all MUST be performed > > only among EBGP learned routes. The best EBGP learned route may > > then be compared with IBGP learned routes after the removal of the > > MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a > > subset of EBGP learned routes and the selected "best" EBGP learned > > route will not have MULTI_EXIT_DISC removed, then the > > MULTI_EXIT_DISC must be used in the comparison with IBGP learned > > routes. For IBGP learned routes the MULTI_EXIT_DISC MUST be used > > in route comparisons which reach this step in the decision process. > > > > mrr If there is no disagreement about changing our prior near consensus, then we have no real change in the intent but some additional clarification and may have converted "not quite concensus" to full concensus. Full consensus is good if that's what we have. Curtis ps - I wonder if there is any "most modified paragraph" in bgp4 where the meaning was not changed just the wording. It would have to be somewhere in route selection or the state machine. No Cc to the list please - if it gets started it could be a lengthy thread. :-) 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 LAA26597 for ; Mon, 3 Feb 2003 11:51:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BF0D691220; Mon, 3 Feb 2003 11:50:48 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88CB591227; Mon, 3 Feb 2003 11:50: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 27E4091220 for ; Mon, 3 Feb 2003 11:50:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 147ED5DF5E; Mon, 3 Feb 2003 11:50:46 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 50B685DDDC for ; Mon, 3 Feb 2003 11:50:45 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h13GoAO02476; Mon, 3 Feb 2003 11:50:10 -0500 (EST) (envelope-from mrr@mrichardson.nexthop.com) 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 h13Go7C02469; Mon, 3 Feb 2003 11:50:07 -0500 (EST) (envelope-from mrr@mrichardson.nexthop.com) Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id h13Go7v00775; Mon, 3 Feb 2003 11:50:07 -0500 (EST) Date: Mon, 3 Feb 2003 11:50:07 -0500 From: Mathew Richardson To: Curtis Villamizar Cc: andrewl@xix-w.bengi.exodus.net, idr@merit.edu, yakov@juniper.net Subject: Re: Issue 18 Message-ID: <20030203165007.GA608@nexthop.com> References: <20030131144131.A256@demiurge.exodus.net> <200302012309.SAA50699@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302012309.SAA50699@workhorse.fictitious.org> User-Agent: Mutt/1.4i X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk > Curtis Villamizar [Sat, Feb 01, 2003 at 06:09:53PM -0500]: > >In message <20030131144131.A256@demiurge.exodus.net>, andrewl@xix-w.bengi.exodu >s.net writes: >> > If a MULTI_EXIT_DISC attribute is removed before re-advertising a >> > route into IBGP, then comparison based on the received MULTI_EXIT_DISC >> > attribute MAY still be performed. If an implementation chooses to >> > perform this comparison, then the comparison MUST be performed only >> > among EBGP learned routes, and it MUST be performed before the removal >> > of the MULTI_EXIT_DISC attribute. >The second one is wrong. The second sentence should start with "If an >implementation chooses to remove MULTI_EXIT_DISC". Replace "perform >this comparison" with "remove MULTI_EXIT_DISC" in the second sentence, >it then becomes redundant. Since the comparison is optional, the "and >it MUST be performed before the removal ..." could be interpreted as >an ambiguity (is it optional or not). I disagree, but that doesn't matter since I'm fine with your proposed text below. In fact, I prefer it because it clarifies the handling of the comparison between EBGP and IBGP learned routes in the presence of MULTI_EXIT_DISC stripping. > If a MULTI_EXIT_DISC attribute is removed before re-advertising a > route into IBGP, then comparison based on the received EBGP > MULTI_EXIT_DISC attribute MAY still be performed. If an > implementation chooses to remove MULTI_EXIT_DISC, then the optional > comparison on MULTI_EXIT_DISC if performed at all MUST be performed > only among EBGP learned routes. The best EBGP learned route may > then be compared with IBGP learned routes after the removal of the > MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a > subset of EBGP learned routes and the selected "best" EBGP learned > route will not have MULTI_EXIT_DISC removed, then the > MULTI_EXIT_DISC must be used in the comparison with IBGP learned > routes. For IBGP learned routes the MULTI_EXIT_DISC MUST be used > in route comparisons which reach this step in the decision process. 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 SAA21225 for ; Sat, 1 Feb 2003 18:10:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1628C9121E; Sat, 1 Feb 2003 18:10:05 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE0B691273; Sat, 1 Feb 2003 18:10: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 7ABA89121E for ; Sat, 1 Feb 2003 18:10:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 377835DEAF; Sat, 1 Feb 2003 18:10:02 -0500 (EST) Delivered-To: idr@merit.edu Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 12AC65DEAB for ; Sat, 1 Feb 2003 18:10:01 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id SAA50699; Sat, 1 Feb 2003 18:09:53 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302012309.SAA50699@workhorse.fictitious.org> To: andrewl@xix-w.bengi.exodus.net Cc: Mathew Richardson , idr@merit.edu, curtis@fictitious.org, yakov@juniper.net Reply-To: curtis@fictitious.org Subject: Re: Issue 18 In-reply-to: Your message of "Fri, 31 Jan 2003 14:41:31 PST." <20030131144131.A256@demiurge.exodus.net> Date: Sat, 01 Feb 2003 18:09:53 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <20030131144131.A256@demiurge.exodus.net>, andrewl@xix-w.bengi.exodu s.net writes: > Although I don't want to extend the time this issue is still open, I have > to agree with mrr here. The text, as it stands is not as clear as > the text mrr is proposing, or the text I proposed a while back. Of the > two alternates, I prefer mrr's text, since it states more clearly that > the comparison is optional. > > Is there any compelling reason NOT to go with one of these two? > > > If a MULTI_EXIT_DISC attribute is removed before re-advertising a > > route into IBGP, then if MULTI_EXIT_DISC comparisons are performed > ^^^^^^^ "and if" better? > > during tie-breaking, the routes that will have their MULTI_EXIT_DISC > > attributes removed before readvertisement in IGBP MUST be treated > > as having been received without a MULTI_EXIT_DISC attribute. > > > or > > > If a MULTI_EXIT_DISC attribute is removed before re-advertising a > > route into IBGP, then comparison based on the received MULTI_EXIT_DISC > > attribute MAY still be performed. If an implementation chooses to > > perform this comparison, then the comparison MUST be performed only > > among EBGP learned routes, and it MUST be performed before the removal > > of the MULTI_EXIT_DISC attribute. > > Andrew The second one is wrong. The second sentence should start with "If an implementation chooses to remove MULTI_EXIT_DISC". Replace "perform this comparison" with "remove MULTI_EXIT_DISC" in the second sentence, it then becomes redundant. Since the comparison is optional, the "and it MUST be performed before the removal ..." could be interpreted as an ambiguity (is it optional or not). If a MULTI_EXIT_DISC attribute is removed before re-advertising a route into IBGP, then comparison based on the received EBGP MULTI_EXIT_DISC attribute MAY still be performed. If an implementation chooses to remove MULTI_EXIT_DISC, then the optional comparison on MULTI_EXIT_DISC if performed at all MUST be performed only among EBGP learned routes. The best EBGP learned route may then be compared with IBGP learned routes after the removal of the MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a subset of EBGP learned routes and the selected "best" EBGP learned route will not have MULTI_EXIT_DISC removed, then the MULTI_EXIT_DISC must be used in the comparison with IBGP learned routes. For IBGP learned routes the MULTI_EXIT_DISC MUST be used in route comparisons which reach this step in the decision process. I think all cases are covered. I think the above is unambiguous. If we must change it, might as well make it completely unambiguous preferably without becoming cumbersome or overly wordy. Curtis